Hi Ken,

Just out of curiosity:
> And I am talking about true concurrency not some approximation.

What exactly designates "true" concurrency? Considering that we're still
talking about sequential execution on some processor it seems hard not have
"some approximation".

Similarly:
> I'm one of those radicals that prefer programming languages that only
> support concurrent computations. Sequentiality isn't hard to
> program in a concurrent language while concurrency can only be
> simulated in a sequential language.

Wouldn't it be more adequate to say that in a true concurrent language you
can only _simulate_ sequential execution?! Also, what makes you think that
it's easier to simulate sequentiality in a concurrent rather than
concurrency in a sequential language?!

Cheers,
  - Andreas


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Ken
> Kahn
> Sent: Monday, October 15, 2001 11:11 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Lots of concurrency
>
>
> Marcel Weiher wrote:
> > >I am still not quite sure for what specific problems large numbers
> > >of processes are a good solution.  Computing propagation patterns
> > >on-the-fly and interleaved with the computation carried out by the
> > >message payload may be one case, but many/most practical cases seem
> > >to be solvable without the need for concurrency.
> >
> And Alan Kay responded:
>
> > It's not so much about concurrency as about environments. And it's
> > not so much about solution as realization.
> >
>
> Many things can be programmed without concurrency, just like
> all things can
> be programmed without objects. Concurrency is not just a way
> to deal with
> networked or parallel computers but is also a way of thinking about
> computation. When I show young children how to build a
> Pong-like game in
> ToonTalk it seems so natural to think of the ball, paddle,
> and score keeper
> as concurrent processes. I think it is even natural to have internal
> concurrency in those concurrent objects. E.g. the ball has a bouncing
> behavior that is running at the same time as a behavior that
> makes a sound
> when it touches anything.
>
> 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'm one of those radicals that prefer programming languages that only
> support concurrent computations. Sequentiality isn't hard to
> program in a
> concurrent language while concurrency can only be simulated
> in a sequential
> language. And I prefer simplicity to having a hybrid language that
> primitively supports both.
>
> The main justification for object-oriented programming is
> that it gives
> programmers a way to think about computation that has some
> cognitive/psychological advantages. Those advantages derive
> from the fact
> that we nearly always think about the world around us as
> objects. (There are
> exceptions like clouds, swarms, and waves.)  Similarly the
> world around us
> is concurrent. When I look out my window I see trees swaying
> the wind. I
> know the trees are growing and doing things like
> photosynthesis. I hear a
> dog barking, birds flying, and cars driving past. And I know
> that there is
> lots of internal concurrency in the car: the wheels turning,
> the various
> processes inside the engine, etc.
>
> Where does call/return fit into this picture?
>
> Best,
>
> -ken kahn ( www.toontalk.com )
>
>
>
>