Dataflow concurrency instead of generators

[Brendan Eich]

On May 16, 2009, at 9:29 PM, David-Sarah Hopwood wrote:

> (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.)

I'm still looking for evidence other than your certainty re: the last  
dispute about semantic cleanliness (by your lights) vs. performance:

https://mail.mozilla.org/pipermail/es-discuss/2009-February/008862.html

When we see SFX (Nitro, heh), V8, and TraceMonkey on board then I will  
be convinced. Until then hand-waves and generalizations don't really  
cut it.


> Remember, I started this thread by arguing against (lambdas +  
> generators)
> precisely because that combination caused a safety problem.

It's already the case that finallys may not run, whether or not you  
add generators and lambdas.


> 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?)

Waldemar argued for reforming function. If we add rest and default  
parameters then there isn't much to do, other than try to force  
Tennent into a language it doesn't fit.


> Note that the fact that a language supports highly expressive
> features doesn't mean that any particular program must or should
> use those features.

Yeah, yeah... There are many bodies, fingers and toes already chalked  
up to this kind of thinking applied elsewhere (C++).

Besides the honey traps, implementation barriers should not be raised  
too high. One good reason to avoid this is to achieve interoperation  
among many competing browser vendors. To pick on C++ again, it took  
too long to get semi-interoperable implementations due in part to the  
complexity inherent in all that expressiveness. There are other  
languages from which to learn the same cautionary tale.


> 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.

On this very general point, we agree.

/be