Lots of concurrency

Alan Kay Alan.Kay at squeakland.org
Thu Oct 18 14:55:32 UTC 2001


Ken and Lex --

This is pretty much how Playground (the kids' programming system we 
made (mainly Scott Wallace starting with a framework built by Jay 
Fenton) for the Vivarium project) worked as well -- though I'm sure 
it wasn't as clean as Ken's stuff (this is why I'm trying to convince 
him to put some of his ideas into Squeak).

Playground was kind of a generalized event-driven system that had 
objects which were kind of like a collection of generalized 
spreadsheet cells, completely concurrent, etc.
      This gave the kids state of objects to look at, but not 
call/return. Every value was a thread.

(I loved to program in it, but I thought that, in the end, it was a 
little too pristine for 9 year olds -- it was a little too much like 
pure lisp functional programming in how clever you needed to be. The 
cleverness was rewarded by beautiful, simple, and powerful programs, 
however.)

      In the recent etoys experiments, we got interested in a little 
more mixed style, and this seems to work much better with the several 
hundred or so kids we've tested it on. (But one should not draw too 
many conclusions from most successes (or most failures) in this area 
(because there are so many artifacts that make it difficult to know 
what is actually happening).)

Cheers,

Alan

-------------

At 10:18 PM -0500 10/17/01, Lex Spoon wrote:
>  > Event handlers have lots in common with what I'm suggesting. Here are
>>  differences (though I admit I have yet to look at Morphic carefully and plan
>>  to):
>>
>>  1. All communication is asynchronous. This would translate into never using
>>  call/return message sending but instead posting events and have event
>>  handlers.
>
>Nice...
>
>>
>>  2. Morphs are tied to graphics - I'm suggesting a general style of computing
>>  that includes graphics but also quick sort and bank accounts.
>
>Cool!  And why not, after all?
>
>
>>
>>  3. Every object is a "thread" as you suggest. I'm agnostic about whether the
>>  iteration is implicit, iterative as in your example, or tail recursive (as
>>  is the common programming technique in concurrent logic programming).
>
>Treating threads as your objects sounds like a nice approach.  It
>certainly makes parallelism a fundamental feature of the language!
>
>
>>
>>  4. I'm a bit unclear about how you would express "When the ball gets close,
>>  do this".  Does each object periodically check its distance from the ball or
>>  can it register and be notified?
>
>The nicest way would be literally, you write down something like:
>
>	(ball distanceFrom: self) < 10  ===>    "...do this..."
>
>This is extremely tough on the language implementation, though, so in
>practice, you might just check very frequently, as you suggest:
>
>	(true)  ===>
>		(ball distanceFrom: self) < 10  ===>    "...do this..."
>
>
>Either way, notice that there's this pattern of "when this happens, I
>run this handler".  There is an infinite loop around the whole program,
>but the programmer doesn't have to write it down.
>
>
>Now here's where I get a little lost:
>
>
>>  I agree. Mixing concurrency and shared state causes headaches that we all
>>  want to avoid. My answer is that there is no shared state and no process
>>  state (there is no *position* in a computation to worry about - remember I'm
>>  getting rid of sequential composition). There are just concurrent objects
>>  that send messages asynchronously. E.g. actors. Though I'm arguing for
>>  something a bit more flexible than actors where there can be multiple mail
>>  boxes, where mail boxes are first class, etc.
>
>
>I don't see how this can work in practice.  For a simple example, how
>would you do BouncingAtomsMorph in your system?  In Squeak, each atom
>currently has a position stored in an instance variable -- i.e., state.
>How do you get rid of the state in something like an atom bouncing
>around?  Move it into the messages?
>
>How does an atom decide when it is close to the edge of the screen and
>needs to bounce into a different direction?  And for bonus, how do atoms
>infect each other, i.e., how do you tell when two atoms of different
>color are near each other?
>
>
>-Lex


-- 




More information about the Squeak-dev mailing list