On Jun 23, 6:38 pm, David Barbour <[email protected]> wrote: > I am confident that you can find actors-model patterns to handle these > issues. (I certainly did.) > > But I suspect there is a difference in perspective hindering our > communication.
I suspect we need to clarify the distinction between a programming model and a programming language/environment based on the model. Patterns at the _model_ level represent the way that the model influences our conceptual decomposition of the problem and our composition of elements of a solution. In keeping with the FoNC goal of creating powerful systems from simple components, the actor model seems (to me) like a good simple foundation. An actor language, such as Humus, is responsible for providing compact means for expressing abstractions. Failings of the language are not necessarily failings of the model. > You seem to consider patterns to demonstrate success of the model. I > consider patterns to be signs of inadequacy and inappropriate use of a > model. A pattern is essentially a mechanism to hand-implement a new > model or feature into a language. Setting aside didactic purpose and > intellectual curiosity, a practitioner's reason for developing and > using a design pattern is that the host language was inadequate or was > missing features. I think we are actually in agreement WRT the purpose of a pattern in the context of a programming _language_. Sometimes you observed a pattern after-the-fact, and then abstract it out for general application. > To clarify, by 'pattern' I mean features that you end up > re-implementing in code in slight variations, and that fail to > abstract or compose, or that require cooperation of non-local code > (from libraries and such). Pure functions or use of macros can go a > long way towards eliminating need for patterns. OTOH, there is such a > thing as a language or model being 'too powerful', hindering ad-hoc > analysis. If a language doesn't provide appropriate abstraction mechanisms, then you end up with a lot of duplication with minor variations, as you described. I agree, this is a bad thing. However, libraries and frameworks _are_ abstraction mechanisms. Humus is, by design, a minimalist language for describing (and understanding) actors. It was named "Humus" in reference to the stable base-state of organic material, from which rich diversity can grow. The primary abstraction mechanism is functional abstraction and composition. While this provides a powerful foundation, in some ways it could be considered an "actor assembly language". It would be useful to create a language with more powerful abstractions mechanisms that would be suitable for the creation of domain-specific languages. I believe such a language could be described in Humus, and thus retain the fundamental properties of actors. > Essentially, whenever you say "I'm sure there's a suitable > solution-pattern for it", I hear "Actors model isn't the most > appropriate for that, so first we create a new model that...". Now, > that isn't a bad thing by itself if kept rare (a language that needs > no patterns is possibly too powerful). But I find dissonant your > optimism about these patterns, as though they were a positive point in > favor of actors. Now, if you argued that these patterns were much > easier to describe in Actors Model relative to some competitor model, > or that the result had nicer properties (scalability, performance, > safety, etc.), you might have a decent point (this pattern stinks less > in Actors model!). I am optimistic that there are appropriate patterns-of-interaction for actors, regardless of their language of expression, that are suitable for the kinds of concurrent, and even distributed, problems with which we currently struggle. In addition, I _would_ argue that there are powerful interaction patterns that are much easier to express with actors. And the resulting composition _does_ maintain safety, scalability and performance (actually responsiveness) properties that are desirable. > So I'm not saying that there aren't solutions to the challenges I > described. There are solutions. But I have many problems with the > solutions, and I consider the fact that the solutions are often > pattern-based to be among the problems. So here's the real challenge: > solve the challenges without using any insecure or pervasive or > non-composable patterns. This is the challenge that I am trying to meet. By building actor- based solutions and exploring their strengths and limitations, I hope to share the patterns for success and warn of the pitfalls. I understand that you've been down this road and are sharing your concerns about the pitfalls you've encountered. I appreciate that, and will keep my eyes open to those dangers. Perhaps I can find acceptable ways to mitigate the danger. At worst, I'll simply confirm your observations. > <[email protected]> wrote: > > The history of civilization provides a rich set of tried-and-true > > interaction patterns--much richer than the relatively impoverished > > history of computing :-) > > I suppose you'll be adding the ability for a bunch of actors to team > up, kill, and enslave one another? :-) I'm sure there are interesting algorithms based on competition for scarce resources (constraint optimization) and even "infecting" other agents with self-serving goals. For now, I'll leave that to those who are building on the long tradition of AI and agent-based research. Dale _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
