Oh! Sorry, no, that's because ECMAScript (Javascript)'s historical baggage and lax attitude toward arity produce a combinatorial explosion of stupidity. See, y

Oh! Sorry, no, that's because ECMAScript (Javascript)'s historical baggage and lax attitude toward arity produce a combinatorial explosion of stupidity. See, you can't just ['1', '2', '3'].map(parseInt) because: 0) All Javascript functions are variadic; the signature specified at definition time is largely advisory, and has semantic meaning only in that the language will automatically declare and bind named arguments. Arguments named in a function's signature, but not passed at call time, are undefined; arguments not named in a function's signature, but passed at call time, are not automatically bound to named variables, but can be accessed via the arguments binding, which is a unique object magically bound within a function's scope, but which will be overridden by a named argument "arguments" if one exists in the signature, and 1) Array.map and friends pass their callbacks three arguments: the value of the element, the index of the element in the array being mapped over, and a reference to the entire array being mapped over, and 2) Number.parseInt requires one argument, the value to cast to integer, and accepts an optional second argument, specifying a radix between 2 and 36 inclusive. So our naïve mapping above expands to the following series of calls: parseInt('1', 0, ['1', '2', '3']); // -> 1 parseInt('2', 1, ['1', '2', '3']); // -> NaN parseInt('3', 2, ['1', '2', '3']); // -> NaN tl;dr: None of this would be necessary in a language whose collection methods did sane things. Since Javascript is not such a language, this is what we have to do. ...I'm not actually sure this whole thing was a joke, but it reads to me a little like it might've been written with the sort of smirk you tend to see academic FP purists directing at industry engineers.