Name Soup

There still seems to be an amazing amount of FUD going around regarding the Harmony announcement. There is clearly a very different perspective from those who have been sitting inside the WG for the past year (as Kris Zyp and I have been lucky to). Inside the WG, the change seems a welcome way to break a logjam of reasonably held opinions of people who are all acting in good faith. From the outside, it all looks like confusion and game-playing.

One of the things, though, that keeps getting me frustrated as I read the “coverage” is that the names people use are confused. Probably because the names are confusing. Here’s a quick glossary:

ECMAScript 3

Aka: “JavaScript”, “ES3″, “ECMAScript 262-3″, and “JScript”.

The current JavaScript that every browser implements (more or less). This is the current ratified standard and represents the 3rd edition of the ECMAScript spec. It is very old. Nothing else in this list is (yet) a ratified standard of any sort.

ECMAScript 4

Aka: “ES4″, “JavaScript 2″

A new language which was to be mostly backwards compatible but add optional (gradual) typing and class-based inheritance. Based loosely on Adobe’s ActionScript 3. This is the language effort which died as a result of Harmony.

Adobe’s current JavaScript-like language, only with many features lifted from languages like Java which also enforce types and class-based semantics. This was the starting point for much of the work which became known as ES4.

Tamarin

A JIT-ing byte-code virtual machine (VM) which is at the core of the Flash Player and was donated by Adobe to the Mozilla Foundation. This is the VM that runs ActionScript 3 code today but will likely run “real” JavaScript for Mozilla in the future. It is not a full implementation of ES3 or ES4, but instead implements its own byte-code and needs to be wedded to a “front end” (like the ActionScript 3
compiler from Adobe) in order to be usable by programmers.

Tamarin-tracing

A VM which implements the same byte-code language as Tamarin (known as “ABC”) but which is designed for use in mobile devices and other scenarios where code size and VM footprint are important. It implements trace-tree JIT-ing as a way to speed up hot-spots. Also donated to Mozilla by Adobe.

A new code-name for a language which is to come after ES3.1. It will feature many of the things ES4 was trying to accomplish, but may attempt them from different directions and will
focus much more on incremental, step-wise evolution of the language.

JavaScript 2

A now-defunct name. This name was originally given to Waldemar Horwat’s first proposal at a large-scale evolution of the JavaScript language in 1999. That effort did not succeed (although Microsoft implemented some of it in JScript.NET) and subsequent work via the current TC39 charter to build ES4 has sometimes been given the name “JavaScript 2″, but it never really stuck. Not a name that describes any ratified standard or current proposal.

ECMAScript

The formalized name of the JavaScript language. Since Sun Microsystems owns the name JavaScript and has no idea what to do with the trademark (but has been benevolent thus far), the ECMA committee which standardized the language was forced to adopt a different name.

2 Comments

I may be dumb but I still don’t understand what the nature of the changes that have been agreed to are. If I understand correctly ES3.1 will be implemented in the short term, then Harmony. ES3.1 includes just a set of small changes but the general form of Javascript doesn’t change much. Harmony will then introduce changes to the shape of your javascript code with features like class-based semantics ?

To be honest I would assume most of the people looking in from the outside like me are mostly interested in when it will become easier for them to code javascript by adopting some familiar class-based semantics.

Your first paragraph is spot-on. 3.1 is a very short-term set of improvements and bug fixes to the language while Harmony will be the next version past that.

As for Class-based semantics, I think the big problem w/ what was being proposed for ES4 wasn’t that classes were being made available, it was that they were being shoe-horned into a language which already had classes but no syntax for them and therefore it was duplicating lots of things to add the semantics you’re familiar with. Prototypal inheritance isn’t bad, but it’s not enough. Class-based inheritance and straight-up multiple inheritance has 20 years of being proven to be terrible for many tasks. We need something in the middle, be they “interfaces with bodies”, real semantics for mixins, or Traits.

Regards

2 Trackbacks

[…] Alex Russell has seen the confusion of the many names that were bandied around with the Harmony news last week. There are so many names, that involve specs, projects, and general technical jargon that it can get a little confusing. Alex has made it very clear: […]