|
|
|
|
|
|
by pavel_lishin
2223 days ago
|
|
|
> if you test all the behavior you care about, then you don't care if there are type errors, because they only occur in situations where you don't care. If I test all the situations I care about, the one situation I thought I didn't care about is going to fuck me in production. |
|
|
It's not useful to talk about a binary "bugs versus no bugs", because "no bugs" isn't plausible in most codebases.
It's also not useful to talk about "more bugs versus fewer bugs" because that's only part of the picture: the other parts of the picture are how much development effort was necessary to achieve the level of bugs you have, and whether the number of bugs you have, and when you have them, is acceptable.
If it's a life or death application where any bugs at runtime are unacceptable, then of course we want static types, but static types aren't enough: I'd also want a theorem prover, fuzzer, a large number of human testers, and a bunch of other things that require way too much effort to be useful in an average software project.
The vast majority of software projects, runtime bugs are acceptable as long as they don't lose data, cause downtime, or expose private information. If you catch these bugs during unit testing instead of 30 seconds earlier at compile time, that's fine. Static types might catch a few more bugs, but it is very much not in evidence that the level of effort involved is lower than equivalent unit testing in situations where reliability requirements are typical.