3 ms·

Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system o

Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. You move the type specification out of tests and manual documentation directly into the code where you'll find out at compile time what you did wrong. Not at run-time, or during testing because you diligently wrote a test that considered the case. I agree that brevity sometimes aids refactoring, but there are many parameters that have to be weighed in, and often I find that the benefit of static typing outweigh whatever ignoring the type or checking it at run-time might offer.

crdoconnor 9y ago
>Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. I've not found this to be true, and tests that do type checking are a waste of time in any language. Bugs that are caught by static type systems are almost always caught by a combination of behavior tests and a sprinkling of sanity/type checks on border code (e.g. a module's publicly facing API). >you'll find out at compile time what you did wrong In a fully tested code base that is regularly tested the distinction between compile time and runtime does not matter a lot. By contrast n code bases in dire need of tests (which is more common than generally assumed), the distinction is absolutely vital.