On 18/01/2013 10:45 AM, David Barbour wrote:
> On Thu, Jan 17, 2013 at 12:42 PM, Ross Bencina
> <rossb-lists_at_audiomulch.com <mailto:rossb-lists_at_audiomulch.com>> wrote:
>
> On 18/01/2013 6:29 AM, David Barbour wrote:
>
> It seems controlling use of local state is important if we both want
> rich abstraction - i.e. where composite networks can be
> abstracted - and
> live programming.
>
>
> There are models that can deal with systems only involving local
> state (eg. the Actor model).
>
> max.msp provides a reasonable example of the utility of this for
> live programming.
>
>
> The issue wasn't whether local state is sufficient for modeling, but
> rather for abstraction and upgrade (or live programming). It is easy to
> abstract and parameterize stateful actor networks, then instantiate
> them. But it is difficult to apply updates to those abstractions or
> parameters to the networks so instantiated. And while I haven't used Max
> (only perused it some), I suspect it isn't very strong for abstraction.
The Max abstraction mechanism is (more-or-less) heirachical/nested
composition of actors.
> If we desire *both* rich abstraction *and* live programming -
> simultaneously, for the same program - I think we need to limit use of
> local state.
>
> (cf.
> http://awelonblue.wordpress.__com/2012/10/21/local-state-is-__poison/
> <http://awelonblue.wordpress.com/2012/10/21/local-state-is-poison/>)
>
>
> >From the post:
> """If you think global shared state is bad, you’re doing it wrong.
> To achieve large scale, robust, resilient, maintainable, extensible,
> eternal systems, we must transition away from local state and shove
> essential state into global, shared spaces where it can be
> represented independently of program logic."""
>
> The problem with the position taken by that post is that it assumes
> an absolutist model of the world, which according to current
> scientific opinion is not realistic. There is only local state and
> local time.
>
>
> Realism isn't the goal. We want our software to be easier to manipulate
> and simpler to reason about than "real" physical systems. The relevant
> question is not whether the system is realistic, rather whether its
> simplifying assumptions render the model unscalable.
One could argue that realism leads to improved usability.
People certainly *have* argued that the absolutist model is unscalable.
Asynchronous CPUs and the inconsistency robustness movement are two
examples.
> That aside, I think you misrepresent both the post and current
> scientific opinion. Global state still allows for notions of distance
> and disruption between state resources. And scientific opinion still
> models synchronous progression of time in different systems even when
> relativity results in some strange compression and decompression.
Perhaps we're speaking accross each other since I don't really see how
this response connects with my comment against absolutism. Global state
certainly does allow for notions of distance and disruption -- but
fundamentally the idea of global state is absolutist. I agree with you
about local synchronous progression -- but that just supports my point
about local state and local time.
> On a single CPU you can pretend that you're in an absolutist
> universe, but in distributed concurrent systems that's not the case
> (even the ones involving 4 cores in your laptop).
>
>
> We can't assume four cores (or threads) are fully synchronous, but we
> can ensure they are synchronous to within a small epsilon (e.g. tens of
> microseconds). We can also design concurrency models and software robust
> to somewhat larger epsilons (e.g. tens of milliseconds).
We can do this (and it is common practice), but it is fundamentally
inefficient.
> With four cores in a laptop, we don't need to worry about relativity
> issues at the physical or communication layers.
Maybe not with four cores, but it doesn't take many more for cache
synchronisation to become a bottle neck if you have global/shared state.
> Trying to pretend that global state exists by forcing it through a
> "persistent substrate" just creates a bottleneck.
>
>
> No, it doesn't. Whether state becomes a bottleneck depends on program
> architecture, on fan-in and fan-out of particular state resources.
> Bottlenecks are essentially orthogonal to whether state is local or
> global, volatile or persistent.
I suspect that I don't understand your use of the term global then. A
global resource with 1:1 fan in/out is effectively a local resource.
Global to me implies global visibility and hence contention.
> Of course there are pragmatic reasons to do this sometimes, but to
> suggest that this is the way forward seems misguided to me.
>
>
> A claim like 'local state is poison' will, of course, be quite
> controversial. It contradicts a whole generation of established best
> practice. A whole generation of programmers know that "global state is
> evil" but cannot explain why - e.g. regarding modularity, local
> reasoning, concurrency.
>
> I would keep global state but tackle a few of the weaknesses. I would
> hope for you to keep an open mind about the possibility, to examine it
> with reasoning, not just react based on intuitions that modern
> programming culture may have ingrained.
I think you mis-read my communication style if you think I'm not keeping
an open mind.
Ross.
Received on Fri Jan 18 2013 - 00:27:23 GMT