[e-lang] Events as Bad Ideas
markm at cs.jhu.edu
Sun Nov 28 14:05:27 EST 2004
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
> 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
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
More information about the e-lang