portable perspectives

a blog about programming, life, universe and everything

ECMAScript 4, the fourth system syndrome

The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features.

Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem.

I believe that part of the success of ES in its current incarnation is that it is quite simple. Yeah, it has its shortcomings and oddities, but in general it is simple enough that everyone can learn it in no time.

ES4, on the other hand, seems to have included almost everything that came out from programming languages in the last 50 years, save Prolog and APL.

For example, it has prototypes, interfaces, classes, metaclasses, higher order types and generic functions, which for what I can tell entails all the work ever done on object-orientation (maybe predicate classes are missing, but they may be there too).

The argument list of a function may have named arguments, rest/variadic arguments, optional arguments, optional types including: non-nullable arguments, like arguments (this seems the same as in Eiffel, used to link the type of an object to another), wrap arguments that perform automatic conversion of an object of type X into another of type Y,

Whereas many languages I know provide a concept of Module or Package to handle namespacing issues, ES4 provides packages and namespaces and program units to support name hiding and modularity. Not only this, but you can introduce variables with var to have it in the object scope or with let to have it in a block, so even more namespace separation :-)

Finally, ES4 incorporates some cool features such as list comprehensions, a kind of destructuring assignment/pattern matching, python-like slicing, triple-quotes and generators (though AFAICT this are only one way generators like in older python releases, where you can yield but you can't receive values Thanks to Neil Mix for pointing out that they are complete coroutines, and support bidirectional value passing).

And operator overloading, program pragmas, required tail call elimination, a host of interesting keywords suchy as intrinsic to reify operators, dynamic to have classes that allow adding of new fields, static to have class-level functions, final to avoid inheritance and override to use it, internal, public and so on. And of course, 6 different values of falsity, with NaN, "", 0, false, null and undefined, but not {} and [].

ECMAScript 4 seems cool, I want to use a lot of those things (yay for multi method dispatch!), but maybe it is changing the language a little bit too much .

How many of the current user of ES in one of its incarnations have ever heard of product types? Will they grasp at once the logic behind the subtyping relation between functions, with all that covariant and contravariant stuff? Will they need it at all?

I hope the internet pipes will resist to the number of "metaclass vs meta namespace vs prototype vs superclass" questions on usenet.

AddThis Social Bookmark Button

16 Responses to “ECMAScript 4, the fourth system syndrome”

  1. Neil Mix Says:

    One clarification: generators in ES4 do indeed support send()-ing as in Python.

  2. riffraff Says:

    ah thank you for pointing out I’ll update the post

  3. John DeHope Says:

    I agree. I read the whole EC4 document and kept thinking how cool and, at the same time, over-engineered it was. This is total overkill for browser scripting and will just make things harder, not easier, to script. I just don’t think the browser is where we need this kind of language horsepower. Browser scripting is not a playground for “wouldn’t it be cool if” language designers.

  4. Chris Ryland Says:

    The people doing ES4 have much larger goals in mind: their hope is to generally produce “the next great language” and use it everywhere, not just the browser.

  5. riffraff Says:

    I believe Chris is right, but I believe the approach they are following may be wrong.

    As JS and ActionScript it will keep its “market share” but in environments where it was common and used as simple extension language it won’t fit anymore, maybe. I mean, people already know where to find common lisp and perl6 :)

  6. Thor Larholm Says:

    Chris is absolutely right, the scope for ES4 extends way beyond the browser. Ditch C++, ditch D, ditch Python, ditch Ruby, re-consider C#, ES4 is the language which fits in all the way from natively compiled code to dynamically included language subsets.

    That might be a big mouthful, but, due to the backwards compatibility, any browser scripter can suddenly jump between environments; - the language constructs will be the same, the frameworks/object models will be different.

    Thanks to the language, the language is dead - long live the environment!

  7. Reggie Drake Says:

    If I understand this correctly, ES4 generators, like in Python, have to yield from the generator function itself, and are thus not ‘real’ coroutines – which would also be able to jump to another coroutine from inside a function call (meaning that each coroutine has its own stack).

  8. riffraff Says:

    in python you can yield only to the caller, but nothing prevents you from calling another routine that may be implemented as a generator, which in turn can yield or call something else, so I think this is the same.

    But probably I’m misunderstanding, could you provide an example of coroutine behaviour that is not possible in python?

  9. JFred Says:

    There is an argument for improving Javascript.

    If Javascript performed better and was a tad cooler as dynamic language it could be used as a server side language, not just in the browser. This would be a net win for managing and developing web applications. Only one language to learn. It doesn’t have to be as cool as Ruby or as easy to learn as PHP – people already know it.

    Imagine the win if Ruby on Rails had instead been Javascript on Rails and that, somehow, Javascript was really the right language to do it in. This is why there should be Some Improvement in Javascript.

  10. rektide Says:

    javascript is no longer being used like the little toy language it was so i see no reason to typecast it to a limited light. javascript is growing because the web platform is growing, and the advantage of building a properly encapsulating & extensible runtime far outweight the usefulness of relying on the OpenAjax Alliance to define heuristic implementations.

    we are talking about the next platform. is “next” actually “next” if it has to look like the old? the omission of any questionable features would make this “the same”, not “next”. importantly, very few of these new features will be required for a working mastery of the language: the cost of these features is born by implementors and not programmers whereas everyone would suffer the omission.

  11. Jeffrey Whitney Says:

    I know that some people like the loose typing of JS (duck typing etc) but I HATE that. If it would just do type checking for those variables that I assign as a type, (var x as int), that would give me everything I wanted.

    However, I don’t think it’s a bad thing that they’re making these other changes. I don’t think that we should keep everything dumbed down just because it’s going to be harder for some people to comprehend.

  12. Jason Orendorff Says:

    Yeah, I totally agree–it’s not a car, it’s a super rocket nitro laser monster truck fighter jet.

    The thing is, I think a lot of people will like ES4. The heavy hitters on that committee know a thing or two about technology survival traits. People drive SUVs. If they could drive a super rocket nitro laser monster truck fighter jet for the same price, I think a lot of them would.

    I’ve discovered people give lip service to simplicity, because their lives are too complicated and it makes them suffer; but when it comes down to it, they don’t actually want to simplify.

    So while I agree with you, I suspect I just value simplicity a lot more than the average programmer. We’ll see what happens.

  13. Graydon Says:

    It’s not as bad as you worry. Perhaps I can help?

    The intrinsic, meta, internal, public and such words are just namespaces, helping to organize the spec and standard library. Nothing terribly special. Serious users of ES4 will want to get a handle on the namespace system, borrowed from ActionScript. It’s surprisingly useful. I disliked it at first, but after a couple years toying with it, it feels essential.

    The metaclasses discussed in the overview are really just a specification formalism; they effectively exist in any OO class system with reflection. There’s no user-adjustable MOP or similar magic. We’re just trying to produce a reflection facility on par with where Java got last century.

    We can’t really change the meaning of ‘var’, so ‘let’ is just an upgrade. Likewise we can’t change the lingering ugliness of boolean interpretations.

    The ‘wrap’ and ‘like’ types are weakened variants of stronger type judgments in the type system. They are primarily to help library authors deliver strongly-typed code that can handle incoming calls from untyped code.

    Tail call contexts, function subtyping rules, this sort of thing … they are important for language nerds to study and get right – lest the language be unsound or unpleasantly inefficient – but no normal users will ever learn about them, and that’s fine.

    Generally the direction of the ES4 work has been to import facilities found in other languages that assist in larger-scale structuring and correctness-checking. Nothing that should perturbs the appearance of a small, easily-learned dynamic bit for 1-liners. There are just more places to go if your needs grow past there.

  14. Joe Chung Says:

    I liked ECMAScript 4 the first time I saw it when it was called Perl 6. cough

  15. GoGoGadgeto Says:


    but no normal users will ever learn about them

    as usual ppl will read the code others wrote and as usual if something does work somehow it will be used, no matter how bad designed it looks like.

    Anyway, what I miss there are delegates, templates and those handy Prolog cut-operator include everything it needs :)

  16. Amit Patel Says:

    Javascript to ES4 is a huge leap. However, you should also look at Actionscript 2 and Actionscript 3. It’s not such a big jump from AS3 to ES4. Whereas AS2 is prototype-based, dynamically typed, AS3 is class-based, statically typed, with public/private, E4X, and rest args. It doesn’t have all of the ES4 features but it has many of them.

Sorry, comments are closed for this article.