7 ms·

This idea that static analysis, runtime checks, and automated tests are somehow in competition with each other is possibly the single worst outcome of the protr

This idea that static analysis, runtime checks, and automated tests are somehow in competition with each other is possibly the single worst outcome of the protracted dynamic vs static typing flamewar that the profession's been having for the past few decades.

gavinhoward 3y ago
I never said that. What I said is that runtime checking is better if you have a test suite that's good enough.
- mumblemumble 3y ago
  That "better/worse" way of wording it places them in competition with each other, regardless of whether you say it explicitly. A way of discussing it that doesn't place them in competition with each other would instead talk about their relative characteristics, including factors that might make different options more or less effective (or even inapplicable) in certain circumstances. For example, there are certain classes of defect that cannot be detected at runtime. But what does and does not fall into this category depends on what programming language you're using. There are other classes of defect that cannot be detected statically, and the specifics of this list also depends on what language you're using. And then there's also a bunch of overlap, but the relative merits of one or another way of solving things cannot be boiled down to a simple "better/worse" hierarchy. The optimal strategy is often domain-specific and finding it may require weighing many tradeoffs.
  - gavinhoward 3y ago
    > That "better/worse" way of wording it places them in competition with each other, regardless of whether you say it explicitly. Absolutely not. It says that they have tradeoffs, and one will be better in certain situations, while the other will be better in others. If you think that means competition, you're overreading it.
- Nokinside 3y ago
  I have written safety-critical code and nobody has a test suite that could do what Astrée does. It can be used to proves the absence of errors with the abstract interpretation that catches all divisions by zero, data races, and deadlocks, and does static taint checking. You want a test suite, but it's never better or good enough. Abstract Interpretation in a Nutshell https://www.di.ens.fr/~cousot/AI/IntroAbsInt.html https://www.di.ens.fr/~cousot/AI/IntroAbsInt.html
  - gavinhoward 3y ago
    > all divisions by zero, data races, and deadlocks, and does static taint checking. That is a wild claim. But how many false positives does it have? Too bad it's not FOSS; I would pay for that is the false positive rate was not too high.
    - Nokinside 3y ago
      It's true claim, no potential error is ever omitted. It may be hard to get code pass because there are false alarms, but when it passes it holds. We are talking code without dynamic memory allocation, recursive function calls, no system and library calls, of course. Like some embedded aerospace, automation, healthcare and military applications. You can use it to verify some libraries if you can't do full coverage. Application domain abstractions are also available. NASA has open source tool called IKOS based on same abstract interpretation concept, but I don't know it's features.

gavinhoward 3y ago

I never said that. What I said is that runtime checking is better if you have a test suite that's good enough.

mumblemumble 3y ago
That "better/worse" way of wording it places them in competition with each other, regardless of whether you say it explicitly. A way of discussing it that doesn't place them in competition with each other would instead talk about their relative characteristics, including factors that might make different options more or less effective (or even inapplicable) in certain circumstances. For example, there are certain classes of defect that cannot be detected at runtime. But what does and does not fall into this category depends on what programming language you're using. There are other classes of defect that cannot be detected statically, and the specifics of this list also depends on what language you're using. And then there's also a bunch of overlap, but the relative merits of one or another way of solving things cannot be boiled down to a simple "better/worse" hierarchy. The optimal strategy is often domain-specific and finding it may require weighing many tradeoffs.
- gavinhoward 3y ago
  > That "better/worse" way of wording it places them in competition with each other, regardless of whether you say it explicitly. Absolutely not. It says that they have tradeoffs, and one will be better in certain situations, while the other will be better in others. If you think that means competition, you're overreading it.
Nokinside 3y ago
I have written safety-critical code and nobody has a test suite that could do what Astrée does. It can be used to proves the absence of errors with the abstract interpretation that catches all divisions by zero, data races, and deadlocks, and does static taint checking. You want a test suite, but it's never better or good enough. Abstract Interpretation in a Nutshell https://www.di.ens.fr/~cousot/AI/IntroAbsInt.html https://www.di.ens.fr/~cousot/AI/IntroAbsInt.html
- gavinhoward 3y ago
  > all divisions by zero, data races, and deadlocks, and does static taint checking. That is a wild claim. But how many false positives does it have? Too bad it's not FOSS; I would pay for that is the false positive rate was not too high.
  - Nokinside 3y ago
    It's true claim, no potential error is ever omitted. It may be hard to get code pass because there are false alarms, but when it passes it holds. We are talking code without dynamic memory allocation, recursive function calls, no system and library calls, of course. Like some embedded aerospace, automation, healthcare and military applications. You can use it to verify some libraries if you can't do full coverage. Application domain abstractions are also available. NASA has open source tool called IKOS based on same abstract interpretation concept, but I don't know it's features.