The ECMAScript working group has started working on the next edition of the language. What can they learn from Ruby?
The ECMAScript working group has started working on the next edition of the language.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
The ECMAScript working group has started working on the next edition of the language. What can they learn from Ruby?
This is actually a much more challenging question than it appears at first.
The main reason for this is that it’s been shown to be very difficult to force browser vendors, by way of specification, to implement the pet or favourite features of language enthusiasts, users, other vendors, or academics without very good justifications. This is how we ended up with the ES4 spec pretty much dead on the table, which yielded a much less ambitious (though still pretty awesome) ES Harmony. A language like JavaScript which has such insanely tricky political deployment and implementation issues is simply unable to be the type of awesome experimental playground that Ruby has been for much of its lifetime. Anyone who has followed es-discuss (the ECMAScript language development mailing list) has probably noticed by now that it takes many many months of debate and experimentation to merely articulate and agree upon common language features like, in recent memory, operator overloading, or short form lambda notation.
Perhaps it may be too much to ask of any working group to nail a spec that will target every device on the planet? On the surface it would appear that it’s a very narrow band of lessons, even the social ones, that can be easily transferred from Ruby to the JavaScript.
To that end, and to ease the burden of Brendan Eich and his group:
One of the most urgently useful “lessons” to bring to the language from a perspective inspired by Ruby (or LISP) would be language malleability. The ability to introduce new features, syntax hacks and domain-specific languages not originating from a inner cabal of spec writers would be incredibly valuable. Allow the language to be a good place for modular extensions to the language to be made, and for those extensions to be self-hosted, so as to minimize fragmentation risks and to allow those changes to permeate and be mashed up, etc.
Such malleability would allow the community at large to apply lessons from all sorts of directions and allow the Internet to decide over time which lessons are worthwhile from which language, etc. We’ve already got a high rate of iteration and evolution happening at the other ends of this sandwich, i.e. in browsers themselves (eg: HTML5), and in js libraries. If that was able to happen more intimately at the language level, we could see some very interesting things happen very quickly.
[addendum/edit]:
The language has to be able to morph significantly because a small group of people is simply incapable of anticipating all the things it’ll ever be used for. A theme that comes up on es-discuss often is that underlying current of designing “a language for the next 10-15 years”. IMHO, this is an incredibly unrealistic goal. If you don’t build it, the system will evolve an alternative long before spec’s intended lifetime. With the immense speedup in javascript engine/JIT technology of late, we’re already seeing the early signs of this happening in the form of new languages being written on top of JavaScript or being cross-compiled on the fly into JavaScript. Yep, even Ruby: http://hotruby.yukoba.jp/