- I think additional complexity needs huge justifications
- I’m suspicious of claims that anything should be added because it will improve the sales pitch
10 December 2007
Why I fear complexity in EcmaScript 4
Various thoughts I had whilst reading Brendan’s @media Ajax Keynote.
I don’t see why every EcmaScript programmer can’t learn to use closures and prototypes. These are not difficult concepts, yet they are extremely powerful.
Of course, if the new stuff is really less verbose and less error-prone, I’m all for it. It’s better, however, if any more concise and less error-prone elements are built on top of existing features rather than introducing new features.
The thing that worries me about adding classes to EcmaScript is that it increases the complexity. An increase in complexity in software means an decrease in stability and a decrease in security. For EcmaScript, it also means raising the barrier for implementing and maintaining the language.
Less complexity means that implementors can take time to do things like removing the memory leak bugs from their closure implementation rather than wasting time adding essentially duplicate features and, by the way, implementing those poorly as well. It’s not that I’m afraid I’ll be forced to use new features that I don’t want to. I want new features, and I want to use them! I’ve been writing software long enough to know the dangers of complexity, though. Features have to over justify the complexity they bring.
Better to add macros that allow more concise syntax to use existing features than to add features because you don’t have macros.
Putting more burden on people writing static analysis tools is exactly the wrong thing. EcmaScript needs to encourage lots of static analysis tools. And, by the way, the less complex they are, the better they will be as well.
I’m all for evolution. I certainly think things can and should be made better. But I want it to be better. I think I mostly agree with Bredan except:
Subscribe to:
Post Comments (Atom)
5 comments:
Hi Robert, a few thoughts:
You seem to equate additions of things like classes, or generally an increase in size, with complexity. I pointed to Guy Steele's "Growing A Language" talk, and cited cases where JS1 is more complicated because it tries to hide classes under the hood.
About "sales pitch", I'm once again less clear than I mean to be: no one is trying to sell JS2 to Java users. Java users want Java, and if they want to program the browser in it they'll use GWT. My point is that the Web is the biggest market of them all for programmers, and GWT is not going to meet all needs of the middle of the bell curve (or middles -- no single cohort there). Java U. does not train users to write idiomatic functional JS.
My final point is that idiomatic functional JS is often far from "simple" -- it can be hellishly complex. Ask anyone who has created a closure-based memory bloat bug, or mixed up scope chains due to the unclear syntax of things like the Module Pattern.
New syntax and semantics can definitely simplify common "patterns", another point I made by citing Peter Norvig's presentation, from when he was at Harlequin (Dylan shop). There's more to simplicity than JS1-style forced minimalism, and more to complexity than just blaming Java's woes on any kind of nominal type system (classes).
/be
I'm honored you took the time to read and respond to my comments, Brendan. Let me say up front that my blog is just whatever is on my mind, and that I have a lot of trust that you and the rest of the EcmaScript group are smart people who are going to do the right thing.
The thing that I get from "Growing a language" is that it would be better to add macros to the language first so that users can expand the language themselves. While you can argue that classes let the users expand the language, it's in a much less flexible way than macros. And macros would allow people--I think--to build their own class system and experiment with different class systems. And aren't macros exactly the feature needed for simplifying common patterns?
I don't know that I equate complexity with "size". When I say I fear complexity in the EcmaScript, I mean I fear anything that makes the language itself more difficult to implement and maintain. Implementors of the language already seem to have a hard time getting it right. I want lots of high-quality, compatible, well-maintained implementations. I want lots of high-quality, well-maintained static analysis tools. Anything that makes implementing the language or writing static-analysis tools more difficult--I want a very significant pay-off in return.
Wouldn't macros provide a more significant pay-off than nigh any other feature that could be added?
But, as I said, I trust you will do the best thing despites any doubts I might have about what I'm reading.
While there are certainly things I don't like about the language, I have been surprised that I've learned to love it now that I've had to do a significant amount of work in it. While I can't always use Scheme or another language of my choice for something, EcmaScript is something I'm actually required to use and is almost as good. (^_^) So, I thank you for it.
Macros would reduce the syntactic sugar in ES4, but macros are *research*. Indeed Dave Herman of Northeastern University is working on macro soundness; there are also ES4 challenges due to the C-based syntax heritage.
I hope macros will show up in a future edition, and much can be recast using them, but we should not delay ES4 and wait for Dave's research to be completed.
/be
I have to admit that the C-based syntax of EcmaScript has been comfortable for me. I’ve wondered, however, how big a factor that has been in its success. I suspect the biggest factor by far has simply been that it was built-into the browsers. Would it have been just as successful with different syntax?
C-like syntax is huge, in the opinion of many -- see, e.g., Stevey's NBL post. I've told the story many times of how the only constraint on JS's design from Netscape management was "it has to look like Java".
LISP the acronym says it all (Lots of InSignificant Parentheses); Pythonic horizontal whitespace sensitivity is HTML- and minify-hostile. Anyway, I stuck to the mgmt requirement. But I think Stevey has a point. We can't run reality backward and try a different experiment (alas!).
/be
Post a Comment