It was for a similar reason that many people used to like XHTML over HTML. Not always because they needed to validate it, but to please the computer.
Yes.
Because programs, unless they deal with machine learning, statistics or other intentional approximations, deal with _strict_ things.
If you put $0.5 in an account you don't expect to find $0.2 there when you read it back or find "Hi Jim" there. You expect to find $0.5, when you seek to byte offset 19553 in the file you expect to read starting with byte 19553 on next read not "something in the vicinity of byte 19553".
[] + [] should not be '', never, it never makes sense, it is not brilliant it is rather profoundly stupid.
Ok, language is broken, we established it, let's take a look at the library functions. At least there cooler heads prevailed:
$ node
> [1,10,9,-3,-4].sort()
[ -3, -4, 1, 10, 9 ]
> [1, 4, 9].map(sqrt)
[1, 2, 3]
> ['1', '2', '3'].map(parseInt)
[1, NaN, NaN]
I'm not actually all that impressed by this illustration of Javascript's equality rules. This makes it look crazy when in fact it just gives the many edge cases much stronger visual weight.
The truth is, Javascript has lent strongly toward being natural in many of the most common cases -- things like being able to do `args = args || []` or simply prepending `!` to anything. Then, sometimes when you end up comparing NaN to undefined you aren't sure what the result should be or how you ended up there.
Funny thing is that often when I've run into those problems myself, I pull on the thread and find it was really caused by my own poor design somewhere else.
They do? How can I stop them all?
Programmers want code to be readable to an IDE.
IDE's can parse, interpret, precompile, and suggest.
Languages that are very wishy washy and dynamic like javascript are absolute hell for an IDE.