I had this long response drafted criticizing Bloom/CALM and Lightweight Time Warps, when I realized that we are probably again not aligned as to which "meta" level we're discussing.
(my main criticism of Bloom/CALM was assumption of timesteps, which is an indicator of a meta-framework relying on something else to implement it within "reality"; and my criticism of Lightweight Time Warps had to do with that it is a protocol for message-driven simulation, which also needs an implementor that touches "reality"; synchronous reactive programming has the word synchronous in it) -> hence my assertion that this is more "meta" level than actors. I think you and I personally care about different things. I want a computational model that is as close to how the Universe works as possible, with a minimalistic set of constructs from which everything else can be built. Hence my references to cellular automata and Wolfram's hobby of searching for the Universe. Anything which starts as "synchronous" cannot be minimalistic because that's not what we observe in the world, our world is asynchronous, and if we disagree on this axiom, then so much for that :D But actors model fails with regards to extensibility(*) and reasoning Those are concerns of an imperator, are they not? Again, I'm not saying you're wrong, I'm trying to highlight that our goals differ. But, without invasive code changes or some other form of cheating (e.g. > global reflection) it can be difficult to obtain the name of an actor that > is part of an actor configuration. Again, this is ignorance of the power of Object Capability and the Actor Model itself. The above is forbidden in the actor model unless the configuration explicitly sends you an address in the message. My earlier comment about Akka refers to this same mistake. However, you do bring up interesting meta-level reasoning complaints against the actor model. I'm not trying to dismiss them away or anything. As I mentioned before, that list is a good guide as to what meta-level programmers care about when writing programs. It would be great if actors could make it easier... and I'm probably starting to get lost here between the meta-levels again :/ Which brings me to a question. Am I the only one that loses track of which meta-level I'm reasoning or is this a common occurrence Bringing it back to the topic somewhat, how do people handle reasoning about all the different layers (meta-levels) when thinking about computing? On Wed, Apr 10, 2013 at 12:21 PM, David Barbour <[email protected]> wrote: > On Wed, Apr 10, 2013 at 5:35 AM, Tristan Slominski < > [email protected]> wrote: > >> I think it's more of a pessimism about other models. [..] My >> non-pessimism about actors is linked to Wolfram's cellular automata turing >> machine [..] overwhelming consideration across all those hints is >> unbounded scalability. >> > > I'm confused. Why would you be pessimistic about non-actor models when > your argument is essentially that very simple, deterministic, non-actor > models can be both Turing complete and address unbounded scalability? > > Hmm. Perhaps what you're really arguing is "pessimistic about procedural" > - which today is the mainstream paradigm of choice. The imperial nature of > procedures makes it difficult to compose or integrate them in any > extensional or collaborative manner - imperative works best when there is > exactly one imperator (emperor). I can agree with that pessimism. > > In practice, the limits of scalability are very often limits of reasoning > (too hard to reason about the interactions, safety, security, consistency, > progress, process control, partial failure) or limits of extensibility (to > inject or integrate new behaviors with existing systems requires invasive > changes that are inconvenient or unauthorized). If either of those limits > exist, scaling will stall. E.g. pure functional programming fails to scale > for extensibility reasons, even though it admits a lot of natural > parallelism. > > Of course, scalable performance is sometimes the issue, especially in > models that have global 'instantaneous' relationships (e.g. ad-hoc > non-modular logic programming) or global maintenance issues (like garbage > collection). Unbounded scalability requires a consideration for locality of > computation, and that it takes time for information to propagate. > > Actors model is one (of many) models that provides some of the > considerations necessary for unbounded performance scalability. But actors > model fails with regards to extensibility(*) and reasoning. So do most of > the other models you mention - e.g. cellular automatons are even less > extensible than actors (cells only talk to a fixed set of immediate > neighbors), though one can address that with a notion of visitors (mobile > agents). > > From what you say, I get the impression that you aren't very aware of > other models that might compete with actors, that attempt to address not > only unbounded performance scalability but some of the other limiting > factors on growth. Have you read about Bloom and the CALM conjecture? > Lightweight time warp? What do you know of synchronous reactive > programming? > > There is a lot to be optimistic about, just not with actors. > > (*) People tend to think of actors as extensible since you just need names > of actors. But, without invasive code changes or some other form of > cheating (e.g. global reflection) it can be difficult to obtain the name of > an actor that is part of an actor configuration. This wouldn't be a problem > except that actors pervasively encapsulate state, and ad-hoc extension of > applications often requires access to internal state [1], especially to > data models represented in that state [2]. > > Regards, > > Dave > > [1] http://awelonblue.wordpress.com/2012/10/21/local-state-is-poison/ > [2] http://awelonblue.wordpress.com/2011/06/15/data-model-independence/ > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
