3 ms·

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 manu

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.

sanderjd 3y ago
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.
- perrygeo 3y ago
  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.
  - sanderjd 3y ago
    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 :)
prewett 3y ago
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.

sanderjd 3y ago

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.

perrygeo 3y ago
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.
- sanderjd 3y ago
  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 :)

prewett 3y ago

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.