On Tuesday 23 October 2001 03:42 pm, you wrote:

> A long time ago, I did an experiment with asynchronous message sending
> (see http://www.advantive.com/squeak for the code) where you could have
> any number of people catching and throwing baseballs with one another.
> A shared queue represented a uni-directional path between any two
> people.  I implemented a syntax that looked like "anObject asend
> someMessage" to actually do the asynchronous messaging.  It was very
> neat to simply inject a baseball into one of the queues and see (via the
> transcript) the players start catching and throwing the baseball between
> each other.  You could also inject multiple baseballs (oh, and they were
> good baseball players because they never dropped any of the baseballs).
> I never created any morphs of the players, but it was neat anyhow.
>
> I could have created this simulation with the base Squeak Process and
> synchronization code, but the implementation of asynchronous messaging
> made the simulation extremely simple to create.  I didn't have to worry
> about creating or forking processes and all of that nonsense.

	Cool, nice idea!

	Wow, I actually understood that, and well, it's quite awesome.

	I think the reason most programmers have problems with concurrency is that 
they are raised on languages that stress linear thinking, and sequential 
processing.

	Someone who learned LISP first tends to see everything as functions, and 
recursion.

	Someone who learned C sees everything as sequential ( you can do some 
concurrent programming in it, but it's a PAIN, even the 'simple' cases ).

> - Stephen


	I've seen ToonTalk, and I like it's almost pure concurrentness. It comes 
down to thinking about programming as a 'team effort' or cooperative, I guess.

	Hmm, anyone write a FFT in Toontalk? :D

	It's a good algorithm for parallelization.

	Daniel Joyce