Not to mention peace of mind when you go and mess around with code you wrote 9 months ago - if you mess up or didn't think of a corner case, there's decent chance it'll get caught by existing tests.
In practice, when you write those tests for where the type system is lacking, you end up also incidentally testing where there is type system coverage, so there likely isn't much for industry to talk about.
Well, you are currently participating in a thread that discusses this very question so there's that... and such threads are regular on HN.
I meant just that. People discuss it. What you want to say is that you have a strong opinion about it, that's OK and still possible with open questions
I guess in this context I mean that the question of static vs. dynamic in unit testing turns out to not be that hard, but the questions like "what is a unit test" and "should we unit test at all" are much muddier. Because people are confused or argumentative about the latter, they tend to pull the former into discussions that don't really have much to do with static vs. dynamic.
("For free" in scare quotes because of course there are always tradeoffs between different programming languages.)
If the testing is insufficient, as in practice it often surely is, then static typing would seem to be more valuable.
If testing is enough to ensure the software is reliable, does the extra benefit of static typing make it worth the cost? This could be quite a lot of testing! The more testing that is done, the fewer type bugs remain that static typing would have found.
The argument you want to make against this is that static typing would have benefit beyond just finding bugs. The argument you don't want to make is that static typing reduces the need for testing.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...