Your comment might be useful or interesting if you explained which WTF moments affected you in particular, or even just which other languages you've used. As it is, it's not adding much to the conversation which is why you've been downvoted.
Most of these WTF examples basically boil down to JS doing type coercion willy-nilly. This 'feature' makes writing conditionals slightly shorter, in exchange for introducing the possibility of massive bugs everywhere in your code at any moment. Seriously, f* JS type coercion.
The other misfeature I hate is that accessing undefined properties doesn't raise an error (then, but you can be sure it will make your program blow up a bit later).
I'm actually trying to write a book about that myself. It's called "JavaScript es basura caliente: Learning JavaScript in Anger".
The goal of the book is not to rag on JS. That's not new or really interesting in its own right. The goal is to walk people through the oddities of the language such as identity loss when passing a function from an object to something else (the good old this == window rather than self).
There are interesting, and annoying, things about JS that are non-obvious to people from a different language like Java or C#. There are other issues like testing and package management that are either assumed or glossed over. The JS community knows about them. Unfortunately for most of us, the responses to the language's weakness and ecosystem strengths are dispersed through the interblogs.
In fact from personal use of JS and some research on the book, I'm moving to a functional approach with JS. OO in Ecma5 is a pain. Pure (or Clojure like) functional can work with a bit of help from Underscore. That pardigm seems to fit the mentality of JS better too.
While these are WTF moments, when is anyone actually going to run [] + [] in a real project? The map to parseInt is the only one that's even close to something you'd actually write.
Writing x + y where x and y are both arguments to a function, and some call site was passed an (empty?) array of integers instead of an integer? Believable.
So the real problem is passing wrong parameters to a function? Sounds like you should swap to something like TypeScript for strict typing then.
Or you know, stop acting like JavaScript is unique in that improper function calling breaks your code.
I can't believe in 2015 there are still people who follow the "JavaScript equalities are WTF" mentality. If you are running into equality operator problems in JS, you are probably going to run into a myriad of problems in any language.
It's not about this causing issues IMO. It's just.. why? Why would '+' not be commutative? Why not throw an error? What is the use-case for "adding" '[]' and '{}'?
Or, put another way: why would a programmer want to have this "feature" instead of being notified: "hey, you're adding '[]' and '{}', that doesn't make any sense, fix that!"
Sure you can work with a language like that. But it sure doesn't feel like somebody thought all of this this through.
parseInt takes two arguments: $thing_to_change and $radix; map iterates over an array and feeds it $value and $index. You're getting parseInt("10", 0); parseInt("10", 1) and parseInt("10", 2);
The fix would be to partially apply parseInt with your defined radix;
var foo = ["10", "10", "10"];
var base10 = function(val){
return parseInt(val, 10);
};
x = foo.map(base10)
[10, 10, 10]
All you have done is used a function without understanding what it was doing, or reading the documentation. Most JS developers know how parseInt works, and even if they run into this problem, would quickly discover the cause. I don't see how this is a flaw of Javascript; it could happen to a developer of any language, if their strategy is 'well, it looks like it'll work'.
I guess my question is: what would have to change, in the last example, to make it not WTF to you? To me it seems pretty straight-forward what is happening.
There is no expected output. It doesn't make sense to subtract the value 1 from the string "wat". But Javascript will cast both of them to numbers, then try to subtract 1 from NaN. However, if you do "wat" + 1, Javascript will cast both of them to strings, and append "1" to "wat".
It's not just the odd behavior, but the inconsistency.
NaN is passed to Array.prototype.join() as the separator to join strings with, so it gets coerced to String ("NaN"). It's deliberately working backward from the behaviour of Array.prototype.join() to create a contrived example for giggles, not a WTF.
Oh, I understand that. I was more trying to explain why someone might think it was a WTF.
And I'm pretty sure your example returns the decimal 15. Comma operator returns the last element in the list, and parseInt will truncate strings with non-number-like text to the number-like part. Here, the number-like part is a hexadecimal code, triggering another feature of parseInt that it can figure out the radix on the fly.