JavaScript harmony

I guess we should note the attempts to smooth over the split amongst implementers that is going down in the JavaScript community with the Oslo Summit and Harmony trying to bring back peace. All programming languages are politics. The attempt to do the right things runs into competing interests and debates over what is the right thing to do. The split in the JavaScript community has been apparent now for a while, with the incrementalists wrapped up in version 3.1 and the more ambitious wrapped up in 4.0. Here's hoping that the wheels don't fall off. From a programming language standpoint, the particulars aren't as interesting as observing how language evolution takes place.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

So basically the idea is to

So basically the idea is to keep JS a niche language for the web (quite a big niche... but you get my point), at the expense of features that would make it better suited for general purpose programming. Specialization is clearly one dynamic pattern in PL evolution.

Big niche an oxymoron?

JS is being used for general purpose web app programming (see Google Gears and the WHAT-WG APIs in modern browsers, which include SQLite now!), and increasingly for crazy 2D and 3D graphics bit-banging. Also some browser-based crypto. These workloads are a rising tide.

/be

I was merely echoing you

I was merely echoing you ("Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony")...

(It has been observed in the past that my humor, especially when I am in sarcastic mood, can be confusing, especially in written conversation.)

Not the droid we're looking for

Packages and namespaces are not the module system that the Web needs. No one can unseat the <script> tag for things like URL addressing, sync vs. async loading, DOM presence, etc. That's outside the language. But in the language, in the CDATA content of each script tag, JS desperately needs an optional module scope, with some way outside the module to require what is provided by the inside code.

Namespaces and packages are not this, and namespaces also require some kind of implicit module- (script-)based prioritization or reservation system. Otherwise you can get foo::baz and bar::baz conflicts across script tags that open foo or bar and define baz, then use baz without the prefix. Clearly, the first script (using just foo) is not ambiguous, and it would like its name judgments to be invariant, even possibly early-bound at compile time.

But without a module scope of some kind, foo can't defend against bar. Which could mean that any foo::baz where foo is open and baz is defined must reserve baz in all subsequent namespaces. A similar problem exists with subclassing and namespaces.

Also, as I noted, down-to-earth browser implementors object to the third dimension of name lookup added by namespaces and the 'use namespace' pragma (first two are scope and prototype chains).

Anyway, I did miss your humor, but it's clear the "unsound for the Web" line can be misinterpreted, and I wanted to shed some light on this point. Namespaces faced real problems, which ActionScript 3 in Flash solves with some kind of hidden module prioritization scheme, I'm told. ES4 never had a proposal along these lines, although the program units idea came close.

One of my goals for Harmony is to solve the "module" problem that the core language should solve: how to defend various kinds of judgments against the ever-extended top-level. LtUers should be thinking PLT and TypedScheme about now... ;-)

/be

solve the "module" problem

solve the "module" problem

Big sigh of relief here.

Main motivation: Avoid Needless Complexity

Chris wrote:
> From a programming language standpoint, the particulars aren't as
> interesting as observing how language evolution takes place.

Actually, in this case both are quite interesting.

Ehud wrote:
> the idea is to keep JS a niche language for the web [...], at the
> expense of features that would make it better suited for general
> purpose programming.

No, this isn't the idea at all. Rather, the idea is to avoid needless complexity, and to realize as good and simple a general purpose programming language as we can within the constraints imposed by legacy compatibility. The legacy problems were an even bigger impediment than our internal politics. If there are any unique lessons to be learned from this experience, that's the first place I'd look.

Many people have contributed to finding a simpler language than, for example, the draft ES4 design from a year ago. Doug Crockford was the first to sound the alarm about the complexity of this design. For myself, my key points are summarized at Insurrection, Classes as Sugar, and Namespaces as Sugar.

A wise person once said "When someone tries to buy a shovel from you, remember that they may really want a hole in the ground." The way I see it is that the ES4 folks really wanted some syntactic conveniences, but thought they needed new semantics to get there. The ES3.1 folks were desperate to prevent needless growth of the semantics, and so dug in our heels on new syntax. Brendan, to his great credit, realized how to bridge that difference and bring about Harmony.

I went into this process skeptical about design by committee, and everything I've seen has amplified that skepticism. However, I was also skeptical about whether out-of-control standards processes can be rescued. At least at ECMA -- which moves by consensus, not majority -- I now see that they can. If simplifiers at other out-of-control standards bodies like the W3C can learn from our success, the technical world could become a much better place.

A wise person once said

A wise person once said "When someone tries to buy a shovel from you, remember that they may really want a hole in the ground." The way I see it is that the ES4 folks really wanted some syntactic conveniences, but thought they needed new semantics to get there.

Well, I don't think that's accurate, nor the implication that the ES4 group suddenly realized that "hey, all we need is this hole in the ground". It's more like, "we wanted the shovel, but it turns out it weighs 500 lbs, so maybe a hole in the ground is good enough." The 'intrinsic' namespace, for example... we aren't going to get those benefits from just new syntax.

Don't get me wrong, (h|H)armony is a Good Thing. But we wanted more than just a hole in the ground.

ES3.1 has new semantics

I would like to point out that ES3.1, which really only appeared as a spec draft this year, has grown some meta-programming APIs under the Object constructor-as-namespace that expose or add semantics not available in past editions.

So it's not really true that "no new syntax" (which became, with Mark's help, "must parse in 3 of 4 top browsers") meant no semantic extensions.

It's true the extensions are mostly straightforward, but they are not different in kind from differently-modeled extensions in ES4. For example, the [[Flexible]] attribute is ES1-3's DontDelete, inverted and with restrictions on its state evolution; Object.seal is similar in effect to ES4-as-proposed's notion of fixtures. However, ES4 namespaces were a big semantic extension, but they're out now and this was key to Harmony.

Mark's links to his es4-discuss@mozilla.org posts are worth reading, but be sure to read all of the followups. The whole story is more than one that can be told by congratulating ES3.1 people (and me) exclusively. Lars Thomas Hansen of Adobe (originally of Opera when he started working in TC39) deserves a lot of credit too, and his name is on the ES4 overview document. Waldemar Horwat of Google, to whom I handed the keys to the JavaScript kingdom at Netscape in 1998, has been a big help to all of ES4, ES3.1, and Harmony.

The politics of Harmony are threatened when history is revised to put all the virtue on one side. None of us likes unnecessary complexity. The trick is finding the simplest solution that is not simplistic.

Still, Harmony will endure in my view. The polarization between "no new syntax, now or ever!" and "Next Big Language" has ended without precluding the language from evolving beyond its current syntax and visible semantics.

This means changes for all the players on the committee. Even Doug Crockford said something nice the other day about an ES4 proposal (rest parameters and the ... [spread] operator). That's a big change from 2007's "We reject ES4 in whole and in part". :-)

/be

broken link

Here's a working link.
ES4 seemed to have a terrible case of kitchen sink syndrome, but Javascript Harmony seems a lot more reasonable.

Links will be fixed

Sorry, the list was renamed from es4-discuss to es-discuss, but the old archive directory was not symlinked. Hoping to get that fixed ASAP.

/be

Links fixed

Sorry again for the temporary outage.

/be