[paulddraper]

It's unexpected.

No other language does this.

[qayxc]

> No other language does this.

Every language that supports default and variable arguments does this. This includes Python, C, and C++ and has absolutely zero to do with "loose typing" in this case.

[paulddraper]

To be correct, all you have to do...all you have to do...is post a single example of the equivalent to the JS code that is producing the same result.

But you can't!!!

> Every language that supports default and variable arguments does this.

Python:

    map(float, ["1", "2", "3"])

C:

No equivalent syntax.

C++

    std::vector<std::string> a = {"1", "2", "3"};
    std::vector<int> b;
    std::transform(a.begin(), a.end(), std::back_inserter(b), std::stod); # compile error

You can say "well feature X exists elsewhere" or "library function Y exists elsewhere", but only JS makes the collective design choices that cause this phenomenon.

Good, bad? IDK, that's subjective. But unique? Certainly.

[qayxc]

Oh, I definitely could post an equivalent example in Python and C. There's simply not enough space on the sidebar to do it ;)

If you ever, like at all, had the pleasure of using any Python library without type hints - past iterations of numpy and in particular matplotlib come to mind - you'd be blown away by the amount of

  def some_function(*args, **kwargs)

Have fun trying to figure those out even with an API reference at hand. Fun times.

Also C does have equivalent syntax, namely variadic functions in combination with function pointer arguments. You can design all kinds of crazy interfaces with that, too, which will exhibit strange and unexpected behaviours if used incorrectly. Heck, name a single C noob who didn't cause a segfault while trying to read a number using sscanf().

When it comes to stdlib interface design, C is actually much more offensive than JS :) strtok() comes to mind. More footguns than stars in the sky just in that innocent seeming function alone. And don't even get me started with the C++ STL...

So no, it's not just JS that makes design choices that seem odd and unintuitive - you'll find them in every language that is actually in widespread use and "battle tested". It's funny to me how some people try to single out JS in that regard, even though it's in no way special when it comes to this.

[etra0]

Python does not do this:

    > help(int)
      class int(object)
      |  int([x]) -> integer
      |  int(x, base=10) -> integer

    > list(map(int, ["1", "2", "3"]))
      [1, 2, 3]

Even if you define a function that takes two parameters, it complains about not having a second one:

    >>> def to_int(a, b):
    ...     return int(a, base=b)
    ...
    >>> list(map(to_int, ["1", "2", "3"]))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: to_int() missing 1 required positional argument: 'b'

[qayxc]

Now replace

  def to_int(a, b):
    ...

with the JS semantic equivalent of

  def to_int(*args):
    ...

because that's how JS function declarations work. You simply have the option to assign names to positional parameters, i.e.

  function fn(a, b) {
    comnsole.log(a, b)
  }

is just syntactic sugar for

  function fn() {
    const a = arguments[0]
    const b = arguments[1]
    console.log(a, b)

}

and that's what people seem to struggle with and argument over for whatever strange reason.

[dragonwriter]

JS discarding extra positional arguments (and that being leveraged in map and similar methods) seems to be the unique bit. I don’t think any other popular language does that.

[fiddlerwoaroof]

Overloading on arity isn’t that uncommon in popular languages like Java

[dragonwriter]

The combination with the design of common-across-languages iterator methods like map, filter, reduce is uncommon. (Neither is doing it implicitly for all functions.)

[qayxc]

It's not unique at all: C has this feature as well - just look at printf() and other functions that accept variable argument lists.

[Jtsummers]

That's a variadic function and those have to be explicitly marked as variadic. You cannot pass in an arbitrary number of arguments to other functions.

https://en.cppreference.com/w/c/variadic

[uzerfcwn]

> You cannot pass in an arbitrary number of arguments to other functions.

More specifically, you could in C89 but it was removed because it's a bad feature.

https://godbolt.org/z/j4v4GT3Wd

[qayxc]

In JS every function is a variadic function, though. The problem is that many people ignore that fact for whatever reason.

  function fn() { }

is semantically the exact same as

  function fn(a, b, c) { }

in JS.

[Jtsummers]

You're discussing this as if the critical "gotcha" was with `parseInt`. It's not the critical gotcha here. The critical one is actually with the semantics of `map` which behaves differently in JS compared to just about every other language with a map (or equivalent) which passes only the elements of the sequence (or sequences in some cases) to the function. See Python, Ruby, C++ (transform is the nearest direct match), Rust, Common Lisp, Scheme, etc. Using the example with `parseInt` just demonstrates this strange, and unique, design decision.

[qayxc]

You're looking at it myopically as well.

JS has this semantic and the interfaces are designed with that in mind.

Take C# for example. There is a List<T>.ForEach() function that passes the value to the delegate. Fine. But what if I require the index as well? I can't use List<T>.ForEach() in that case, because ignoring extra arguments is not part of C# function call semantics.

The interface of map() has been designed to be as flexible as possible to cover use cases outside of just passing the current value. This matches perfectly with JS function call semantics that allow any number of arguments by default.

Why doesn't parseInt() *always* require two parameters? Why is one design decision "strange and unique" (e.g. map() passing 3 arguments) while the other (parseInt() accepting one or two arguments) is perfectly fine? I also would be careful with citing the STL as being sound when it comes its interface design :)

JS is different from other languages - big whoop. The same complaints about seemingly strange design decisions can be made for any sufficiently old and widespread language - JS isn't unique in this regard.

There actually annoying strangeness in other things, e.g. confusing type conversions in places (e.g. ("" == false) === true; [1, 2, 3] + [4, 5, 6] === "1,2,34,5,6"), which is why "==" should never be used if you want to retain your sanity.

The interfaces and standard functions, however, are as offensive or inoffensive as those in most other languages.