On Thu, Jan 17, 2013 at 4:26 PM, Ross Bencina <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.
>
> 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. Inconsistency robustness (which seems to be Carl Hewitt's main
platform of late) is quite poorly argued for the scales relevant to most
programs.
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?
>
> 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. But it does imply that
there always exists some supervisor to whom the state is visible and
accessible. 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.
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.
--
bringing s-words to a pen fight
Received on Fri Jan 18 2013 - 03:28:09 GMT