4 ms·

The max value of what? The array in one of the arguments? What if there are two arrays? Or an array and a number? Or a multi-dimensional array of numbers and an

The max value of what? The array in one of the arguments? What if there are two arrays? Or an array and a number? Or a multi-dimensional array of numbers and any of the above? I think this attempt to come up w/ reasonable interpretations for unanticipated usages of a function is kind of a rabbit hole. Beyond that I think it's also problematic to assume that all usages of a function in a language without a type system are intended usages, i.e. that programmers _mean_ to pass arrays whenever an array appears as one of the arguments.

z3t4 7y ago
Sometimes you want to call a function with something else, or are not using an IDE (no argument hinting), and just call the function intuitively. Instead of converting the input, or writing a middle-man, you edit the function to accept it as is. You don't even have to pass values in the right order, the function will figure it out.
- almostdeadguy 7y ago
  There's nothing wrong w/ polymorphic functions, but there has to be a reasonable rule to apply for what kinds of shapes of data are permitted. Trying to aggressively handle unforeseen cases instead of indicating an error doesn't actually help anyone, it's akin to swallowing exceptions. It's why falsey values and automatic type conversion are some of the most problematic features in javascript. Your example of how to handle max for array arguments is exactly the kind of thing I would discourage in js code, because it overloads the meaning of "maximum" to data that don't have a natural way of assigning an ordering if heterogeneous arguments are permitted (actually it sounds like you're saying something like max([1], [9]) should return "9", which doesn't correspond to an intuitive understanding of "maximum" at all given it returns something that isn't either of the passed arguments). Whereas the rust code can use the "PartialOrd" trait to ensure we only try to produce a maximum of like elements with a defined ordering relation. That's fine for a limited number of cases where its easy to show type equivalence in js, but I think it's problematic as a general design principle, and because you don't have ways to express the limits of polymorphism I've seen this kind of thing proliferate to unsafe uses of a function very quickly.
  - z3t4 7y ago
    Only after you have tried to call the function with an array many times, that's when it would make sense. And there's another option too, to instead add a check and a friendly error. But it should be a fairly rare thing to do. Naming things can be hard and maybe more so if you do not have type annotations. But being used to dynamic languages I always find type annotations a chore. And I think it's better to have a good name and no types, then a bad name and types. eg. max(...numbers) vs x(y:number, z:number) -> number . Even though x is more verbose it can be anything, but with max(...numbers) I can be fairly sure.
    - mgraczyk 7y ago
      but then you have to test for this behavior, which was the counterpoint to the article.

z3t4 7y ago

Sometimes you want to call a function with something else, or are not using an IDE (no argument hinting), and just call the function intuitively. Instead of converting the input, or writing a middle-man, you edit the function to accept it as is. You don't even have to pass values in the right order, the function will figure it out.

almostdeadguy 7y ago
There's nothing wrong w/ polymorphic functions, but there has to be a reasonable rule to apply for what kinds of shapes of data are permitted. Trying to aggressively handle unforeseen cases instead of indicating an error doesn't actually help anyone, it's akin to swallowing exceptions. It's why falsey values and automatic type conversion are some of the most problematic features in javascript. Your example of how to handle max for array arguments is exactly the kind of thing I would discourage in js code, because it overloads the meaning of "maximum" to data that don't have a natural way of assigning an ordering if heterogeneous arguments are permitted (actually it sounds like you're saying something like max([1], [9]) should return "9", which doesn't correspond to an intuitive understanding of "maximum" at all given it returns something that isn't either of the passed arguments). Whereas the rust code can use the "PartialOrd" trait to ensure we only try to produce a maximum of like elements with a defined ordering relation. That's fine for a limited number of cases where its easy to show type equivalence in js, but I think it's problematic as a general design principle, and because you don't have ways to express the limits of polymorphism I've seen this kind of thing proliferate to unsafe uses of a function very quickly.
- z3t4 7y ago
  Only after you have tried to call the function with an array many times, that's when it would make sense. And there's another option too, to instead add a check and a friendly error. But it should be a fairly rare thing to do. Naming things can be hard and maybe more so if you do not have type annotations. But being used to dynamic languages I always find type annotations a chore. And I think it's better to have a good name and no types, then a bad name and types. eg. max(...numbers) vs x(y:number, z:number) -> number . Even though x is more verbose it can be anything, but with max(...numbers) I can be fairly sure.
  - mgraczyk 7y ago
    but then you have to test for this behavior, which was the counterpoint to the article.