[e-lang] Events as Bad Ideas

[Mark Miller]

Jonathan S. Shapiro wrote:
> But Ousterhout's key argument concerned complexity, which is something
> that von Behren, Condit and Brewer don't address at all. In failing to
> address this, they are arguing against a straw man, not against
> Ousterhout.

 > Rather, he
 > claimed that for the vast majority of cases where threading was actually
 > getting used, it wasn't the right tool for the job. The difficulty is
 > that generalized concurrency is well beyond the capabilities of most
 > programmers.

Yes. To my mind, this is the strong argument for events. Events are high level 
isolated serializable units of operation. (The "I" of ACID.) With threads, the 
unit of operation remains instructions, memory accesses, and critical 
sections. With threads, for large applications and realistic amounts of 
programmer effort, it is essentially impossible to both maintain consistency 
and avoid deadlock. With high level events, it is easy to both.


> What E does, which is (so far as I know) unique to the E/Joule line of
> work, is directly integrate dataflow and event-driven dispatch into the
> language architecture in a coherent way.

Actually, Actors, the concurrent logic/constraint languages (like FCP and 
Vulcan), and Joule all have this in common.

 > My own feeling (and I think
 > MarkM would agree) is that the Joule approach is theoretically better
 > integrated, but its cost is that it visibly violates the programming
 > paradigm, which makes it a very tough sell. E chooses to introduce
 > dataflow in a different place, and the result is much more usable.

Close. Taken by itself, E's dataflow is rather similar to that of Joule. What 
is unique to E, AFAIK, is having event-oriented control flow and traditional 
sequential/imperative control living together smoothly in a single language. 
If you remove "." from E, it resembles a pure Actors language (it especially 
resembles Joule). If you remove "<-" from E, it resembles an object-oriented 
variant of sequential Scheme. Doug Barnes' great discovery, in inventing E, is 
that "." nests within "<-" without conflict.

The thing that makes E more learnable than these other event-oriented 
languages is that programmers can get started by writing mostly sequential 
programs, as they are used to, and gradually take on the event paradigm as 
they are ready for it.

This is perhaps much more than a pedagogical strength.

E's events can be larger, and are often much larger, than the individual 
events of programs in these other event-oriented languages. By nesting "." 
within "<-", i.e., by allowing an individual event to consist of a 
conventional call-return program, E gives the programmer tools to create 
practical high level units of operation that often better match the 
abstraction level of the problem they're solving.


>>>"Common event patterns...map cleanly...onto threads...They 
>>>need a return event on the event model." We agree that a 
>>>return is needed, and this is where the promises come in...
> 
> Oddly enough, it looks like Coyotos is going to abandon this. It turns
> out that you *don't* need a return. What you need is the ability to
> transmit a capability on which the returned message should be sent. You
> also need a way to invalidate this efficiently.

Do you think the technique you're using (which I'll leave it to you to 
explain) would be suitable for general use writing complex applications? Do 
you believe it should be directly supported by a general purpose programming 
language? (The possibility hadn't occurred to me before, and it's intriguing.)


> In my opinion, the one interesting concurrency mechanism that E lacks is
> an event queue that is shared across multiple co-equal vats. This is
> exactly the same problem that KeyKOS/EROS have in the current
> call/return design.

I don't understand.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM