Hacker News Reader

Comment by contravariant | Hacker News Reader

What the hell, who on earth thought that behaviour would be a good idea?

No one ever thought it would be a good idea, Contravariant. :/ It's just an unfortunate interaction between two APIs. Map's callback gets three args, and parseInt takes two (and ignores the third). After a while, you get used to wrapping callbacks to slough off the spare variables as shown.

In this case, the index of the element (1, 2, 3) is getting passed as the radix with which to parse the element (1, 1, 1).

Probably the same person who thought

    [1, 2, 3, 4].reduce((x, y) => Math.min(x, y))

should be 1 but

    [1, 2, 3, 4].reduce(Math.min)

should be NaN, for similar reasons. Unfortunately it's a recurring theme in JS that a lot of useful functions have optional extra parameters and a lot of useful higher order functions pass extra context to their callbacks, causing many traps for the unwary if you try to use these tools in a style that works fine in most functional programming languages.

.map(fn) calls its callback with three arguments, the value, the index, and the full array. Then parseInt takes two arguments, the string and the base (radix).

"1" of base 0 is 1

"1" of base 1 is NaN

"1" of base 2 is 1

The gotcha here is if you map(fn), you're going to get all three arguments sent to the fn, where map(v => fn(v)) explicitly only sends the first one.

I see. I'll remember this example for when someone asks why you need types.

this is more than just types though. Typescript, even in strict mode, will still allow this! You need strict function arity/signature checking of some kind, which a dynamically typed language could have, and a statically typed language could lack.

If a language can't detect the difference between a function a => f(a) and a function (a,b) => f(a,b) then I would consider it very weakly typed indeed. Dynamic vs static isn't really the issue, Python will also complain if you call a function with the wrong number of arguments.

Then again I suppose that you could recreate JavaScripts behaviour even in the fairly strongly typed C# if you wanted to, by defining two overloaded versions of Map as follows:

    IEnumerable<B> Map<A,B>(this IEnumerable<B> list, Func<A,B> f)
    IEnumerable<B> Map<A,B>(this IEnumerable<B> list, Func<A,int,B> f)

in that case C# would also choose the latter Map when you call it on a function with an optional int argument, similar to what JavaScript would do. However C# will never ignore an optional argument when you're passing around functions, so it's more consistent in that sense. And overloading a function in this way is not the best idea in the first place, it's just that JavaScript kind of encourages it.

Nobody thought about it or did that on purpose to confuse you with this particular example. If you would do js enough you still could be surprised at first but then you'll see it's pretty valid behavior. map will pass value and key to the method given. so it will call parseInt('1', 0) parseInt('1', 1) parseInt('1', 2)

Reply on news.ycombinator.com