[erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution

Joe Armstrong erlang@REDACTED
Wed Jun 25 20:39:31 CEST 2014

On Wed, Jun 25, 2014 at 6:56 PM, Miles Fidelman <mfidelman@REDACTED>

> Joe, Thanks for the info.  A bit of follow-up if I might (embedded inline):
> Joe Armstrong wrote:
>> On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman <
>> mfidelman@REDACTED <mailto:mfidelman@REDACTED>> wrote:
>>         On Wednesday 25 June 2014 00:09:35 Robert Virding wrote:
>>             I think it is very lucky that we weren't interested in, or
>>             worried about,
>>             the theoretical aspects, or that we had heard about the
>>             actor model. If we
>>             had we would probably still be discussing whether we were
>>             doing the actor
>>             model and which parts of it, or where we differed and how
>>             important that
>>             was? Or should we differ and maybe we should drop the
>>             differences to we
>>             would comply, etc ... :-)
>>             We were trying to solve *THE* problem and this was the
>>             best solution we
>>             could come with. It was purely pragmatic. We definitely
>>             took ideas from
>>             other inputs but not from the Actor model.
>>     Robert, I know it's probably documented somewhere, but...
>>     1. what do (did) you see as "*THE* problem" you were trying to
>>     solve at the time
>> Joe here - I'll dive in with a reply:
>> Bjarne Däckers thesis has a good outline of the problem the thesis is
>> here http://citeseerx.ist.psu.edu/viewdoc/summary?doi=
>> This blog has a good summary of Bjarnes thesis
>> http://jlouisramblings.blogspot.se/2012/10/ramblings-
>> on-thesis-of-bjarne-dacker.html
> Thanks for the pointers - and yes, the blog post is a very nice summary!
> Re.
>      2. what sources DID you draw from (other than the predecessor
>>     languages at Ericsson), are there any that you'd consider primary
>>     influences?
>> Prolog and Smalltalk in equal measure. Pattern matching and syntax was
>> inspired by Prolog. Messaging from Smalltalk. We took a few ideas on
>> guarded commands from
>> Dijkstra.
>>  This is mostly in the form of historical curiosity of course, but...
>  can you say a bit more about the Smalltalk influence, and in particular,
> which version of Smalltalk?  I ask, because:
> - The earlier versions of smalltalk included (at least in theory) a lot of
> concurrency (objects seemed a bit more like actors), whereas later
> versions, starting with Smalltalk-72, pretty much dropped concurrency as a
> focus (there was really interesting exchange with Alan Kay on this, a while
> back, on the fonc email list).

I can't be sure but at a guess smalltalk-80. The version I used was
on a sun workstation and I used to take a coffee break when it garbage
collected. To be honest I was more influenced by the books than the
implementation which was very slow - the red green and blue books
were great reading.

> - During that time period (very early 70s), there was a lot of
> cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER, actor
> model), and Steele and Sussman (Scheme)

(I'm kind of exploring Robert's statement that "I think it is very lucky
> that we weren't interested in, or worried about, the theoretical aspects,
> or that we had heard about the actor model." Particularly, in that Alan Kay
> cites PLANNER as a key influence on Smalltalk.  I'm kind of interested in
> the origins and history of languages that treat processes as fundamental
> units of computation, vs. the object model).

All the smalltalk stuff did talk about "sending messages to objects" - so
in a sense a message passing model - there were a few problems with
this - message passing was really just a disguised function call, and time
and errors didn't fit into the model.

I always thought it was funny to say "everything is an object" - time and
errors don't seem to naturally fit into this ontology - a time value (like
10.45 pm on 12 march 1984) might be represented by an object - but
not time as being something which passes as processes execute - this is
some kind of invisible stuff that is outside the computation.

It's funny that the "sending message to an object" way of describing
Java and Smalltalk, Objective-C, C++ etc. objects has persisted despite the
fact that this is manifestly *not* what happens (which is a function call).

In Erlang we really do send a message to an object (well a process
actually) - so Erlang is probably the only OO language there is :-)


> Thanks,
> Miles Fidelman
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140625/17bb49f2/attachment.htm>

More information about the erlang-questions mailing list