6 ms·

It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped

It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. How do you make sure your function that takes an `any` doesn't crash and burn or silently sneak through and write null to the database?

goto11 4y ago
> It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. Sorry, I don't understand what you are saying here. By A and B are you referring to the correct output given an input, or just to the expected data type? Because there is a big difference, as with the `min()` example.
- kajaktum 4y ago
  A and B refers to the expected data type, yes.
  - goto11 4y ago
    So proving that `min(number, number)` returns a number is 99% as good as a unit test which shows that it returns the smallest number?
    - kajaktum 4y ago
      yes because the set of possible inputs for A -> C is basically infinite. But min(A,B)=C is only 2^64^2. Why shouldn't you test for string, object, object of object, object with a certain kind of shape, or Number class as opposed to number primitive? How can you know it will or won't work from a unit test perspective? >inb4 just document it that is what types are for
      - goto11 4y ago
        But the purpose of unit tests is to show that the code under test is correct, i.e. that min() return the smallest input, not just a random value of the same type. Static typing cannot do that, so it is in no way a substitute for unit tests. Static typing is a useful tool, just not a substitute for any unit tests. The risk of static typing is when it becomes a goal in itself and you start thinking correctness means the program satisfies the type checker.
kazinator 4y ago
One possible answer is that you make that a feature: the database can contain null, and it means something. In some cases you will trade one problem for another, but the economics of the tradeoff in overall productivity can be favorable.

goto11 4y ago

> It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. Sorry, I don't understand what you are saying here. By A and B are you referring to the correct output given an input, or just to the expected data type? Because there is a big difference, as with the `min()` example.

kajaktum 4y ago
A and B refers to the expected data type, yes.
- goto11 4y ago
  So proving that `min(number, number)` returns a number is 99% as good as a unit test which shows that it returns the smallest number?
  - kajaktum 4y ago
    yes because the set of possible inputs for A -> C is basically infinite. But min(A,B)=C is only 2^64^2. Why shouldn't you test for string, object, object of object, object with a certain kind of shape, or Number class as opposed to number primitive? How can you know it will or won't work from a unit test perspective? >inb4 just document it that is what types are for
    - goto11 4y ago
      But the purpose of unit tests is to show that the code under test is correct, i.e. that min() return the smallest input, not just a random value of the same type. Static typing cannot do that, so it is in no way a substitute for unit tests. Static typing is a useful tool, just not a substitute for any unit tests. The risk of static typing is when it becomes a goal in itself and you start thinking correctness means the program satisfies the type checker.

kazinator 4y ago

One possible answer is that you make that a feature: the database can contain null, and it means something. In some cases you will trade one problem for another, but the economics of the tradeoff in overall productivity can be favorable.