My JSConf.US Presentation

@jashkenas was kind enough to let me join him for his JSConf.us session. Here is the slideshare link. I’ll comment on the individual slides below.

Jeremy’s talk was entitled “CoffeeScript as a JS/next”, and I was interested in giving an update on Ecma TC39 Harmony progress, so when Jeremy and I met and caught up during the first day of JSConf, we quickly agreed on a joint session with about 15 minutes in the first half for my stuff.

JS developers sometimes seem afraid of the future, specifically of what browser vendors and Ecma TC39 might do to them! Here I used some inspiring quotes and a practical, three-step process outline to encourage everyone at JSConf to have courage and make their direct wishes known, as best they can. By acting (using CoffeeScript, for example) as well as writing (es-discuss at mozilla.org).

Browser competition is hot, browser vendors crave developers as fans and supporters. This should give JS hackers great power, if they can speak coherently, as individuals and as a group. But it’s important for developers to speak clearly, since TC39 members often listen to their own peers on the committee and in their respective companies more than to the JS community writ large.

Of course “the community” does not speak with one voice. Communities do evolve leaders, and leaders are often necessarily articulate. Also, effective communities produce artifacts such as PrototypeJS and jQuery, which speak in their own ways.

Why does the community matter? One good reason is this: communities facing harsh survival tests (as JS’s has) reward merit better than committees operating under competitive and time pressures.

@andrewdupont observed, in his barn-burner of a talk near the end of JSConf day one, how recent JS standards started as community-project library methods. Often enough, these de facto standards also started out as rough and real, i.e., far from perfect — just as JS did. They had to be user-tested and iterated upon until winning.

I reiterated this point in my talk. TC39 should avoid inventing where it can pave the cowpaths.

The Harmony goals (slightly reworded here to fit on the slide, and for clarity) indeed talk about codifying de facto standards.

The “complex applications” and “libraries” bits suggest programming in the large, implying modules and other Harmony proposals. The “code generators targeting the new edition” verbiage directly invokes CoffeeScript and the many other JS code-generators out there today.

An important point about the Harmony process: you don’t have to wait three years for a finished standard before browsers start supporting prototype implementations of solid proposals. We aim to do how implementors have done HTML5 and the Web API standards — continuous early implementation and rolling standardization. Thus, Proxies in FF4, WeakMaps in Nightly (FF6) releases, etc.

This slide (which builds bullet by bullet in Keynote) is as concise a summary as I could make of the bulk of what is already very likely in the next ECMA-262 Edition, according to the Harmony Proposals wiki page.

We have invested over the years in most of these proposals, not only on TC39 but in SpiderMonkey (with Norris Boyd, Steve Yegge, et al. matching in Rhino), in order to test implementability and usability. Firefox and other Mozilla XUL apps and add-ons make great use of let, generators, and more. We will keep adjusting our prototype implementations to match the emerging ES.next spec.

Now it looks like other browsers will start to implement Harmony proposals. This effort complements the adoption of de facto standard library functions. Some problems can’t be solved in the current language by writing library code. We need language evolution at both syntactic (user interface) and semantic (deep meaning) layers.

David Flanagan’s talk, which was first up on JSConf day one, covered typed arrays and array buffers a bit. During the Q&A I mentioned the Harmony binary data proposal from @littlecalculist.

The binary data proposal embraces and extends the fine work of WebGL typed arrays. Sometimes someone paves the cowpath into an expressway, which grows into a superhighway. JS has a lot of bits to move these days.

I’ve been talking about better function syntax for a while. function is too long (I wish I’d used fn in 1995 and preempted this issue).

TC39 has had several proposals or variations. Meanwhile, CoffeeScript has emerged and taken off. In arrow function syntax I’ve synthesized all the winning ideas, without goring anyone’s ox. This slide conveys the main points of the proposal.

The # syntax from Harmony of My Dreams evolves in this proposal to be an orthogonal prefix, for freezing and joining (fusing identity up to the nearest relevant closure). See records and tuples for analogous hash meaning.

Here I go out on a limb in listing some strawman proposals not yet in Harmony. Some of these will make ES.next, some probably won’t (there will be an ES.next.next).

At this point in my talk, I advocated strongly for standardizing prototypal inheritance a la CoffeeScript’s class, super, and @ syntactic sugar.

TC39 is tempted to “do more”, which means invent (not by committee but by champions, single members or sub-groups working on a particular area). I believe we will not achieve consensus soon, and possibly go wrong, if we overreach.

We could renounce classes in order to remain future-proof, but JS developers are crying out for sweet and (more important) foolproof syntax to make prototype-based single-inheritance class-like abstractions. We should pave this cowpath now.

(Some at the conference tweeted against “classes” thinking this was another turn-JS-into-Java thing, but counter-tweeting made it clear that it’s purely prototypal. What’s in a name? It is hard to beat “class”, IMHO.)

Oh, and paren-free still wins. Where it is not simply a relaxation of JS’s over-bracketed C-based grammar, it gives for-in in loops, comprehensions, and generator expressions not only lighter syntax (and only paren-free syntax!) — it gives better semantics.

Generally, paren-free for-in provides the iteration protocol hook for custom iterators, definitely including generators (the easiest way to write an iterator).

Specifically, paren-free for-in reforms array iteration to be over values, not keys. This is pure win (ignoring migration, see next paragraph), as far as I can tell.

Forbidding parenthesized for-in heads makes a migration “early error”, a tax for a common good: lighter syntax with much better semantics.

JS developers and implementors on TC39 must learn from one another and “meet in the middle”. The Harmony goals are good. But developers may do only what can be done in library code, or reach for CoffeeScript or another language on top of JS. And TC39 may over-invent.

The better way is a dialog between JS developers, especially natural leaders among them such as @jashkenas, and TC39 members.

This won’t involve “scientific polling”. There’s no substitute for nice judgment and (ultimately) sound language design theory and practice. But the experts must also learn from the users, who’ve moved mountains on their own over the last ten years. And users, meaning JS developers, should step up to this dialog and away from fear and passivity.

After our talk, with some fun stage misdirection, Alex Russell and Peter Hallam of Google introduced Traceur, Google’s Harmony-ish transpiler. This is a good development on the whole. I’m happy to see it as a way to test proposals. However, I need to register some misgivings that go beyond “style point deductions”:

• The slides are Chrome-only. Come on, it’s not 1997. I’m using slideshare.net and HTML/PNG. There’s no excuse.
• Some of the extensions are neither Harmony nor Strawman. (In particular for (i : o) was rejected. So was __iterator__.) I hope this can be updated, but if Traceur turns out to support (over the long run, ignoring short-term committee jitter) other than what has been pitched and vetted by TC39, that would be several kinds of wrong.
• Dion’s post was up last night [UPDATE: not pre-arranged, Dion is just very fast even when he’s not actually at JSConf. Sorry, D], yet it says “JS.next” without qualification. My posts, and other TC39ers as far as I know, have been careful to say “experimental”, “proposed”, “possible”, “dark horse”, etc. I personally try to assess odds of inclusion in ES.next based on the Harmony/Strawman process. No such nuance from Dion.
• Narcissus on github is where Mozilla and several academic partners have been working on ES.next prototypes. We’re not as well-staffed as Google, but we’ve done this work in the open and I’ve talked about it since last year. Meanwhile, Traceur was done as “delayed open source”, with the wow-effect JSConf unveiling.
• Ok, to each his own. But the after-show cajoling by Alex to me, along the lines of “come work on our transpiler with us”, left a bad taste. I say: Open-source early, tell your TC39 colleagues your plans and intentions, invite others to join you. Don’t seed the googlecode project with all-Google-employee committers, work for months in relative secrecy, and then go open.

This reminds me of how V8 was developed (I have a few saved emails from 2006… V8 released as open source with Chrome in 2008).

Again, it’s Google’s prerogative to do whatever it wants with its staff and code. But this pattern of secret-first/open-later development is on a slippery slope toward openwashing. That aside, with Traceur it seems “forkish” in TC39 social-cohesion terms.

Another point: a transpiler (syntax only or mostly) or true compiler/runtime targeting JS (new semantics too) is ultimately not enough. Harmony proposals need to be implemented in several engines, ideally including V8, before a new standard edition is ratified. No word on this at JSConf, but I hear good things from others at Google, so I’ll leave this one on a positive note.

Really, I’m not out to break TC39 and Harmony over this. Indeed we haven’t heard anything from Microsoft about what they’re hoping for in Harmony; we have not seen anything like an open source transpiler. So good for Google. But some things about how this came out don’t sit right, enough so that I’m writing publicly.

Jeremy is a star, and I want to thank him again for letting me share his slot. He made a number of excellent points, some intentionally “dialectically sharp”, all encouraging JS developers to use and even implement “better languages” built on top of JS.

The sharpest point in my mind was “JavaScript is too important to be left to the experts.” This is obviously true for several definitions of “experts”, but expertise matters too or we wouldn’t have Jison, the parser-generator used by CoffeeScript, based on Bison and Yacc before it.

Jeremy was dialectically sharp to encourage developers to throw stuff up and see what sticks. Seeing what sticks with a programming language in part depends on user-testing, usability, human factors that are not reduced to science — that is, part of language design is art. He even encouraged people to “cheat when you get stuck”, words I try to live by (after the example of Cadet Kirk).

Now, not everyone is a @WilliamShatner, or a @jashkenas. Many will get stuck, cheat, fail, and cry in despair. Not to be discouraging!

Expertise, even formal methods and people who know them, can help. Zaach‘s Jison is one example. TC39’s generally pragmatic collection of experts, including Dave Herman, Allen Wirfs-Brock, Mark Miller, Sam Tobin-Hochstadt and others, also constitute a valuable resource for the community.

What Jeremy and I tried to advocate, which I believe is happening before our eyes, is a connecting of the circle, from JS as I created it, though its fearless communities and their leaders, back to browser vendors and experts on TC39 — and around again.

We are not just advocating a language on top of JS that you use to avoid JS (GWT, Haxe, Objective-J, etc.). We are advocating that you all help build a better JS on JS, which then becomes standardized as JS.next.

This is important work. I haven’t seen anything like it at this scale, with multiple interoperating implementations. It happens with single-open-source-as-spec languages (Perl, Python, Ruby). With transpilers, better libraries, and de facto, prompt (but not premature) standardization, it can happen with JS, too.

/be