Many of your examples could definitely be caught by static types, depending on the type system. But that’s less important than…
> This is actually very important since "type bugs" are trivially easy to catch
This, IMO, is exactly why I’m in the static type camp. It’s so trivial that you can do it declaratively, inline with the code it’s testing, with instant feedback, at every call site and in every downstream expression/statement. A type annotation doesn’t mean my semantic/domain logic is sound, I still have to test that. but it could replace dozens of trivial tests orthogonal to the logic I care about… tests which, let’s face it, few people are going to write exhaustively otherwise.
The amount of runtime checks and/or tests required to emulate the guarantees of static types is huge. It's perplexing that some people would rather do that manually.
But to the point of triviality, static types tend to lull developers into a false sense of security. There are limits to their usefulness. You still need both runtime checks and test-time assertions for your logic. You just need less of them and they provide more value per line of code. But I've never seen a type system capable of expressing the entire problem domain in an ergonomic way. Not even close.
For my money, a combination of: static types, property-based testing, unit/integration tests, and an end-to-end test against prod are all required. You can compensate for the lack of one by putting more effort into another but you're really just shuffling the "correctness burden" from one place to another. I like static types because it makes the rest of testing easier. But at some point, you've got to roll up your sleeves and make sure it works IRL.
I question this "false sense of security" point. In my experience, people who prefer as much static analysis as possible, mostly based on types, are also more likely to be thinking about invariants and error cases more generally. I would go further to say that anyone who has really adopted a thinking-about-invariants-and-error-cases style of programming has almost certainly become frustrated with the amount of repetitive validation code required to accomplish that in projects with no static analysis of types.
Agreed. I was more rebutting the "If it compiles, it works" mentality - which is not true for anything other than trivial examples. You still need to test that the compiled artifact actually works in a real setting, where "works" is domain-specific and defined by user's perception of value.
Right. But I'm saying that I don't think that mentality actually exists. I think the mentality of people who prefer static analysis is more like "if it compiles, it has passed a huge number of test cases that I'm really glad I didn't have to write myself". But "if it compiles, it works" is a more pithy short-hand for that :)
In a dynamically language you need 100% test coverage, because misspelling a variable name turns into a runtime error.
On large projects this can be a problem. I worked on a Python server some years ago, and with every large program that supports exceptions, there's a catch block somewhere that silently eats the exceptions it doesn't process. Well, some modules were loaded dynamically, so my first spelling mistake (and second and third...) took quite a while to debug because things just didn't work, the code didn't get executed, but there were no errors. This also ate syntax errors, too, since that is also an exception. So if you edited the file, you had no idea if things actually still worked (or even compiled!) until you tested the functionality from the file.
> This is actually very important since "type bugs" are trivially easy to catch
This, IMO, is exactly why I’m in the static type camp. It’s so trivial that you can do it declaratively, inline with the code it’s testing, with instant feedback, at every call site and in every downstream expression/statement. A type annotation doesn’t mean my semantic/domain logic is sound, I still have to test that. but it could replace dozens of trivial tests orthogonal to the logic I care about… tests which, let’s face it, few people are going to write exhaustively otherwise.