On Jan 20, 2013 5:44 PM, "Ross Bencina" <rossb-lists_at_audiomulch.com> wrote:
>
>
>> Inconsistency robustness (which seems to be Carl Hewitt's
>> main platform of late) is quite poorly argued for the scales relevant to
>> most programs.
>
>
> Can you provide an argument or a link to substantiate this claim please?
No. But Hewitt also argues on LtU. I'm sure you can find our arguments.
The basic issue is that, while large systems cannot have full agreement on
information, they can still have:
* islands of internal consistency
* a consistent model for propagation of information over time
* models for clean disruption
These are sufficient conditions for forms of global consistency, albeit of
a weaker nature than 'global agreement'. Further, they are fully compatible
with what we know of physics.
Hewitt's argument hinges on an over-generalization: that we can't have
global agreement, therefore we can't have any kind of global consistency.
>> What definition of 'absolutist' are you using?
>
>
>
> The idea that everything exists in a simultaneously accessible state and
that there is a single continuous notion of time throughout the universe
>
Consider a system where we have a global notion of time, yet no participant
in the system has instant access to it; information (or users of
information) must still propagate through space.
You present absolutism vs. relativism, but are those just different faces
of the same cube?
>>
>>
>> I mean 'global' in a similar sense that a filesystem is global relative
>> to its application. This doesn't imply 'global visibility' - e.g. not
>> every process can see every part of every file-system.
>
>
> I would suggest that common usage (in programming) is that "global" is
taken to mean 'globally visible' and 'globally acessible' (navigable,
inspectable).
Global has never meant global visibility relative to every scope (the
module/process/service structure).
>
> Given this kind of "ingrained" definition, and, as one of the commenters
on your blog suggested, you may want to revise, qualify or clarify your use
of the term 'global' there.
I did, in fact, clarify my use of it (i.e. first describing it as
'external' state). But people get stuck on global visibility, despite such
clarification, and despite its absence even in traditional systems. Not my
problem.
> In many languages "local" state is only local within some subset of the
programming environment (perhaps the core language sans reflection), not
within the debugger or reflection system.
True. But it still makes a difference that it is *modeled* as global vs.
local state, I.e. such that the abstraction is consistent with the usage,
and is part of our formal reasoning.
A debugger is traditionally one big abstraction violator. What if it didn't
need to be? We could precisely reason about debugging a system, and might
even support it more effectively.
>
> x = new Object();
>
>
> It really depends on how you read this as to whether x is local.
Regardless of whether 'x' is local, the notion of creating 'new' identity
requires local state.
>
> x is not being materialised out of thin air, it's being allocated out of
the global process address space.
That is only the implementation. It's the abstraction that we understand
and reason about. The connection to implementation is very unstable (e.g.
won't allocate to the same location each time).
> there's nothing stopping me enumerating all objects allocated
You aren't in control of the allocator. In most languages, it will take
another abstraction violation to enumerate the objects...
>
> I can see how this kind of "global" is important for live programming (to
reify allocation into a separate acessible layer, like a tuplespace as you
suggest). You'd need to do the same for activation frames.
Or we could be rid of activation frames... or ensure bounded time returns
on them. When I said local state is poison, I explicitly included implicit
local state. Such as activation frames. New programming models (or old but
not popular models, e.g. designed for mobile agents) are necessary to
achieve this.
>
> As an aside: The question of whether or not it's possible to dynamically
create objects seems orthogonal.
The notion of "creation" implies local state, from activation records if
nothing else. Dynamic systems can be modeled without local state, but is
closer to discovery and shaping of existing material.
In reactive or live programming systems, we'll want to take extra steps to
ensure stability.
Regards,
Dave
Received on Mon Jan 21 2013 - 03:27:05 GMT