On Thu, Jan 17, 2013 at 12:42 PM, Ross Bencina
<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.
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.
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.
>
> 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).
With four cores in a laptop, we don't need to worry about relativity issues
at the physical or communication layers.
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.
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.
--
bringing s-words to a pen fight
Received on Thu Jan 17 2013 - 23:46:20 GMT