4 ms·
> Yes I should have written more unit tests, but my excuse was it's just a prototype. Never understood this point "well, you don't need types, you can just wri
by sgift 9y ago
> Yes I should have written more unit tests, but my excuse was it's just a prototype.
Never understood this point "well, you don't need types, you can just write tests for it". IMO you should never have to write tests for something a type system can find for you. Why should I waste time with something which can be found by the compiler?
- zurn 9y agoThis is the path to formal methods. You will build formally correct programs very slowly, usually too slowly for the world/app domain.
- bjz_ 9y agoThis need not be the case forever. It's still an open problem, but the tooling is getting better all the time! For now types+tests are a happy medium. No need to throw the baby out with the water just because 100% correctness is still unfeasible for everyday business problems.
- crdoconnor 9y agoI find that strict type systems are good for 'locking down' execution space and sanity checking but they're not effective at cleanly specifying higher level verification even when that's possible. I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach.
- sgift 9y ago> I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach. Completely agreed. I tend to prefer pragmatic solutions over strict adherence to some methodology. As a sibling comment noted the natural end of specifying everything beforehand would be formal systems, which are usually not worth the effort. On the other hand I don't see "let's just throw everything the compiler could help us with out, because it's a bit more effort" as a sensible strategy.