threads

Alan Kay Alan.Kay at squeakland.org
Sat Feb 16 14:24:41 UTC 2002


At 11:57 PM -0500 2/15/02, Bijan Parsia wrote:
>On Fri, 15 Feb 2002, Alan Kay wrote:
>
>>  Bijan, as you say, Erlang programming is very similar to Smalltalk-72
>>  programming, since message receiving is implemented in much the same
>>  way (and both are derived from a kind of coroutine structure on
>>  something like a closure).
>
>Hmm. The part the felt similar to me is the parsing of the messages in a
>kind of case structure. AFAICT, Smalltalk-72 used synchonous calls (at
>least, you return to the sender, just like in Smalltalk-80). Whereas, in
>Erlang, the only way to get stuff back to the sender is for the sender to
>include it's id in the message and for the receiver to explicitly send the
>message back.

The inclusion of the sender in the message (actually in the message 
send) and access to both the static and dynamic chains were how 
control structures were implemented a la Dave Fisher.

>
>I was reflecting on the problems you discussed at various points of each
>class inventing syntax in Smalltalk-72, and wondered why it doesn't seem
>to be a problem in Erlang. The answer seems partially to lie in the fact
>that Erlang isn't as systematically message oriented. Though concurrancy
>is built in and well integrated, you can do a fair bit in Erlang with
>purely sequential code (i.e., there's a reasonable functional programming
>langauge in there, next to the message passing stuff). Plus, you build
>messages fairly explicitly, rather than casting all syntax into the
>message passing mold.
>
>That being said, I don't quite get all of the Smalltalk-72 model, though
>I'm diligently (for me) perusing the manual :)
>
>I'll also note that SOAP, the non-rpc bits, are *very* message
>oriented. The W3C use case document recently put out has some nice
>examples of "thinking in the inbetween, at the messages" stuff that you
>sometimes talk of. Alas, I think this will go past many folks (web
>services, faugh!).
>
>Cheers,
>Bijan Parsia.


-- 



More information about the Squeak-dev mailing list