Aller au contenu | Aller au menu | Aller à la recherche

Bad syntax in Javascript 1.8

Mozilla developers improve day after day Javascript. It's a good thing to improve a language. But I think those who made this improvements in Mozilla should stop smoking the carpet right now.

Improvements in javascript 1.6 (Firefox 1.5) were good, although I'm not a fan to pass a callback function to each array function. I would prefer to have a real support of array with for each statement like the foreach statement in PHP instead of to have this for each statement which return not only elements of the array, but all all the properties of the array object. However E4X was a good improvement in Javascript 1.6.

They began to do crazy things with javascript 1.7 (Firefox 2).

Generators can be useful, but conceptually, it begins to introduce some things that can be disruptive for a "normal" web developer (you know, one of these thousand of thousand web developers who made millions of web site). And it is difficult in a complex function to distinguish a normal function from a generator because the difference is only the use of this small keyword yield.

Iterator is a good thing, but I don't know why we should catch an exception to know when the iterator stops. That sucks. (Interface like PHP iterators is better IMHO).

The goal of array comprehensions is to make easy initialization of array. It would be a good thing if the syntax didn't sucks too.

var ten_squares = [i * i for (i in range(0, 10))];
var evens = [i for (i in range(0, 21)) if (i % 2 == 0)];

Sorry but it is unreadable. Good luck for those who will maintain such code. Look at this example pointed by John that we can do in Javascript 1.8 (Firefox 3):

dict([s, [u for (u in unitlist) if (u.contains(s))]] for (s in squares))

I think this is a good example of unmaintainable code. No specific keywords, no really separators. I'm sure it will be a nightmare for maintainers.

In his post, John Resig shows other things like this horrible "expression closures" feature. I don't see any advantage to write function(x) x * x instead of function(x) { return x * x; }. It is less comprehensive, less readable.

I think only nerds will play with this "features", and "normal" developers and geeks will continue to use javascript 1.5. There is an evidence : in all javascript file of Firefox 3 and other Mozilla products in the trunk, i don't find any use of let, yield or other features of Javascript 1.7.

Glazou gave me only one advantage of this new features : web/XUL developers won't have to use JS obfuscators...


1. Le jeudi, mai 31 2007, 14:12 par zyegfryed

This syntax is very similar to Python...

2. Le jeudi, mai 31 2007, 17:55 par loufoque

Those are just features other programming languages have had for years.
It's not really JavaScript's fault if you're bothered by concepts or idioms any average computer scientist would know, but that are not very known to web "developers" since they're simply not very competent to begin with.

For example, coroutines are a natural way of expressing many algorithms, such as simulations, games, asynchronous I/O, and other forms of event-driven programming or co-operative multitasking.
Generators are just an application of coroutines.

Unmaintainable code can be written with anything anyway, and whether it's readable or not quite depends on the style the reader is used to. The new features introduced don't advocate any form of unsafety so I see nothing wrong with them.

I still find your supposedly unmaintainable code quite straigthtforward. It simply generates a map of squares to a list of unitlists the square is in, by first making of list of pairs (square, the list).
What's elegant here is that it does not generate the list of pairs and then convert it to a map, it actually generates a function (a generator) used to iterate over the list, with its elements computed as needed. That's the new feature called "generator expressions".

About that new expression closures feature, it's just a notation to make writing anonymous functions simply easier and more beautiful, because they are highly common in functional programming.
Of course, if you've never practiced or if you're not used to functional programming -- the fact that you're disturbed by having to pass a function, or a closure rather, to array algorithms is proof of that --, such a shorthand may look useless.

3. Le jeudi, mai 31 2007, 19:03 par benoit

+1 with loufoque

I understand that you may find this syntax obfuscated but mozilla people don't smoke carpet. It's a very classic syntax.