21–30 of 58 posts
Common confusion has to do with how JS overloads the "+" operator. '9' + 1 = "91" +'9' + 1 = 10 It's all very weird though...
What would you expect string + number to do?
This article is written like these flaws in javascript are just a quirky feature. No, they are an embarrassment. They don't make the language cool or interesting, they aren't tricks. They are logically incoherent nonsense.
" ['1', '7', '11'].map(parseInt); For what you would expect the output to be: [1, 7, 11] However, things get a bit off here, and the actual result is: [1,NaN,3] At first, this may look up very weird, but it actually has an elegant explanation. " The elegant explanation is that JavaScript was taken over by psychopaths like bajcmartinez. JavaScript is fine for button onClick code. Outside of that it's garbage.
Later formal standards created the “use strict” feature which alleviates a lot of problems.
Earlier quoted context omitted.
What would you expect string + number to do?
Kind of depends on the language. Perl converts the string to an integer if you use a math operator on a numeric string. Python just throws an error.
2 + 2 == 4
2 . 2 eq 22
use warnings FATAL => qw(numeric)This code snippets are the JavaScript equivalent of the Obsfucated C contest: amusing for insiders, a source of smug satisfaction for language warriors, and ultimately of no consequence to day-to-day practitioners. There is a relatively small list of "gotchas" in JavaScript that stem from the early days of the language. They are easily avoided. Use a linter, "use strict," use ===, and be explicit about your type conv…
I'm not saying these issues make the language unusable, but you've got to be a bit more honest that you were if you want to be taken seriously.
This code snippets are the JavaScript equivalent of the Obsfucated C contest: amusing for insiders, a source of smug satisfaction for language warriors, and ultimately of no consequence to day-to-day practitioners. There is a relatively small list of "gotchas" in JavaScript that stem from the early days of the language. They are easily avoided. Use a linter, "use strict," use ===, and be explicit about your type conv…
I have a bit of a hard time with you there, I like to use maps in my code and trying to map a parser over a list of strings and getting the wrong answer is far from 'of no consequence' to me. I'm not saying these issues make the language unusable, but you've got to be a bit more honest that you were if you want to be taken seriously.
Earlier quoted context omitted.
I have a bit of a hard time with you there, I like to use maps in my code and trying to map a parser over a list of strings and getting the wrong answer is far from 'of no consequence' to me. I'm not saying these issues make the language unusable, but you've got to be a bit more honest that you were if you want to be taken seriously.
But you're not getting the wrong answer, it's doing exactly what it should do. That one isn't really even a weird language quirk like the others. It's just assuming you're not aware that parseInt can take a 2nd argument
I use map() all the time but I didn't know about that until I read this article. I wonder why map() functions this way in Javascript and if any other languages pass additional values like this in their own map() implementations.
I do think GP has a fair point of criticism - at least when I use map() I expect it to take each value in the array and pass it to the callback function. I don't expect it to take each value in the array, the index of that value and the entire array and pass all of that to the callback function instead.