Agreeing completely with the above comments (complex systems will be
composed of cells not clocks), let me add that a professional
programmer/ engineer/ scientist always does the the "simplest thing that
could possibly work". (Reference: XP  and TDD.)  Complexity will evolve
by "natural selection"; complexity by "intelligent design" is almost
always wrong.

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Gary McGovern
> Sent: Saturday, May 08, 2004 10:46 AM
> To: squeak-dev at lists.squeakfoundation.org; Lothar Schenk
> Subject: Re: Distributed intelligence or not
> 
> 
> Thanks, that's an interesting book to read. My question came 
> from a program I made before I knew how to make an object. It 
> was a hangman applet. It had a ui class and a domain class. I 
> treat the methods in the domain class like objects. I thought 
> the methods were objects. I've just been changing that applet 
> to object style, and I'm realising that it is more 
> complicated to write that way, maybe overly complicated for 
> what the program does. This swarm stuff seems it might be a 
> step up into more complexity. So more to learn........ Thanks, Gary 
> 
> 
> >Gary McGovern wrote:
> >
> >> I'm struggling a bit at the moment, trying to justify distributed 
> >> intelligence in program design. Or if centralised is better, or 
> >> whether there should be a shift between centralised and 
> distributed 
> >> depending
> u>pon
> >> the nature or size of of the program/system. Maybe it is 
> because what 
> >> I>
> am
> >> mostly doing is small - writing centalised seems quicker 
> and simpler 
> >> to write. And distributing the intelligence I do because 
> it is good 
> >> form ->
> my
> >> course texts say do it. Maybe in the long term it works better.
> >
> >Doing something just because someone else says so is never 
> >satisfactory, even if it should work. Usually, there is a reason why 
> >certain things are recommended, and this reason can be examined for 
> >validity. Often this examination reveals specific conditions under 
> >which a certain course of action is valid and also when it is not.
> >
> >With regard to your question, you may find it worthwhile 
> reading Kevin
> Ke>lly's
> >book "Out Of Control", which deals with what he calls "vivisystems",
> arti>fial
> >systems that are modeled after the way biological systems function. I
> fou>nd a
> >reference to this book on Ted Kaehler's web site, and a 
> little bit of 
> >web>
> 
> >searching revealed that it is available online in its entirety here: 
> >http://www.kk.org/outofcontrol/contents.php
> >(I just ordered my printed copy via amazon, too.)
> >
> >One interesting point he makes (which apparently also gave 
> the book its
> t>itle) 
> >is that massively parallel self-organizing processing 
> systems will, at
> th>e 
> >extreme end, be de facto uncontrollable systems, at least 
> not in the way
> >we 
> >can control the linear sequential systems we have known so 
> far. Here's a 
> >quote:
> >
> >"As our inventions shift from the linear, predictable, 
> causal attributes
> >of 
> >the mechanical motor, to the crisscrossing, unpredictable, and fuzzy 
> >attributes of living systems, we need to shift our sense of what we
> expec>t 
> >from our machines. A simple rule of thumb may help:
> >
> >      For jobs where supreme control is demanded, good old 
> clockware is
> t>he 
> >way to go.
> >
> >      Where supreme adaptability is required, out-of-control 
> swarmware is>
> what 
> >you want.
> >
> >For each step we push our machines toward the collective, we 
> move them
> to>ward 
> >life. And with each step away from the clock, our 
> contraptions lose the
> c>old, 
> >fast optimal efficiency of machines. Most tasks will balance 
> some control>
> for 
> >some adaptability, and so the apparatus that best does the 
> job will be
> so>me 
> >cyborgian hybrid of part clock, part swarm. The more we can discover
> abou>t 
> >the mathematical properties of generic swarm processing, the 
> better our 
> >understanding will be of both artificial complexity and biological 
> >complexity."
> >
> >Regards, Lothar
> >
> >
> >
> >
> 
> 
> 
>