Check out David Reed's 1978 MIT thesis "NetOs" about just such issues.
Cheers, Alan ________________________________ From: David Barbour <dmbarb...@gmail.com> To: Fundamentals of New Computing <fonc@vpri.org> Sent: Wed, July 27, 2011 12:54:48 PM Subject: Re: [fonc] Physics and Types Very nice survey, Chris. Thank you for it. Many people consider that 'reversibility' will become hugely important for pushing hardware and software much further, e.g. with respect to energy conservation, which is important for pushing computers ever smaller. An excellent paper on this subject was on LtU not so long, which you linked but did not relate to reversibility: http://lambda-the-ultimate.org/node/4120 . It also describes some of the other systems you mention (e.g. billiard ball computers). Casey, Physics has a very large influence on a lot of language designs and programming models, especially those oriented around concurrency and communication. We cannot fight physics, because physics will ruthlessly violate our abstractions and render our programming models unscalable, or non-performant, or inconsistent (pick two). But we want programming to be easier than physics. We need composition (like Lego bricks), integration (without 'impedance mismatch'), open extension, and abstraction (IMO, in roughly that order). So the trick is to isolate behaviors that we can utilize and feasibly implement at arbitrary scales (small and large), yet that support our other desiderata. Language design is, in a sense, related to physical engineering. My language design has been inspired by physics in the following properties: * temporal semantics; explicit model of time [1] * continuous timed values, i.e. ability to model analog phenomenon. * fields; each behavior is a potentially infinite 'field' that can only be sampled at specific 'points'. Simple variables are modeled as fields with only one point: `()`. * observer-effect; sampling a field can influence it, there is no 'const' accessor. This is actually the basis for all communication and side-effects in my model. [2] [1] My impression, when I studied physics, was that time is an illusion, experienced by an observer due to relative motion. But it turns out that programming in terms of behavior over time (temporal semantics) is a lot easier than programming in terms of relative motion (e.g. actors model), especially for consistency. I initially had some concerns about 'relativity' (the fact that different observers have different clocks), but I eventually resolved these concerns by use of a 'duration-coupling' constraint. [2] Observer-effect is inspired more by psychology than by physics, but the physical relationship holds. The idea is that systems under observation can behave differently based on the pressures, expectations, or demands of their observers. Chris, On Wed, Jul 27, 2011 at 10:41 AM, Chris Warburton <chriswa...@googlemail.com> wrote: Locality: Mentioned in passing for relativity, but locality is a very >useful property that holds for most Physics: stuff happens because of >stuff nearby. This seems an incomplete observation. If we include 'physics' itself in the equation, we could make different things happen by adjusting the rules governing them. I.e. behavior happens because stuff exists in a governing field or environment. A common problem encountered in developing OO simulations, games, etc. is that we ascribe rules directly to the objects, then later find the model inflexible and stubborn when we want to tweak the rules. We can solve this by modeling each object with a reference to its environment, but the abstraction seems wrong - the idea of a bunch of objects 'voluntarily' obeying a rules set doesn't seem much like physics at all! In computing this would be the equivalent of "globals >considered harmful". I understand space and connectivity to be distinct concepts. Globals are more of a connectivity issue (i.e. controlling coupling and propagation of effects) than a space issue. Object capability model, for example, eliminates globals without modeling space. In a, dare I say theological, alternative, the all-powerful text editor seeks to position each and every character using its ineffable algorithms, and is thus impossible to reason about because one cannot know the mind of the text editor. > In between, characters are positioned based on a set of simple rules and constraints provided by the text-editor or an intermediate 'canvas' object. >As far as something like a type system based on Physics goes, I think >that would be a bit messy. Linear types are one of the physics-inspired abstractions that work quite nicely. And I suspect physics could severely affect how we model state, error handling, and incremental computation. >Physics tries to work out the inconceivable ways that the Universe actually >behaves by systematically throwing away all of our intuitions that turn out to >be wrong. With a computer system, we want the opposite; we want a system that >requires as little study as possible, and for which our intuitions are >accurate. > Agreed! Programming to be intuitive must: (a) be relatively simple, (b) easily become familiar with exposure, and (c) be exposed to developers from a young age. Point (c) suggests a good programming model should be very effective for modeling, mashing, and extending UI, multi-media, augmented reality, command-and-control, and games. I think dataflow programming, including support for control signals, is the only general class of paradigms that comes close. And my particular brand of it is most promising ;-). Regards, Dave
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
