What can JavaScript learn from Ruby?

Question

The ECMAScript working group has started working on the next edition of the language. What can they learn from Ruby?

Answer 1

Having a name that sounds like a gemstone is much better than a name that sounds like a skin disease.

But don't name your new language after today's hottest thing (that's how we all got into this "Java"script mess in the first place....)

Answer 2

This is actually a much more challenging question 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/

Answer 3

Embrace function programming, don't try to bury it in static language constructs

Answer 4

I can't see to much that it could learn from Ruby. The standards group has already given the language a mean to do resend messages, or messages to the protoype. The method_missing functionality might be cool to implement, but it isn't as necessary as better refelction facilities.

Answer 5

build a standard library around the heavy use of closures, both for collection iteration and for the acquire resource/yield resource/dispose of resource pattern. that's one of ruby's biggest wins, imo. of course, part of what enables this is the brilliant decision to give every method one 'free' closure parameter, with syntactic support, so it's probably not going to look as nice in javascript. the techniques are still useful, though.