Disclaimer: I don't know Javascript, but that's why: > ['1','7','11'].map(console.log) 1 0 [ '1', '7', '11' ] 7 1 [ '1', '7', '11' ] 11 2 [ '1', '7', '11' ] [ undefined, undefined, undefined ] > parseInt(1,0) 1 > parseInt(7,1) NaN > parseInt(11,2) 3 The correct way is: > ['1','7','11'].map(x => parseInt(x)) [ 1, 7, 11 ] same as: > ['1','7','11'].map(x => parseInt(x, 10)) [ 1, 7, 11 ]
What does parseInt work with a radix of 0 but not 1? Neither really makes any sense.
Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
71–80 of 163 posts
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#72This is not one of the weird things about Javascript. When you use a function (like map), always check the documentation to know its behaviour and don't assume it's similar to some similarly named function from another language. End of story.
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#73Earlier quoted context omitted.
So it's clickbait?
The article is not clickbait but the takeaway is easily misinterpreted. Instead of "JavaScript is such a weird and confusing language" it should be "a lot of people are using JavaScript without understanding the method signatures of commonly using methods".
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#74Earlier quoted context omitted.
Once you work with several languages it’s really hard to keep track of all this stuff. I never know what exactly evaluates to true vs false in PHP or JavaScript for example. Add to that sloppy programmers on your team who don't check their assumptions it’s really easy to have a ton of subtle bugs in your code.
> I never know what exactly evaluates to true vs false in PHP or JavaScript for example. You don't have to know if you don't use implicit type-casting. Make it explicit and you won't really have to worry about it. "Explicit is better than implicit" is part of the Zen of Python for a very good reason.
Correct. Unfortunately a lot of people use implicit casting a lot and have no idea that that's what they are doing.
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#75This is not one of the weird things about Javascript. When you use a function (like map), always check the documentation to know its behaviour and don't assume it's similar to some similarly named function from another language. End of story.
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#76Earlier quoted context omitted.
This has nothing to do with casts or defaults. Map passes multiple parameters and parseInt accepts multiple parameters. Being unaware of the functions you're using is the problem, not some sort of weird gotchas of the language. The code in the title makes multiple assumptions, and those assumptions all proved wrong.
A typed language would absolutely fail this at compile time.
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#77This is not one of the weird things about Javascript. When you use a function (like map), always check the documentation to know its behaviour and don't assume it's similar to some similarly named function from another language. End of story.
> don't assume it's similar to the same named function from every other language
Even languages that do have different versions of it on different objects (e.g. Scala's zipWithIndex)
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#78Thanks Medium! Great readability.
Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript
#79Because It's JavaScript.. stop using unsafe languages, really
More generally, general purpose languages don't provide safety guarantees in the problem domain. They can provide certain guarantees in the solution domain, but it's left to the programmer to compose the elements of the language into a correct solution.
(In my experience, by far the biggest barrier to a correcty solution in the problem domain is that no one actually knows what that is, much less has expressed it. Instead, people express certain specific behaviors they think the system should have, from which the programmer needs to extrapolate the actual requirements -- not straight-forward since to a greater or lessor degree the expressions will be vague, self-contradictory, self-defeating, and/or incoherent. Then they need to compose those requirements in the solution space. BTW, the language is just a part of the solution space and "safe" languages are usually only referring to static checks, which the solution space often consists of distributed components which aren't strictly controlled in lock-step by the same static sources, meaning the static guarantees are useful, but in a limited way.)