Ken --

I want to take that quote (below) literally also. That was my 
original conception of OOP, and we never quite got a Smalltalk that 
could really do it. *Now* is the time, etc.

Cheers,

Alan

-----

At 12:16 PM -0700 10/23/01, Ken Kahn wrote:
>On Friday Andreas Raab did a very good job of explaining some of the
>concurrency issues that were raised by Lex and others. He ended by writing:
>
>>You can write broken code
>>in any language and no environment will prevent you doing that. The
>question
>>is how much does the environment help you to write correct and well-defined
>>code without having to resort to introduce an entire extra layer of
>>simulation?! And that's what I think Ken is after when he's saying that he
>>wants a language that supports both, sequential and concurrent execution
>>"primitively".
>
>Actually I waffle on the question of whether to have any primitive support
>for sequential execution. Here's how I see the tradeoffs:
>
>PRO.
>1. Existing programmers are good at sequential programming and most are new
>to concurrency.
>2. Some problems seem to be inherently sequential. E.g. writing to a file.
>
>CONS.
>1. Conceptually and implementionally it is simpler to have only one
>primitive. Concurrency is the more general one.
>2. Some (most?) problems are most naturally as concurrent. Programmers used
>to sequential constructs will program these problems in an awkward manner if
>the language supports sequential composition. (Mitch Resnick discovered this
>with kids programming in MultiLogo -
>http://el.www.media.mit.edu/groups/el/Papers/mres/MultiLogo/MultiLogo.html )
>
>In designing ToonTalk I decided to only support concurrent computations
>since PRO#1 doesn't apply to children and CONS#1 is important for learners.
>(ToonTalk actually does have support for sequentiality at a small scale but
>this is not very important or general.) Kids tend not to run accross the
>PRO#2 problems. If they are rare enough then the fact that programming such
>things is a bit awkward is a small price to pay for CONS#1.
>
>I tried to find a quote from Alan Kay about recursion on the idea of
>computer itself. I found this in a paper by Andrew Black where he quotes
>Alan as:
>
>   "The basic principle of recursive design is to make the parts have the
>same power as the whole" rather than dividing the computer into "lesser
>stuffs", like data structures and procedures, we should divide it into lots
>of little computers that communicate together.
>
>I want to take this literally. Think of an object as a little computer.
>Except maybe when an object sends a message to self, all message sending is
>to another computer and therefore should be "eventual" - computer/objects
>shouldn't hang just because the object they are sending a message to isn't
>currently ready. (Bye bye call/return.) When a computer/object creates a new
>computer/object the newly created object becomes completely independent. If
>there is any sequentiality in the execution of a method it is minor. If the
>method sends 3 messages and creates 2 new objects then the order those
>things happen doesn't matter.
>
>An alternative model is to have lots of Smalltalk or Squeak systems with
>lots of internal objects running independently and communicating. But this
>is much more complex (CONS#1) and I don't think the benefits (PRO#1 and
>PRO#2) are enough.
>
>Best,
>
>-ken kahn ( www.toontalk.com )


--