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
