> And I am talking about true concurrency not some approximation. So the game
> can have a second paddle that is running on another computer as a way to get
> the game to work over a network.


I would prefer to program this as a list of event handlers.  "When the
ball gets close, do this".  "When the joystick moves, do this".  If I
write each of these as a thread, they will probably end up having an
outer loop which is an event dispatcher!

	[ true ] whileTrue: [
		self waitForEvent.
		self nextEvent dispatch ]

By the way, it is very natural in morphic to program your objects as a
list of event handlers.


So, while I agree that making things psychologically natural is
important, in what cases does concurrency really help?  I've seen an
occasionaly case, but not a lot of them.  And they add headaches when
you start worrying not only about the *state* of another process, but
the *position* in its computation that it might be at.  The argument for
threads often comes from making explicit state implicit in the process's
stack; however, making this actually makes it hardet to understand
what's happening if you end up caring.


-Lex