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 ⚥ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
