[E-Lang] E FAQ

[Mark S. Miller]

At 11:55 AM Friday 9/28/01, Ken Kahn wrote:
>For ToonTalk I don't have to be concerned much with a "severe loss of
>familiar guarantees" since for my users nothing is familiar and there is
>nothing they need to "relearn".

Agreed.  I purposely phrased things in terms of the costs of "relearning". I 
remain hopeful that a fresh audience, such as yours, may find purely 
concurrent pure Actor-like programming as easy or easier to learn as 
sequential programming.  In a way, I think of Toontalk as Actor-like 
programming packaged for people who haven't learned to program, and E as 
Actor-like programming packaged for people who have learned to program, but 
in a conventional (sequential imperative) fashion.


>But I'm not convinced in the general case (E and Mozart/Oz). Earlier this
>month I was visiting with some of the Mozart people at SICS and this topic
>came up frequently. The Mozart people were supporting MarkM's argument.
>Here's my (biased) summary of the argument:
>
>Without language support to express sequential computations programming
>becomes awkward. But how awkward? The consensus was that you can easily
>express it using two extra arguments [...]

Again, I am *not* saying that purely concurrent programming is inherently 
more awkward, harder to learn, harder to use, etc..  I have said on this 
list many times that I, personally, prefer Joule to E.  Rather, I am making 
a marketing observation based on the installed base of programmer brains. 
When I said "fatal", I should have been clear I was talking about a 
marketing cost, not a technical cost.

Look at Walnut and imagine how the book would have to be written if it had 
to explain these extra two arguments before the reader could again write the 
kinds of simple programs they are familiar with. Imagine how the Ode would 
have had to be written, and how much longer it would have been, if we first 
had to explain a different concurrency model.

Yet even a fatal marketing cost is still fatal.  Witness the extraordinary 
influence of Scheme, and the extraordinary success (in aggregate) of Scheme 
and languages descendent from Scheme.  While at the same time, Scheme's 
ancestor, Actors, together with all Actor-like languages, have in aggregate 
been almost invisible, even to most of Scheme's gurus.  I believe Scheme's 
support for conventional sequential imperative programming was crucial for 
it to gain its audience.  I don't believe it was any claimed technical 
superiority of Scheme over Actors.

For the future, just as C++ provided a bridge C programmers could cross into 
the world of objects, enabling better oo languages to take over; so E's 
success may provide a bridge that may eventually enable the pure Actor-like 
languages to finally get the audience they've always deserved.  E's 
successors may very well be its predecessors.


        Cheers,
        --MarkM