I would like it very much if important topics like concurrent and non
concurrent technologies could be substantiated by a bit more than off the
cuff commentary. A few URLs don't take up that much space surely.
Since parallelism it is a subject dear to my heart I'll kick it off with one
URL on Logic Programming. Come on Guys! There are a lot more. Perhaps
someone out there has a single URL to a complete archive.
Cheers
Justin


----- Original Message -----
From: "Alan Kay" <Alan.Kay at squeakland.org>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, October 24, 2001 8:23 AM
Subject: RE: Lots of concurrency


> Ken --
>
> I want to take that quote (below) literally also. That was my
> original conception of OOP, and we never quite got a Smalltalk that
> could really do it. *Now* is the time, etc.
>
> Cheers,
>
> Alan
>
> -----
>
> At 12:16 PM -0700 10/23/01, Ken Kahn wrote:
> >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 )
>
>
> --
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: What are Logic Programming and Prolog.url
Type: application/octet-stream
Size: 180 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011024/c0dce316/WhatareLogicProgrammingandProlog.obj