I pursued actors model for a few years before growing dissatisfied with it. Actors model is still far too stateful to scale well, and does not deal effectively with lost messages. I roughly explain this dissatisfaction - and the alternative I favor (a form of synchronous, reactive agent-oriented programming) at [1].
You say in your blog post: "On the contrary! The actor model is flexible enough to model the mechanisms of practically any other model of computation, including functional, logical, procedural and object-oriented." I object. The only classes of modeling that you can reasonably attribute to Actors model are those Actors model subsumes. I use 'subsume' in the sense explained in Levy's 1999 Call-by-push-value paper: L1 can be said to subsume L2 if every expression in L2 can be achieved by pure local syntactic transform from L1 (that is, L2 is hygienic syntactic sugar for L1). If you don't constrain yourself, then your arguments reduce to 'Actors model is Turing complete, feel my excitement.' We should not find interest in Turing tarpits, except as curiosities for a museum. Actors model does not subsume these other models - not even for the models that at first glance seem close enough to derive trivially from Actors (such as functional and procedural and object-oriented). The mention of logic programming is nonsense; Perl with its regexps is better for logic programming than is Actors model. Much of the problem Actors model has with modeling other paradigms is that actors do not compose (do not maintain actor properties in face of composition). Actors process one message at a time, which makes tractable the management of dynamic state in the face of concurrent messages, but a group of actors will not normally retain this property except with complex and non-local design patterns. Even dealing with query-and-reply becomes complex and non-trivial. I developed a Transactional Actors Model [2] to support actor composition by eliminating dependence upon message queues. But I still ended up rejecting Actors model for being far too stateful. Various forms of state in the Actors model include implicit messages-in-transit, the snapshots of the past those messages carry into the future, the implicit continuation/thread for processing each messages once received, and the explicitly stateful actors that change behaviors after receiving messages. All this state is an enormous mess that hinders the alleged scalability of Actors model. State hinders redundancy, persistence, disruption tolerance. When you seriously approach disruption and network partitioning and survivable networking schemes (such as networking on mobility-based overlays), the state of each message - that each message is processed at most once (as opposed to being processed many times) - is headaches and complexity and bugs. And how shall we deal with a lost message? In a real system permanent node-loss is indistinguishable from a long-term disruption, and so we can neither make the Actors model guarantee of delivering all messages. Detecting a lost message in Actors model is non-trivial, much less handling and recovering from it. And yet graceful degradation and resilience are among the most important things an in-the-large programming model must support developers in achieving. Others important properties include scalability, concurrency, stability and robustness, security, extensibility, deployment, maintenance and upgrade. I believe that Actors model is deficient in all of these. As an aside, while Actors model might seem securable within precept of the Object Capability Model, the heavy reliance upon vulnerable design patterns for even simple compositions does much to undermine this property. (I.e. consider the effort to develop concurrency-control patterns that will be secure against priority inversion and denial-of-service. Transactional Actor Model qualifies... but many techniques will not, and that's just one pattern among many.) The model may seem simple at first glance, but there is a difference between 'simple' and 'simplistic': actors model too far reduces the physical constraints for computation, and the consequence of this over-reduction is a lot of extra 'design patterns' and complexity. These are problems common to a whole class of languages that we call 'Turing tarpits'. The reputation of actors model is greatly overblown. When it comes to actors, there are many good reasons "Why Not". In April 2010, I developed a new model that corrects deficiencies I was seeing in Actors model and even my transactional variation. It is reactive, agent-oriented, and replaces imperative messages with a declarative, demand-based observer-effect. You might read about it at [3]. David Barbour [1] http://c2.com/cgi/wiki?ActorVsAgent [2] http://c2.com/cgi/wiki?TransactionalActorModel [3] http://c2.com/cgi/wiki?ReactiveDemandProgramming On Fri, Jun 18, 2010 at 7:58 PM, Dale Schumacher <[email protected]> wrote: > Published: > "Actors in Clojure — Why Not?" (http://bit.ly/9ZUXaQ) > http://www.dalnefre.com/wp/2010/06/actors-in-clojure-why-not/ > > This article provides a counterpoint to Rich Hickey's rationale for > not including actor-based concurrency in Clojure. > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
