On Sun, Apr 7, 2013 at 2:56 PM, Tristan Slominski < [email protected]> wrote:
> Well... composing multiple functions does not result in the same > termination properties as a single function either, does it? Especially > when we are composing nondeterministic computations? (real question, not > rhetorical) I'm having difficulty seeing how this is unique to actors. > An individual actor is guaranteed to terminate after receiving a message. It's in the definition: upon receiving a message an actor can send out a *finite* number of messages to other actors. But two actors can easily (by passing messages in circles) send out an infinite number of messages to other actors upon receiving a single message. Therefore, with respect to this property, you cannot (in general) reason about or treat groups of two actors as though they were a single actor. Similarly, there is no guarantee that two actors will finish processing even a single message before they start processing the next one. A group of actors thus lacks the atomicity and consistency properties of individual actors. (Of course, all this would be irrelevant if these weren't properties people depend on when reasoning about system correctness. But they are.) As you note, actors are not unique in their non-termination. But that misses the point. The issue was our ability to reason about actors compositionally, not whether termination is a good property. > > But how do you weigh freedom to make choices for "the task at hand" even >> if they're bad choices for the tasks NOT immediately at hand (such as >> integration, maintenance)? > > > For this, I think all of us fall back on heuristics as to what's a "good" > idea. But those heuristics come from past experience. > We also use models - e.g. actors/messaging, databases, frameworks, VMs, pubsub, etc. - with understanding (or hope) that they're supposed to help. We can then focus our brainpower on "the task at hand" with an understanding that various cross-cutting concerns are either addressed or can be at leisure. And that's exactly what a good language should be doing - lowering the bar for those cross-cutting concerns. > Hmm. Based on your response, I think that we define event systems > differently. > I provided a definition for 'events' in my article. By events, I include commands, messages, procedure calls, other conceptually `instantaneous` values in the system that independently effect or report changes in state. The 'instantaneous', 'independent', and 'changes in state' are all relevant to my arguments. If you mean something different by event systems, we might be talking past one another. The system as a whole seems to me to be resilient, and I don't see that > even if there is no generic way to re-establish connection at TCP/IP level > this degrades resiliency somehow. > We can develop systems that exhibit resilience due to ad-hoc mechanisms. That doesn't necessarily "degrade resiliency", but it certainly loses the "generic" and creates a lot of repeated development work. Review my assertion with an understanding that I was emphasizing the "generic" (and certainly not saying "event systems lack resilience"): *Event systems lack generic resilience.* Developers have built patterns for resilient event systems – timeouts, retries, watchdogs, command patterns. Unfortunately, these patterns require careful attention to the specific events model – i.e. where retries are safe, where losing an event is safe, which subsystems can be restarted. Many of these recovery models are not compositional – e.g. timeouts are not compositional because we need to understand the timeouts of each subsystem. Many are non-deterministic and work poorly if replicated across views. By comparison, state models can generically achieve simple resilience properties like eventual consistency and snapshot consistency. Often, developers in event systems will eventually reinvent a more declarative, RESTful approach – but typically in a non-composable, non-reentrant, glitchy, lossy, inefficient, buggy, high-overhead manner (like observer patterns). To the extent that 'multiple layers are at play' - I agree, but I believe it's the non-eventful layers that contribute to resilience even as the eventful ones (and POST) do their level best to tear it away. Regards, Dave
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
