Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript • Hacker News Board

Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript

#161

Post by fgonzag » Mon, Jun 24, 2019, 10:33 PM UTC

syntheticcdo wrote: post #39

jlarocco wrote: post #14

Earlier 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".

A lot of people are using JavaScript expecting it to conform to the principle of least surprise. Map applies a function f to each element and returns the result. If you want to supply a second argument, you either have to partially apply the function or manually supply the arguments. JavaScript's map is different from what the rest of the world calls map, and that's the problem.

I would never have guessed that it was passing the index as a second parameter, I would have expected a compiler error.

Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript

#162

Post by ernst_klim » Tue, Jun 25, 2019, 12:25 PM UTC

horsawlarway wrote: post #126

tomxor wrote: post #50

Earlier quoted context omitted.

Yes but with mandatory parameters the programmer would be aware parseInt had a radix in the first place if they had used it even once. That's one advantage of mandatory parameters, but there are of course disadvantages.

I'd argue basically everything about mandatory arguments is worse than having edgecases like this. Honestly, most languages STILL won't catch this, because the typical pattern is to use method overloading to provide multiple signatures if default arguments aren't supported. parseInt(in) parseInt(in, radix)

> I'd argue basically everything about mandatory arguments is worse than having edgecases like this.

Any sane language having optional arguments is using keys for opt args. That's what common lisp and OCaml do.

In OCaml you would write:

    let parse_int ?(radix = `Dec) string =...
    val parse_int : ?radix:[`Bin | `Oct | `Dec | `Hex] -> string -> int

and call it like

    parse_int "42"
      - 42
    parse_int ~radix:`Bin "111"
      - 7

    List.mapi parse_int ["1"]
      - Static error: this expression has type `string -> int`
        but expected int -> 'a -> 'b

Re: Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript

#163

Post by zbentley » Sat, Jun 29, 2019, 3:23 PM UTC

wutbrodo wrote: post #130

happytoexplain wrote: post #81

Earlier quoted context omitted.

Precisely - this is an API design failure, pure and simple. Not a problem with typing, optional arguments, etc.

It's both. Silently accepting variadic arguments increases the odds of something like this happening. This case wouldn't have happened without it. Though as I said in another comment, best-effort parsing was a decision that arose out of the Web ecosystem and its one of the few things about Javascript's language design that can't br blamed on incompetence.

What does this have to do with best-effort parsing?

"Variadic arguments" (really optional arguments with defaults/signature overloading, which is only arguably the same thing) existed long before JavaScript, and, indeed, the web. Optional arguments are also widely considered to be good/useful.