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.
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.
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.
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 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.