korrents

What Hillel Wayne thinks about formal proof

@hillel-wayne · 45 positions · 0 changes of mind

Writer and consultant on formal methods, testing and software correctness, author of Logic for Programmers and Practical TLA+. He ran the Crossover Project, interviewing seventeen people who worked as traditional engineers before becoming software developers, to settle by evidence whether software engineering is engineering.

Everything they publish, on ppll ↗

Hillel Wayne did not write this page.

We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording. Their own site. Is this you? Claim it or ask us to remove it. Or tell us what is wrong here.

7 dated positions, 2019 to 2026, in their own words. Our reading of what Hillel Wayne has said — not written or endorsed by them.

  1. Our readingFormal methods are not used everywhere because for most real problems writing down what the function should do is itself a nightmare, and a program that is right ninety-nine per cent of the time is good enough.

    Their wordswhen you start talking about like most interesting domain problems, you have to pull in so much context that basically even writing what the function is supposed to do becomes a nightmare. The imperative program you write that will get correct 99% of the time is probably good enough to use in almost all cases.

    ↗Formal methods with Hillel Wayneyoutube.com 9th of 24 in this recording

    Interesting

  3. Our readingNuclear power plants, the standard example of software that must be proved correct, do not care about formal verification: thorough testing is enough for them.

    Their wordsbut I can tell you with first hand experience nuclear power plants do not care about this stuff. They're actually just fine with with with thorough testing.

    ↗Formal methods with Hillel Wayneyoutube.com 10th of 24 in this recording

    energynuclear power

    Interesting

  5. Our readingFormal methods shine in highly computational domains and struggle wherever the problem is embedded in human business behaviour.

    Their wordsI think the case of TLA+ and most, not all, but most formal methods, they shine the most in highly computational domains, where most of the problems are highly technical and not like business embedded.

    ↗Formal methods with Hillel Wayneyoutube.com 15th of 24 in this recording

    Interesting

  7. Our readingEngineers are sceptical of formal methods because they were burned by CASE and UML, sold as miracle solutions and imposed on them regardless of fit.

    Their wordsI think a lot of the reason people are skeptical of these is because they've been burned by things like case and UML and all these other miracle solutions that were forced on them by people who wanted them to use it no matter what.

    ↗Formal methods with Hillel Wayneyoutube.com 16th of 24 in this recording

    Interesting

  9. Our readingFormal methods are a niche tool; property-based testing is the one most engineers should adopt, and stopping there is a fine place to stop.

    Their wordsI love formal methods, but I think it's a fairly niche tool for most people and I think like property-based testing is in general going to be useful for more people.

    ↗Formal methods with Hillel Wayneyoutube.com 17th of 24 in this recording

    Interesting

  11. Our readingAI is making formal methods more popular without making them mainstream, moving them from about a tenth of a per cent of engineers to three tenths.

    Their wordsI think it is making it more popular. I don't know if it'll make it go mainstream, but it's definitely making it a lot more popular. It's bringing it from maybe like 0.1% to 0.3% which is huge.

    ↗Formal methods with Hillel Wayneyoutube.com 20th of 24 in this recording

    Interesting
  12. 8 years earlier

  13. Our readingFull formal verification is a waste of money for most software: near-perfect is reachable with ordinary techniques at a fraction of the cost.

    Their wordsYou do not need full code verification to write good software or even to write near-perfect software.

    ↗Why Don't People Use Formal Methods?hillelwayne.com 5th of 5 in this piece

    Interesting