4 ms·

A common philosophy in JavaScript is to make it just work. For example if an array is passed, sort it and return the max value, which was probably what the pro

• SideburnsOfDoom 7y ago
  Which would need even more tests, because now there a set of types that will work (e.g. numbers, arrays of numbers), with code to make them work and tests on that; and other types do not work, and tests on that.
  • z3t4 7y ago
    Yes, you write a new test for each new feature. But if you do the same thing in a statically typed language, once you've allowed arrays, and what not, how do you know if the function still works, besides carefully studying it.
    • mgraczyk 7y ago
      The point is that you need more tests. In statically typed languages, you typically don't make it "just work" and hence need fewer tests.
      • AnimalMuppet 7y ago
        Well, you don't make it "just work" for all conceivable input shapes. You make it work for the one and only accepted input shape, which is 1) much easier to make work, 2) means that you don't miss possible input shapes, and 3) is much easier to test thoroughly.
• almostdeadguy 7y ago
  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.