July 30, 2026
Proof is in the pudding fight
Why Don't People Use Formal Methods?
Even the nerds can’t agree if proof-heavy software is genius or a giant time sink
TLDR: The article says proof-based software tools stay niche not just because they’re costly, but because the whole field is fragmented and hard to navigate. Commenters turned that into a bigger drag: companies already resist basic engineering, while “formally verified” can sound like marketing hype instead of real safety.
A blog post set out to answer a deceptively simple question: why don’t more programmers use “formal methods,” the math-heavy way of proving software does what it’s supposed to do? The writer says the usual shrug — “too expensive” or “only for airplanes” — misses the bigger story. In plain English, the field is a confusing maze of tiny camps, clashing terms, and multiple ways to describe what “correct” even means. Before anyone can prove code works, they first need a crystal-clear description of what the code should do — and apparently that alone is enough to make many teams run for the hills.
But the real fireworks were in the comments, where the community basically staged a group therapy session for software engineering. One camp argued the real problem is cultural: many companies barely invest in basic carefulness, so asking for rigorous proof feels like asking a toddler to file taxes. Another side warned that “formally verified” is becoming a shiny marketing sticker, like slapping “all natural” on a snack and hoping nobody checks the label. And then came the industry roast: commenters joked that food-delivery-app mindsets are being hired to build crypto and finance systems, which is exactly as calming as it sounds.
The funniest recurring mood? Total decision paralysis. One reader practically begged for a universal “second-best” tool because learning a different proof system for every problem sounds emotionally exhausting. Even a helpful Jane Street post got tossed in like a study guide for a class everyone agrees is important — and secretly dreads.
Key Points
- •The article argues that simple explanations like cost or limited necessity do not fully explain the limited adoption of formal methods.
- •It distinguishes formal specification from formal verification and further separates code-focused work from design-focused work.
- •The author introduces the labels CS, CV, DS, and DV for clarity, noting that these are not standard terms across the formal methods field.
- •The article says formal verification requires a precise specification of correctness before code can be proved correct.
- •It identifies two major code-specification styles: separate specifications used by systems like Isabelle and ACL2, and embedded assertions formalized through Hoare Logic and used in Design by Contract.