>All natural systems are heavily coupled -- it is only that the coupling
>is usually indirect or mediated in some (sometimes elaborate) fashion.

This is what I was getting at. Natural organisms are coupled in a very
different way to most programs. Each component is connected to each other
component INDIRECTLY, via its immediate neighbours. Like a school of fish or
a flock of birds - each animal only noting the proximity and speed of those
immediately surrounding it. But in Smalltalk, how many objects would assume
knowledge of say, the collection or stream protocol? It would be interesting
to see, for each Class in the base image, how many other classes the class
depended on to get its job done. Layering helps to restore some locality and
reduce coupling, but organisms are just superb at completely encapsulating
themselves. As an example, how many classes would break with my new
holographic monitor with it's 3 dimensional screen and mouse coordinates?

>Highly coupled local systems of cells and symbiotic/parasitic organisms
>are the way the game is played. A few million molecules of a single
>chemical released into an organism can enhance or destroy its function -
>or simply make it nauseated or sleepy. Millions of very different cells
>are simultaneously responding, each in its own fashion, to the exact
>same "message".

This is a very important point. Each cell has access to the environment at
all times, and responds to it at all times (concurrently). This is what is
missing in the e-environment. The PostOffice event system I have been
writing is a good example. Every object now depends on, (is coupled) to this
new Object. This is bad programming. In the real world, locality would do
the job. An object would make a noise, and its immediate neighbours, simply
by their proximity in the environment, would be aware of it. Maybe the
complexity arises because we have to simulate the objects AND their
environment, whereas biological organisms don't have to create their
environment, only respond to it.

>The objects and structure in Squeak can be thought of as both the
>environment and the organisms within it (the separation of the two is
>largely artificial anyway). Each object has certain behaviors, which
>with other objects and their behaviors can begin to create their own
>microenvironment - and can perform in concert with to accomplish certain
>larger more complex tasks -- an application is in a sense a
>multicellular organism (or an organ): the coupling inside it is tight,
>the coupling outside it is much looser. But not zero - the app uses
>resources from its environment - which likewise defines and constrains
>much of the app's final form, appearance, and functionality -- and the
>app also adds new resources to the environment by its existence, and
>changes the environment a little to suit itself a bit better in the
>process. The new objects and new behaviors now become a resource in the
>environment for other objects and developing apps to use (like elephant
>dung :-b). Refactoring simply makes the building blocks simpler and more
>generally useful to other objects - other organisms; refactoring evolves
>and refines behaviors. In Squeak the fundamental basis of "life" is not
>DNA but _behaviors_, which are contained inside of and define objects.
>Think how much faster evolution could work if discrete behaviors could
>be mixed and matched, added and subtracted directly.


>The real source of hard coupling in Squeak/Smalltalk is not in the
>fundamental object/message concept, nor in the class/inheritance
>structure, but in the specificity of message sending - *an* object sends
>*a* message to *an* object which must return *a* result. THIS is where
>the limitation is. This is what makes coordinated system-wide behaviors
>so difficult - why large-scale emergent behaviors from tiny low-level
>behaviors are so hard to create. Objects should swim in a flowing river
>of messages, responding to those they understand, ignoring those they
>don't, adding their own messages to the river as they wish. Some groups
>of objects - organisms/organs - surround themselves with a membrane -
>filter/interface - to only allow certain sorts of messages through:
>those meaningful to the organism as a whole, not its individual
>parts....


This last idea I really like. What we need to do is focus on simulating an
'environment'. Every action performed by an object (they all need to be
running independently and concurrently) goes via the simulated environment.
This breaks the hard coupling of *a* message to *an* object. The simulated
environment decides which objects will be affected by the action and lets
them know in an appropriate way. Naturally, just like the real environment,
the simulated environment should be infinitely complex and ever changing...
I'm sure Dan could knock something together over the weekend :-)

The more I think about this, the more I am starting to realise how
insightful the asynchronous messaging in the original Smalltalk was.

>I do love blue-sky conceptualizing. :-)


Ditto - back to some real work...

Peter