Dataflow concurrency instead of generators

[David-Sarah Hopwood]

Brendan Eich wrote:
> On May 16, 2009, at 5:50 PM, David-Sarah Hopwood wrote:
> 
>> Bear in mind, though, that adding message passing significantly
>> increases the expressiveness of the language, so we should take that
>> into account when comparing the complexity of (lambdas + generators)
>> with that of (lambdas + dataflow concurrency + message passing).
>> The latter is much more powerful.
> 
> Who says lambdas are "in"?

The above argument applies equally to a comparison between just
(generators) and (dataflow concurrency + message passing).

(But I would be very disappointed if Harmony doesn't end up with
lambdas :-)

> Who says power is the good to maximize?

Expressive power isn't good to maximize if it is at the expense of
safety or the ability to reason about programs (preferably using
local reasoning whereever possible). However, if it is feasible to
increase expressive power *without* compromising those properties --
as I believe it is in this case -- then yes, I think that's definitely
a good thing.

(Implementation complexity and performance are also important, but
personally I consider them to be lower priorities than safety and
expressiveness -- especially since safety often has a lower performance
cost than many people believe.)

Remember, I started this thread by arguing against (lambdas + generators)
precisely because that combination caused a safety problem. So we
have no disagreement on the principle that unsafe combinations of
features should be avoided even if they would be highly expressive.
We disagree on whether the identified problem is best avoided by
ditching lambdas (and replacing the lost functionality with what?)
or by ditching generators (and exceeding their functionality using
dataflow concurrency and message passing, neither of which interact
badly with lambdas).

Note that the fact that a language supports highly expressive
features doesn't mean that any particular program must or should
use those features. A program that is restricted to only using
features that are necessary to solve the problem that it is supposed
to be solving, will probably be easier to understand, debug, and
maintain. This is essentially the "Principle of Least Expressiveness"
discussed in the book "Concepts, Techniques and Models of Computer
Programming". However, programming in a highly expressive language
that supports multiple programming paradigms (but designed with
considerable attention to maintaining safety properties) makes it
easier, not harder, to follow this principle. And maybe JavaScript
just isn't cut out to be that language, but I'd like to at least
have a stab at making it closer.

-- 
David-Sarah Hopwood ⚥