Oh yeah, it’s inarguably a bug in javascript, it’s just many decades too late to fix it.

Neither do TS/flow. And there’s a reason they don’t: https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters

It’s unfortunate but there’s not much to be done here. You’d have to craft a very strict, one-off eslint rule to prevent this error in your codebase at the cost of some performance and convenience (eg prevent passing anything but an arrow function to Array.map)

An in-depth description of the problem is here, for anyone having trouble following along: https://jakearchibald.com/2021/function-callback-risks/

Linters cannot rule out cases when the argument function is actually supposed to take an element and its index. But at least they could warn about a possible gotcha.

I get that it’s not the common map api in other languages, but coming in with “this is the API in some other unrelated language, therefore this is WAT” is simply not reasonable.

For the latter: not needing exact parameter count is a fairly fundamental part of the language. Saying it’s surprising that map(parseInt) invokes the same behavior as anywhere else in the language is “surprising” is again not reasonable.

JS has quirks, but labeling basic language semantics as WAT is tiresome.

Also, the fact that map() takes a function that expects 3 args (IIRC) but is commonly passed a function with one argument and things don’t blow up (neither at runtime nor at compile time in TypeScript) is pretty strange and probably the cause of a lot of these kinds of bugs. In general, JS/TS’s approach to “undefined” is difficult for me to intuit about and I’ve been using JS on and off for about 15 years.

map passes multiple arguments

It’s vaguely reasonable to not know this, but also the signature of map’s functor is on the first line or two of any documentation.

it’s not an error to call a function with the wrong number of arguments

Because variadic arguments (and the arguments array) are first class language features. This is where we get into “this is a core JS language feature, you really need to know it exists”

Or you can remember that other languages have other idioms, and that the index can be useful in principle. There’s also an additional parameter which is the array being enumerated. Together these can be useful.

You my have a functional language puritanical belief about what the API should be, but that’s a subjective opinion, hence it is reasonable that the functor receive additional information about the iteration, especially in a language like JS where variadic functions are first class.

You’re complaining about dynamic typing then, not JS.

Plenty of languages have varargs, plenty of languages have default parameters. The reason map(parseInt) works is because there is no type checking beyond “can be called”.

If you do want “arguments must match exactly”, then all your common calls to map would need function wrappers, because they’d trigger errors from not handling all three arguments.

The issue here is that variadic functions are core to JS from day 1. We’ve generally decided that that is “bad” nowadays, but given the functions have always been variadic in JS, large swathes of APIs are designed around it.

I suppose the simplest way to fix this would for map’s type to be like it is in Haskell, i.e.

(a -> b) -> [a] -> [b]

So the function map takes as argument takes just one argument, and map does not pass an index of the iteration.

I don’t doubt that there are valid reasons why this would be cumbersome in Javascript/Typescript, but I’m not familiar with them. Index of the iteration is not typically needed in functional style, so it’s kind of redundant and as shown here, potentially harmful.

Array.map() provides a third argument. Other languages would blow up when parseInt() was called with two arguments. You seem to argue elsewhere that JavaScript’s parseInt() accepts more than 2 arguments (because all functions in JavaScript accept ~arbitrarily large numbers of parameters), but that’s precisely what’s bizarre (and as many contend, error prone) about JavaScript–that we can call a function whose signature is function(a, b) with 3 arguments and it doesn’t blow up.

The issue isn’t that people don’t understand map()‘s signature, it’s that JavaScript is unusually permissive about function calls which makes it easy (even for people who understand that JavaScript is unusually permissive about function calls) to make mistakes where they wouldn’t in other languages.

The problem is you’ve misunderstood the claim.

Your claim was that any language would behave as JavaScript does when passing multiple parameters to a multiple parameter function.

I can pass a function that takes a variable number of arguments, and that will work

Ok, so you’re arguing that unlike other languages, all functions in JavaScript take a variable number of arguments which is just rephrasing the criticism that JavaScript is unusual (thus more programmer errors) and contradicting your claim that it’s behaving as any other language would do (e.g., “but again the language semantics and behaviour are not weird”).

Your example of python however is simply wrong. If python’s map passed the index:

Respectfully, you’re mistaken. Array.map() passes a third parameter to fn. If we update your Python example accordingly, it blows up as previously discussed:

def map(array, fn):
  result = []
  for i in range(0, len(array)):
    result.append(fn(array[i], i, array)) // TypeError: int() takes at most 2 arguments (3 given)
  return result