techno.blog("Dion")

Brendan Eich just spelled out the Harmony of his dreams. A state of the union from the language creator timed for when the ECMA TC39 group gathers to hopefully move the ball forward.

This post made me very happy indeed. Over the years I have gotten to the place where I actually really like JavaScript. There are other languages that I may prefer, but I am at peace with JavaScript and its frustrations.

Variable hoisting and this.foo all over? Crazy, but I am fine.

var self = this; or .bind(this)? Whatever.

Module system is tied to script tags? Worked around.

I was right there with ES4 back in the day, hoping to see a bunch of improvements finally getting in to more than Firefox’s type=”". Then the wheels on the bus came off. There were great additions / changes / clarifications, but the typing and namespaces/programing units/packages features? It went just too far.

JavaScript put its tail between its legs and we had to cheer for the small wins of bind() and create(). Fortunately there were huge wins at the VM level. Modern VMs are fantastic, and paved the way for server side JavaScript with Node…. after all of these years.

We need more. There is a responsibility to backwards compatibility that is always brought up. That is important, but there is also a responsibility to moving the Web stack forward. JavaScript has become the glue and power tool of the Web. In theory you can use that type=”" to do more, but getting all of the browsers to implement a language isn’t going to really happen, so we are stuck with JavaScript for good and ill, for the foreseeable future. Let’s make it great.

So, this is why I am so excited to see Brendan talking about how to do just that. There are some classic lines in his post:

You can do anything with function in JS, but you shouldn’t have to — it over-taxes JS programmers and VM implementors to learn and optimize all the idiomatic patterns. Too much like writing with only one-syllable words.

…

I agree with Doug that tail calls would be a win, especially with evented code. The # function syntax allows us to give tail calls a boost and save you seven (14 total: function + return_ – #) keystrokes.

…

Why not bind this to the same value as in the code enclosing the hash-func? Doing so will greatly reduce the need for var self=this or Function.prototype.bind, especially with the Array extras. It’s great that ES5 added bind as a standard method, but why should you have to call it all over the place? If Harmony does not address this issue, I will count that a failure.

…

A hot-button issue with ES5: Object.freeze. Whose side are you on, Batman’s or Mr. Freeze’s? Simplistic to say the least, since even in one’s own small-world codebase, making some things immutable protects against mistakes. Never mind single- and multi-threaded data sharing and other upside.

…

The simple modules proposal, along with its module loaders adjunct, is the likely Harmony module system solution. Note that there is no left-hand side example written in current JS below — you’d need a preprocessor, not part of the language.

Closing Remarks

This is a long post. If you made it this far and take away anything, I hope it is Guy’s “Growing a Language” meta-point. JS will be around for a very long time, and it has a chance to evolve until its users can replace TC39 as stewards of its growth. The promised land would be macros, for syntactic abstraction and extensibility. I am not holding my breath, but even without macros, the Harmony-of-my-dreams sketched here would be enough for me.

We aim to do more than dream. Narcissus is coming along nicely since it moved to github and got a shot in the arm from our excellent Mozilla Research interns last summer. We are prototyping Harmony in Narcissus (invoked via njs -H), so you can run it as an alternate <script> engine via the Zaphod Firefox add-on.

@andreasgal has a JS code generator for Narcissus in the works, which promises huge speedups compared to the old metacircular interpreter I wrote for fun in 2004. With good performance, we can actually do some usability studies of Harmony proposals, and avoid Harmony-of-our-nightmares: untested, hard-to-use committee designs.

A code-generating Narcissus has other advantages than performance. Migrating code into Harmony, what with the removal of the global object as top scope (never mind the other changes I’m proposing — here’s another one: let’s fix typeof), needs automated checking and even code rewriting. DoctorJS uses a static analysis built on top of Narcissus, which could be used to find flaws, not just migration changes. Self-hosted parsing, JS-to-JS code generation, and powerful static analysis come together to make a pretty handy Harmonizer tool. So we’re going to build that, too.

More on Narcissus and Zaphod as they develop. When the time is right, we will need users — lots of them. As always, your comments are welcome.

I am sure some programmers will feel like they just read Crock’s good parts and finally get JS…. and now it will change? I remember the days where my() seemed so foreign as I put on Perl5 (and it took me a bit to really grok my vs. local [and we have var vs. let now]). There are so many times where I dislike change, but then in time the changes become habit and I wonder how I lived on the other side.

It is time to re-tool.

I am finding that I really enjoy CoffeeScript. I find it fun to use. I am happy when using it. If core JavaScript can give me much of that, I will be very happy indeed.

I may disagree with some of the TC39 decisions, but I just hope that they make a big push to do bold things at this time. The time is now, and it is great to see signs of hope:

Good news everyone! typeof null == ‘null’ might actually happen.