3 ms·

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

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
      Automated tests can also be provided in far higher volume than manual tests. This didn't used to be the case, back in the stone ages of computing, when computers were much more expensive, so you often see old literature criticizing automated testing as inefficient, wasting expensive computer time. To give some idea of what automated testing can do these days, I point to the testing I regularly do on Common Lisp implementations, and particularly on the compilers of these implementations. I can quickly set it up to run some 200 tests per second in a single thread on SBCL, with randomly generated code of moderate size (a few hundred cons cells). Over the years I've run billions of distinct tests with this approach. This sort of testing found large numbers of bugs in every implementation I've ever tried it on. Similar testing on compilers for other languages (like Csmith for C) found bugs in every compiler it was ever tried on, even those implemented in statically typed languages.
    - golergka 3y ago
      Yes, I completely agree with that. I provided that argument just to illustrate that exactly the same point you've just made works for static typing when you compare it to automatic testing.

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
    Automated tests can also be provided in far higher volume than manual tests. This didn't used to be the case, back in the stone ages of computing, when computers were much more expensive, so you often see old literature criticizing automated testing as inefficient, wasting expensive computer time. To give some idea of what automated testing can do these days, I point to the testing I regularly do on Common Lisp implementations, and particularly on the compilers of these implementations. I can quickly set it up to run some 200 tests per second in a single thread on SBCL, with randomly generated code of moderate size (a few hundred cons cells). Over the years I've run billions of distinct tests with this approach. This sort of testing found large numbers of bugs in every implementation I've ever tried it on. Similar testing on compilers for other languages (like Csmith for C) found bugs in every compiler it was ever tried on, even those implemented in statically typed languages.
  - golergka 3y ago
    Yes, I completely agree with that. I provided that argument just to illustrate that exactly the same point you've just made works for static typing when you compare it to automatic testing.