JavaScript 2: Everything but the Kitchen Sink
Welcome to the next generation of JavaScript! The ECMAScript Edition 4.0 (ES4)Working Group has been hard at work and on Oct. 22, 2007 put out an overview. Their proposals give new meaning to the concept of “kitchen sink” and “design by committee”. The only thing they forgot was to rename the language Javathon++. Luckily, ES4 is no more likely to take root than the previous abortive proposal issued in 2003.
Classes. The ES4 spec grabs the pre-reserved “class” keyword and uses it to, uh, define classes. All good and fine, but it’s just syntactic sugar replacing the current var CLASSNAME=function() {} idiom. Of course we have subclassing in the form of class BetterC extends C, but people have been doing this for years with existing functionality in JS1 . And of course we have “final” classes. I suppose that could lead to better performance in some cases in a JIT environment. We also have static class variables, but we already knew how to do that. And lest we forget, we have interfaces a la Java.
Types . We’ve got types everywhere, including in weird Pascal like function declarations: function foo (string) : boolean. ES4 goes on and on: unions, named types, non-nullable types, subtypes, type comparisons, casts and wraps and conversions, type-based catch clauses, even parameterized types! If we’ve got types, we can do polymorphism! Guys, if I’d wanted a typed programming language I’d have chosen one to start with.
Namespaces, packages and units . In the so-called “programming in the large” category, we have namespaces, even though all current serious JS programmers and library builders already implement robust namespace management using existing JS facilities. Of course, if we have namespaces we need new syntax for declaring things to be in namespaces or specifying the default namespace to use. We’ve got packages and hey, we can import them with cool new keywords to do so. And there’s more: packages are then bundled into “units” which need more machinery to define and import.
Just plain weird. One of the most bizarre aspects of the new spec is this:
If the body of a function definition or function expression is a single expression whose value is returned, then the braces enclosing the body and the return keyword may be omitted. This tends to reduce clutter.
Example: function square(n) n*n // a definition
This is madness.
Pythonites on the committee manged to slip in triple-quoted literals, “destructured assignments” ([a,b]=[1,2]), and array slicing. What, no indentatation-based program structure?
I must applaud a couple of small points in the spec. First, trailing commas are now allowed in object literals: {a:1, b:2,}. Readable regular expressions are also a Good Thing.
Languages have identities, they have personalities, they have philosophies. Revving the language spec is all about respecting and extending that identity and personality and philosophy. One need look no further than Perl 6 and Python 3 for good examples. ES4, by contrast, is Frankenstein’s monster.
October 27th, 2007 at 20:11
The “Just plain weird” objection to syntactic extensions needs more than expostulations about madness. Try expression closures (in Firefox 3’s forthcoming beta), you will like them.
Here’s another clue: Python had nothing to do with the destructuring assignment proposal, which was implemented in Opera before it was submitted to the group (destructuring has a long provenance in ML and other languages; the idea did not begin with Python, which anyway calls it “unpacking”).
About your “If I’d wanted a typed programming language, I’d have chosen one to start with”—did you really “choose” JS? In browsers there is no choice, and however much you detest types (don’t write them if you don’t want to, type annotations are optional), others absolutely will use them. Especially at API boundaries, in lieu of piles of error-prone and bulky argument and result checking/normalizing code.
The thread at http://lambda-the-ultimate.org/ is worth a read in full, if you are willing to give ES4 half a chance. If you simply prefer to keep using JS as it is, no problem. Your choice will not be diktat to everyone, however.
/be
October 27th, 2007 at 20:22
One more point: class is not equivalent to prototype/closure-based OOP in JS today. There is no way today to make an instance that is sealed against mutation by addition of new properties. The private properties you can create by capturing constructor closures, e.g., is costly and verbose to write (besides being alien to most programmers—many can learn, but the other costs hurt; why be different?).
For high-integrity abstractions that can compile to the metal, classes are the right fit, dogmatic objections aside. My point here, though, is that it simply is not true that class in ES4 can be simulated in ES3/JS1. Simulated in some ways, but mutation in JS1 is a bitch, and class controls it along several axes.
/be
November 5th, 2007 at 05:48
Funny, our user choice will not be “diktat” to everyone but yours (brendan’s one, as the father of the language) will “diktat” our use of the language. You keep saying everywhere that’s everything in ES4 is optional. But in reality it is not, your are just creating a lot more of confusion and code nightmare with ES4.
ES4, IMO, is not needed, a much better thing would have been to adress the issues in 3rd edition.
This is madness. Sorry to say but you, at the TG1, are turning a simple language to a confusing one.
[bar,foobar] = [function(z,x) z*x, function() 666];
function foo(x) x * bar(x,foobar())
Total madness, confusing like hell.
December 4th, 2007 at 16:48
laurent V.: you are faking confusion, and not fooling anyone. Your examples prove my points: 1. You know how to write ES4 without confusion, and read it. 2. You chose to write the new forms, but you are not required to — they’re optional, backward compatible extensions. Cut out the crocodile tears and intentional use or abuse of new forms, and you have no objection.
As for addressing issues in the 3rd edition — we’re doing that, we have a list of bug fixes to track what real browser implementations do, or where those disagree and ES3 still was broken (two cases of note), to do something better. See the compatibility doc at http://ecmascript.org/ and quit whining :-/.
/be
December 4th, 2007 at 16:55
I should add that your example is fine JS2, closer to Python or Scheme than the JS1 version:
bar = function(z,x){return z*x}
foobar = function(){return 666}
function foo(x) { return x * bar(x,foobar()) }
Now why are those curly braces and return keywords, and two lines instead of one for the bar and foobar assignments, so necessary once you learn about destructuring and expression closures? Learning new shorthands is sanity, not madness. But to each his own.
BTW, JS1.8 in Firefox 3 supports your version already. Run and hide! 😛
/be