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 )