2 ms·

> if you didn't care enough about the correctness of your code to test it adequately, why would you care that static type checking could find some bugs? I thin

> if you didn't care enough about the correctness of your code to test it adequately, why would you care that static type checking could find some bugs? I think you got this backwards. If you didn't care enough about the correctness of your code to even do something as simple and straightforward as using a proper type system, why would you spend enormous amount of time to write and then support unit tests just so that they could find some bugs?

pfdietz 3y ago
I do care about the things type checking could find. I just don't care to use type checking to find them, because I'd find them by doing other activities (extensive testing) that I'd do anyway.
- golergka 3y ago
  The main difference is, nobody checks if you wrote tests for every failure condition. Choose coverage tries, but it doesn't really come close enough to type checker.
  - pfdietz 3y ago
    So, you're saying nobody actually cares if the code is correct. So why should I?
    - golergka 3y ago
      No, I'm saying that I would rather depend on an automated tool than human decision. That's why you use automated testing instead of manual, right? Static typing is just the next step in the same direction.
      - pfdietz 3y ago
        But the automated tool (static type checker) does not actually produce reliable software. Only extensive testing does that. And if you do extensive testing, why do you need that automated tool? The static type checker is only useful (in the sense of making the software more reliable) if the testing is inadequate. In which case, the software is going to be crap anyway. You might argue that enforcing static type checking cause the software to be structured in some way that's helpful, but that's a different argument.
        golergka 3y ago
        But automated testing (unit tests) does not actually produce reliable software. Only extensive manual testing does that. And if you do extensive manual testing, why do you need that automated testing? Automated testing is only useful (in the sense of making the software more reliable) if manual testing is inadequate. In which case, software is going to be crap anyway. You might argue that enforcing unit tests cause the software to be structured in some way that's helpful, but that's a different argument. --- If you have a counter-argument against this in manual vs automated testing debate, then you also have a counter-argument against your own position above. Also, from my personal experience: I've started to write more and more functional code lately. Not only static type checking, but "almost-Haskell" in Typescript with fp-ts. And I find that when I write code in this way, the only place where I actually find and fix bugs are... unit tests.
        pfdietz 3y ago
        I didn't specify automatic or manual testing, I just said testing. Automatic vs. manual testing is another topic entirely (albeit one I have opinions on).
        Jtsummers 3y ago
        > But automated testing (unit tests) does not actually produce reliable software. Only extensive manual testing does that. And if you do extensive manual testing, why do you need that automated testing? Unit testing is not the only form of automated testing. You can have automated regression tests, integration tests, and even automated exploratory tests (similar to what you get with the "million QAs typing on keyboards" approach of manual exploratory testing). Automated tests are reproducible and reliable (particularly for regression testing or with tight timing constraints) in a way that manual testing will never be. You sound a bit like my old boss who had to be convinced to let us automate tests by sitting him at the relay box and telling him, "This test procedure says 'flip the switch 10 times per second for 10 seconds and a fault indicator will appear', can you do that?" The answer, of course, was no. No one can, automated tests are useful for making reliable software (this was a safety critical system, we cared very much about reliability and if you've ever flown you ought to be happy that we cared).

pfdietz 3y ago

I do care about the things type checking could find. I just don't care to use type checking to find them, because I'd find them by doing other activities (extensive testing) that I'd do anyway.

golergka 3y ago
The main difference is, nobody checks if you wrote tests for every failure condition. Choose coverage tries, but it doesn't really come close enough to type checker.
- pfdietz 3y ago
  So, you're saying nobody actually cares if the code is correct. So why should I?
  - golergka 3y ago
    No, I'm saying that I would rather depend on an automated tool than human decision. That's why you use automated testing instead of manual, right? Static typing is just the next step in the same direction.
    - pfdietz 3y ago
      But the automated tool (static type checker) does not actually produce reliable software. Only extensive testing does that. And if you do extensive testing, why do you need that automated tool? The static type checker is only useful (in the sense of making the software more reliable) if the testing is inadequate. In which case, the software is going to be crap anyway. You might argue that enforcing static type checking cause the software to be structured in some way that's helpful, but that's a different argument.
      - golergka 3y ago
        But automated testing (unit tests) does not actually produce reliable software. Only extensive manual testing does that. And if you do extensive manual testing, why do you need that automated testing? Automated testing is only useful (in the sense of making the software more reliable) if manual testing is inadequate. In which case, software is going to be crap anyway. You might argue that enforcing unit tests cause the software to be structured in some way that's helpful, but that's a different argument. --- If you have a counter-argument against this in manual vs automated testing debate, then you also have a counter-argument against your own position above. Also, from my personal experience: I've started to write more and more functional code lately. Not only static type checking, but "almost-Haskell" in Typescript with fp-ts. And I find that when I write code in this way, the only place where I actually find and fix bugs are... unit tests.
        pfdietz 3y ago
        I didn't specify automatic or manual testing, I just said testing. Automatic vs. manual testing is another topic entirely (albeit one I have opinions on).
        Jtsummers 3y ago
        > But automated testing (unit tests) does not actually produce reliable software. Only extensive manual testing does that. And if you do extensive manual testing, why do you need that automated testing? Unit testing is not the only form of automated testing. You can have automated regression tests, integration tests, and even automated exploratory tests (similar to what you get with the "million QAs typing on keyboards" approach of manual exploratory testing). Automated tests are reproducible and reliable (particularly for regression testing or with tight timing constraints) in a way that manual testing will never be. You sound a bit like my old boss who had to be convinced to let us automate tests by sitting him at the relay box and telling him, "This test procedure says 'flip the switch 10 times per second for 10 seconds and a fault indicator will appear', can you do that?" The answer, of course, was no. No one can, automated tests are useful for making reliable software (this was a safety critical system, we cared very much about reliability and if you've ever flown you ought to be happy that we cared).