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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
