No JavaScript in all honesty was painful because the way it was designed (it was made in ten days). Equality operator ('==') is a cause of MAJOR headache and so is the global scoping, the bizzaro addition operator, etc.
http://stackoverflow.com/a/9033306 - this "wat" meme is getting old. At best, you people that keep posting this are automatically qualified as trolls. The fact is that probably none of you folks from the "wat" crowd didn't take the time to read the ECMA standard. I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either.
And yes, developing under node is not the same as developing for the browser where you need to use the lowest common denominator, which usually is IE6.
I'd say that the issue is the "omg node.js" crowd that promoted it as the hammer for every issues that may pop out. It isn't. But this doesn't mean that it is completely useless.
Sorry, but please explain how is this issue somehow elevated by node when it is a part of language standard (ECMAScript standard linked in the article it posted)? Does V8 break ECMAScript? This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive.
> I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either.
You failed the read test. Twice. The first was the manual itself.
> please explain how is this issue somehow elevated by node when it is a part of language standard
You failed the read test. For the third time. Please indicate the part where I claim that node elevates the issue vs. standard ECMAScript behavior. I said something about the node vs browser runtimes. This is a totally different beast.
> This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive.
The only gotcha is the coercion that some regard as dark magic vs statically typed languages vs the operators themselves. The "+" and "-" operators in JavaScript: "+" for summing Numbers or String concatenation, "-" for subtracting a Number from another Number (which basically makes it a strict arithmetic operator, you know, stuff for Numbers).
Besides:
- PHP uses the + and - as strictly arithmetic operators (it has the . operator for string concatenation), while summing up two strings equals int(0) since (int) 'foo' === 0: http://php.net/manual/en/language.operators.arithmetic.php
- C (and to some extent C++) uses the + and - as strictly arithmetic operators: invalid operands to binary + (have ‘char ’ and ‘char ’)
Yes, I may have skimmed a little. But this doesn't excuse language makers for not anticipating such a use common case and returning a result that can be said to be expected (i.e. error, trying to add one list on other). If there isn't a real comparison, you should take a couple of people that are likely to use this and say "what should [] + [] return". You can't say that they couldn't have implemented " []+[] " throws a TypeError or something, even in a dynamic language.
It is said that API is UX for programmers. Well this is UX for a computer language. And JS fails at it. Big time. And this isn't the only stumbling rock (see global variables, == operator, semi-colon insertion, etc.).
My point was that developing under Node.js is same as developing under a browser only the lowest common denominator changes to V8.
Edit: I'm pretty sure + operator in Ruby concatenates two arrays.
Couldn't agree more. But that's the standard. At some point I hoped that the ES5 'use strict' would fix all of this SNAFU, but it didn't.
However, not even once I tried to sum [] + [] or {} + {} till that "wat" video. Funny, but unrealistic, therefore: close, but no cigar. One could operate the "World's safest table saw", but the common sense tells us that usually finger vs. saw => saw wins. Safer tools are desirable, but it's up to the craftsman to use them properly.
> the lowest common denominator changes to V8
V8 is pretty much on par with its competition with the ES5 adoption, therefore we can hardly talk about a lowest common denominator that's actually low. The only thing that I actually missed in V8 vs. the Mozilla engines is the support for E4X (which most runtimes don't support anyway).
http://kangax.github.com/es5-compat-table/ - even if IE6 and IE7 are gone from the traffic stats, IE8 is there to stay with the XP users. Some of us still don't have the possibility to just drop those users as long as the analytic data shows a fair share of legacy users.
Ruby isn't part of the "similar syntax" family. The '==' operator isn't recommended in JS (and PHP). In fact, jslint yells at you if you use it. That's why '===' exists. The semi-colon insertion is one of the big failures on the "allowed" part. Wish that never happened. But any developer that doesn't try to adhere to some hipster JavaScript coding style uses the semi-colon at the end of the statement.
I don't find that makes much difference in practice because most developers learn about the good parts of JavaScript early on and so ignore these things.
Yes, the lack of proper standards made it even worse, and yes, JavaScript has 'good parts', but JavaScript is still chockfull of wat: https://www.destroyallsoftware.com/talks/wat
That video is completely misleading due to a quirk of the repl treating {} as a block not an object, not really a language wart.
Try it yourself:
var a = [] + {};
var b = {} + [];
Miraculously they are same (but only because the list is empty, string concat order matters obviously)! The only time that wat can ever happen is a case that would never exist in any actual code. The Dom is full of wat but I still havent seen any legitimate cases in js itself.
