On 18/01/2013 2:27 PM, David Barbour wrote:
>
> On Thu, Jan 17, 2013 at 4:26 PM, Ross Bencina
> <rossb-lists_at_audiomulch.com <mailto:rossb-lists_at_audiomulch.com>> wrote:
>
>
>
> 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.
>
>
> One would be wrong to do so. Reality is mostly a pain to manipulate. Of
> the things in reality we consider 'usable', most are achieved by at
> least thousands of hours of design, many require hours of training, and
> very few are composable into larger usable artifacts. Reality imposes
> many physical concerns and constraints that are difficult to address.
>
> Realism also doesn't help with intuitions - not when by 'realism' you
> mean probability, relativity, or quantum mechanics. Further, people have
> all sorts of misleading intuitions. The notion of 'objects' being
> something that exists outside our head (as opposed to being a function
> of perception and cognition) is one of the intuitions that misleads many
> developers today.
I can see where you're coming from, and these are fine arguments. From a
high level human-factors perspective I completely agree with you.
Perhaps your ideas also make sense at other levels (see discussion of
"global" below), although this is less clear to me.
I do think it depends one's goals. If the goal is to engineer efficient
systems* then I think economy of materials needs to be included in the
picture -- and with it this brings constraints of the real -- that time
is local and local information is acessible and remote information must
be fetched.
[*] by efficient, I mean economical use of resources including: atoms,
electrons, time.
> People certainly *have* argued that the absolutist model is
> unscalable. Asynchronous CPUs and the inconsistency robustness
> movement are two examples.
>
>
> Asynchronous CPUs (cf. Karl Fant) reduce a dependency on CPU clock, but
> still support deterministic and real-time software. It isn't clear to me
> why you'd consider them a counter-example to whatever you mean by
> absolutism.
I chose absolutism as an antonym to relativism. A counter-example to
absolutism might be software that doesn't try to paper over the
realities of systems that we actually use. For example, with regards to
cache coherence, consider this:
David Ungar et al, "Inconsistency Robustness for Scalability in
Interactive Concurrent-Update In-Memory MOLAP Cubes"
https://docs.google.com/file/d/0Bykigp0x1j92YWU3ZjlhNmMtNjc5NS00NTgzLTk1NmMtODBkZjIzMjQ4ZTBi/edit?hl=en_US&pli=1
The paper describes an approach where cache inconsistency is accepted as
part of the system behavior, rather than trying to impose an unrealistic
"absolutist" consistency on the cache through synchronisation.
Another example of asbsolutism vs relativism would be this:
Absolutist: pretend that RPC is a synchronous function call
Relitivist: use asynchronous send and receive primitives
> 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?
> Global state certainly does allow for notions of distance and
> disruption -- but fundamentally the idea of global state is absolutist.
>
>
> 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.
> 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.
>
>
> I may be willing to sacrifice a little efficiency in order to predict
> and control performance, hide latency, and improve resilience and
> consistency. Even better if there is some promise of regaining that
> efficiency to larger-scale features (e.g. optimization, speculative
> evaluation, memoization).
>
> 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.
>
>
> 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).
"""In computer programming, a global variable is a variable that is
accessible in every scope (unless shadowed)."""
http://en.wikipedia.org/wiki/Global_variable
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.
It seems like you are using "global" in a similar sense to saying that
"a processes address space is global." Which it is.
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.
Perhaps the distinction you're drawing is based on who is accessing the
address space and how.
You used an example something like:
x = new Object();
It really depends on how you read this as to whether x is local. I
suppose you're thinking of something like "within the formal semantics
of programming language X."
Taking an imperative, running program view: To begin with, x is not
being materialised out of thin air, it's being allocated out of the
global process address space. Further, it is being allocated by an
implict (but none the less existant) allocator, who can record who
allocated the object, and there's nothing stopping me enumerating all
objects allocated or even (with certain allocator modes) discovering
who/where it was allocated. Search the address space to discover all
references to the object.
In this sense, all objects are already global. Granted, not all language
environments give access to the whole address space, nor do all
allocators type-tag the allocated blocks.
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.
As an aside: The question of whether or not it's possible to dynamically
create objects seems orthogonal.
> But it does imply
> that there always exists some supervisor to whom the state is visible
> and accessible.
I see. Assmuming a relatively unoptimized view of the program, that's
already the case. There is a memory allocator. Maybe it's just a matter
of not allowing "raw" object allocation and retrofitting the memory
allocator with inspection capabilities (as many allocators already are).
Perhaps activation frames also need to be first-class objects.
Another realated existing approach is the Factory design pattern.
> It also means that state is never anonymous (e.g. via
> 'new Dog()'). There may be state resources that 99.9% of the time are
> effectively used as local. Support for the remaining 0.1% makes a rather
> pervasive difference.
As an aside: dependency injection is often used to avoid creation of
anonymous/inaccessible local state. The DI people seem to agree with you
and see this kind of anonymous state is very evil.
> Also, global visibility does not imply contention. It does imply the
> *potential* for contention. Actual contention depends on actual sharing,
> which depends on architecture. Architecturally, we can often share much
> beyond 1:1 without creating bottlenecks, e.g. might have 3:5 sharing for
> a particular resource.
Good point.
Ross.
Received on Mon Jan 21 2013 - 01:44:54 GMT