I think I am now bogged down in a Meta Tarpit :D A good question to ask is: "can I correctly and efficiently implement > actors model, given these physical constraints?" One might explore the > limitations of scalability in the naive model. Another good question to ask > is: "is there a not-quite actors model suitable for a more > scalable/efficient/etc. implementation". (But note that the not-quite > actors model will never quite be the actors model.)
The problem with the above is that popular implementations (like Akka, for example) give up things such as Object Capability for nothing.. it's depressing. Hearing commentary from one of the creators of the framework himself, as far as I understand, this was not a conscious choice, but a result of unfamiliarity with the model. Actors makes a guarantee that every message is delivered (along with a nigh > uselessly weak fairness property), but for obvious reasons guaranteed > delivery is difficult to scale to distributed systems. And it seems you're > entertaining whether *ad-hoc message loss* is suitable. I still prefer to model them as in every message is delivered. It wasn't I who challenged this original guaranteed-delivery condition but Carl Hewitt himself. (see: http://letitcrash.com/post/20964174345/carl-hewitt-explains-the-essence-of-the-actorat timestamp 14:00 ). I was quite surprised by this ( https://groups.google.com/d/msg/computational-actors-guild/Xi-aGdSotxw/nlq8Ib0fDaMJ) Consider an alternative: explicitly model islands (within which no message > loss occurs) and serialized connections (bridges) between them. Disruption > and message loss could then occur in a controlled manner: a particular > bridge is lost, with all of the messages beyond a certain point falling > into the ether. Compared to ad-hoc message loss, the bridged islands design > is much more effective for reasoning about and recovering from partial > failure. You've described composing actors into actor configurations :D, from the outside world, your island looks like a single actor. I find "actors can only process one message at a time" is an interesting > constraint on concurrency, and certainly a useful one for reasoning. And > it's certainly relevant with respect to composition (ability to treat an > actor configuration as an actor) and decomposition (ability to divide an > actor into an actor configuration). >From the same video I linked above at time 5:16 Carl Hewitt explains one message at a time. Do you also think zero and one are uninteresting numbers? I've spent an equivalent of a semester reading/learning axiomatic set theory and trying to understand why 0+1=1 and 1+1=2. I definitely don't think they are "uninteresting" :D It seems you misrepresent your true opinion and ignore difficult, > topic-relevant issues by re-scoping discussion to one of explanatory power. This may very well be the case, hence my earlier comment of being stuck in a Meta Tarpit. But to the extent you do so, you can't claim you're benefiting from actors > model. It's a little sad when we work around our models rather than with > them. I don't think we have created enough tooling or understanding to fully grok the consequences of the actor model yet. Where's our math for emergent properties and swarm dynamics of actor systems? Where are our tools for that? Even with large companies operating server farms, the obsession with control of individual components is pervasive. Even a Java-world all-time favorite "distributed" coordination system ZooKeeper has a *master* node that is elected. If that's our pinnacle, no wonder we can't benefit from the actor model. Where is our reasoning about symbiotic autopoietic and allopoietic systems? (earlier reference to http://pleiad.dcc.uchile.cl/_media/bic2007/papers/conscientioussoftwarecc.pdf) This is, in my view, where the actor systems will shine, but I haven't seen (it could be my ignorance) sustained community searching to discover and command such actor configurations. This is what I'm trying to highlight when I discuss the appropriate frame of reference for actor system programming. (This can be rooted in my ignorance, in which case, I would love some pointers to how this approach failed in the past). That said, focusing on explanatory power could be interesting - e.g. > comparing actors model with other physically-inspired models (e.g. time > warp, cellular automata, synchronous reactive). To be honest, I think > actors model will fare poorly. Where do 'references' occur in physics? What > about fan-in and locality? Such issues include composition, decomposition, consistency, discovery, > persistence, runtime update. > But there are also a few systemic with respect to implementation - e.g. > regarding garbage collection, process control, and partitioning or partial > failure in distributed systems, and certain optimizations (inlining, > mirroring). Actors really aren't as scalable as they promise without quite > a few hacks. That's some stuff that I'm interested in tackling. It should be interesting. This discussion has certainly started to frame problems and challenges that I will need to address in order to create an actor system that would meet your "usability"(for lack of a better world for all of the above) criteria. For such properties we *must* reason in an external language/system, > since Goedel showed that such loops cannot be closed without producing > inconsistency (or the analogous 'bad' outcome). Thank you Chris, your highlights tremendously helped to anchor my mind at the correct "layer" of the conversation. On Mon, Apr 8, 2013 at 11:37 PM, David Barbour <dmbarb...@gmail.com> wrote: > > On Mon, Apr 8, 2013 at 6:29 PM, Tristan Slominski < > tristan.slomin...@gmail.com> wrote: > >> The problem with this, that I see, is that [..] in my physics view of >> actors [..] Messages could be lost. >> > > Understanding computational physics is a good thing. More people should do > it. A couple times each year I end up in discussions with people who think > software and information aren't bound by physical laws, who have never > heard of Landauer's principle, who seem to mistakenly believe that > distinction of concepts (like information and representation, or mind and > body) implies they are separable. > > However, it is not correct to impose physical law on the actors model. > Actors is its own model, apart from physics. > > A good question to ask is: "can I correctly and efficiently implement > actors model, given these physical constraints?" One might explore the > limitations of scalability in the naive model. Another good question to ask > is: "is there a not-quite actors model suitable for a more > scalable/efficient/etc. implementation". (But note that the not-quite > actors model will never quite be the actors model.) Actors makes a > guarantee that every message is delivered (along with a nigh uselessly weak > fairness property), but for obvious reasons guaranteed delivery is > difficult to scale to distributed systems. And it seems you're entertaining > whether *ad-hoc message loss* is suitable. > > That doesn't mean ad-hoc message-loss is a good choice, of course. I've > certainly entertained that same thought, as have other, but we can't trust > every fool thought that enters our heads. > > Consider an alternative: explicitly model islands (within which no message > loss occurs) and serialized connections (bridges) between them. Disruption > and message loss could then occur in a controlled manner: a particular > bridge is lost, with all of the messages beyond a certain point falling > into the ether. Compared to ad-hoc message loss, the bridged islands design > is much more effective for reasoning about and recovering from partial > failure. > > One could *implement* either of those loss models within actors model, > perhaps requiring some global transforms. But, as we discussed earlier > regarding composition, the implementation is not relevant while reasoning > with abstractions. > > Reason about the properties of each abstraction or model. Separately, > reason about whether the abstraction can be correctly (and easily, > efficiently, scalably) implemented. This is 'layering' at its finest. > > >> This is another hint that we might have a different mental model. I don't >> find concurrency within an actor interesting. Actors can only process one >> message at a time. So concurrency is only relevant in that sending messages >> to other actors happens in parallel. That's not an interesting property. >> > > I find "actors can only process one message at a time" is an interesting > constraint on concurrency, and certainly a useful one for reasoning. And > it's certainly relevant with respect to composition (ability to treat an > actor configuration as an actor) and decomposition (ability to divide an > actor into an actor configuration). > > Do you also think zero and one are uninteresting numbers? Well, de > gustibus non est disputandum. > > >> >> Actor behavior is a mapping function from a message that was received to >> creation of finite number of actors, sending finite number of messages, and >> changing own behavior to process the next message. This could be a simple >> dictionary lookup in the degenerate case. What's there to reason about in >> here? >> > > Exactly what you said: finite, finite, sequential - useful axioms from > which we can derive theorems and knowledge. > > >> >> A fact is that programming is NOT like physics, >> >> >> This is a description >> > > Indeed. See how easily we can create straw-man arguments with which we can > casually agree or disagree by stupidly taking sentence fragments out of > context? :-) > > > > I like actors precisely because I CAN make programming look like physics. >> > > I am fond of linear logic and stream processing for similar reasons. I > certainly approve, in a general sense, of developing models designed to > operate within physical constraints. But focusing on the aspects I enjoy, > or disregarding those I find uninteresting, would certainly put me at risk > of reasoning about an idealized model a few handwaves removed from the > original. > > > > relying on global knowledge when designing an actor system seems, to me, >> not to be the "right" way >> > > In our earlier discussion, you mentioned that actors model can be used to > implement lambda calculus. And this is true, given bog standard actors > model. But do you believe you can explain it from your 'physics' view > point? How can you "know" that you've implemented, say, a Fibonacci > function with actors, if you forbid knowledge beyond what can be discovered > with messages? Especially if you allow message loss? > > >> >> I think this highlights our different frames of reference when we >> discuss actor systems. Refactoring, static typing, maintenance, >> optimizations, etc. are [..] relevant in a productivity sense, but [..] >> not the interesting part of the actor system. >> > > Programming models are for programming - specifying behavior, not just > describing or predicting behavior that already exists. The 'productivity > sense' is thus very relevant if we are to consider actors in its role as a > programming model. > > >> what language an actor system is written in is, in my opinion, an >> "implementation detail". > > > Programming models aren't necessarily implemented as 'languages'. They can > be implemented as frameworks, for example. But issues of abstraction, > refactoring, maintenance, validation, etc. will still apply to users > because those aren't implementation details. They are software development > concerns. > > >> >> I think I'm describing an actor model as in "turing machine/a model of >> computation" (a running system of actors communicating via messages, the >> "platonic form" of it, if you will), whereas you're describing an actor >> model as in "language". >> > > It is clear that you use and promote use of the actors model as a > programming model. It is clear that you do not consider actors merely to be > an explanatory aide. It seems you misrepresent your true opinion and ignore > difficult, topic-relevant issues by re-scoping discussion to one of > explanatory power. > > That said, focusing on explanatory power could be interesting - e.g. > comparing actors model with other physically-inspired models (e.g. time > warp, cellular automata, synchronous reactive). To be honest, I think > actors model will fare poorly. Where do 'references' occur in physics? What > about fan-in and locality? > > >> I think we might have interesting things to talk about within the >> confines of an actor _language_, but we should make a clear distinction >> about expressiveness and properties of a language, vs. those of an actor >> model of computation. >> > > Any "expressiveness issues" that can be attributed to actors model are a > consequence of the model. It doesn't matter whether you implement it as a > language or a framework or even use it as a design pattern. > > Of course, one might overcome certain expressiveness issues by stepping > outside the model, which may be easy for a framework or certain > multi-paradigm languages. But to the extent you do so, you can't claim > you're benefiting from actors model. It's a little sad when we work around > our models rather than with them. > > > > I'm very much interested in hearing about the "systemic problems of >> actors" because I'd like to figure out any solutions for such from my >> physics perspective on the problem. >> > > Many of those systemic problems regard use of actors model as a > programming model, i.e. where developers *specify* behavior in terms of > actors and messages. Such issues include composition, decomposition, > consistency, discovery, persistence, runtime update. > > But there are also a few systemic with respect to implementation - e.g. > regarding garbage collection, process control, and partitioning or partial > failure in distributed systems, and certain optimizations (inlining, > mirroring). Actors really aren't as scalable as they promise without quite > a few hacks. > > Regards, > > Dave > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
