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.
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).
Typescript helps to solve both.
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.
var foo = ["10", "10", "10"];
foo.map(parseInt);
// Returns [ 10, NaN, 2 ]
[] + [] // ""
[] + {} // {}
{} + [] // 0
{} + {} // NaN
var a = {};
a[[]] = 2;
alert(a[""]); // alerts 2
alert(Array(16).join("wat" - 1) + " Batman!");
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.
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.
I can't believe in 2015 there are still people who follow the "invalid input should produce invalid output" mentality.
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]These aren't my examples. I haven't done anything. I credited the person who provided them: Gary Bernhardt.
https://www.destroyallsoftware.com/talks/wat
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Next time before you make an accusation, reread the post before pressing the reply button.
I assume the expected output is "wa" but why should a string less an integer produce that?
It's not just the odd behavior, but the inconsistency.
I like javascript but I don't do anything so complicated (or maybe not the right types of things) that I run into many of these situations.
It's no more a WTF than this, which follows the same principle: https://gist.github.com/insin/1183916
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.
https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...