I am disappointed by dynamic typing

Re:I am disappointed by dynamic typing by int_19h on Wednesday November 30, 2022 @03:51AM (#33798410)

The case you describe is handled by some form of checked types. In Ada, I'd just declare the range and let the compiler handle it. In a more conventional OO language, I can have a wrapper type for that number which enforces all constraints in the constructor. Either way, the point is that things blow up as soon as possible.

Broadly speaking, this is the contract-based approach: at every data flow boundary, explicitly describe your contract, so that any violation can be detected immediately instead of propagating and poisoning derived state. Eager type checking is just a subset of that, true. That means that static typing is not enough, not that it's unnecessary.

OTOH unit tests cannot fully express contracts, because even with parametrization you can only test so many of the possible inputs.

[ Parent | on HN ]

Re:I am disappointed by dynamic typing by goto11 on Wednesday November 30, 2022 @11:34AM (#33803225)

How do you define a contract which guarantee that the result of `add(a, b)` is correct? Not just that the result is a number, but that it is the correct number?

[ Parent | on HN ]

Re:I am disappointed by dynamic typing by tines on Wednesday November 30, 2022 @02:23PM (#33806155)

There is no way, in any language with any type system or any amount of tests (except maybe in a pure language with tests that cover the entire domain of the function, in which case you're just reproducing the entire function in the tests), to guarantee that calculateSalesTax produces the correct number in all cases. So the problem you describe exists equally for both dynamic and static type systems with tests. Dynamic type systems just rule out fewer possible errors (and fewer possible correct programs as well, to be fair) before the program runs.

[ Parent | on HN ]