alt.hn

12/12/2025 at 11:26:26 PM

50 years of proof assistants

 https://lawrencecpaulson.github.io//2025/12/05/History_of_Proof_Assistants.html

by baruchel

12/13/2025 at 4:15:27 AM

I can see "no progress in 50 years" in fundamental physics where the experimental frontier seems to be running away from us (though recent gamma astronomy results suggest a next generation accelerator really could see the dark matter particle)

In biology or chemistry it's absurd to say that -- look at metal organic frameworks or all kinds of new synthetic chemistry or ionic liquids or metagenomics, RNA structure prediction, and unraveling of how gene regulation works in the "dark genome".

Progress in the 'symbolic AI' field that includes proof assistants is a really interesting story. When I was a kid I saw an ad for Feigenbaum's 3-volume "Handbook of AI" and got a used copy years later -- you would have thought production rules (e.g. "expert systems" or "business rules") were on track to be a dominant paradigm but my understanding was that people were losing interest even before RETE engines became mainstream and even the expert system shells of the early 1980s didn't use the kind of indexing structures that are mainstream today so that whereas people we saying 10,000 rule rule bases were unruly in the 1980s, 10,000,000 well-structured rules are no problem now. Some of it is hardware but a lot of it is improvements in software.

SAT/SMT solvers (e.g. part of proof assistants) have shown steady progress in the last 50 years, though not as much as neural networks because they are less parallelization. There is dramatically more industrial use of provers though business rules engines, complex event processing, and related technologies are still marginal in the industry for reasons I don't completely understand.

by PaulHoule

12/13/2025 at 6:31:28 AM

>in biology or chemistry..

>But it’s fair to assume that such fields have not been idle either.

"Manngell amnesia", where if you hear of breakthroughs in any field other than AI, you assume that very field has always been stagnant?

There's another angle to this. Eg MoF-synthesis is a breakthrough unappreciated outside of chem because of how embarrassingly easy it is. Laymen (& VCs) expect breakthroughs to require complexity, billions, wasted careers, risk, unending slog etc..

Read the bios of the chem nobellists to see what stress-free lives they led (around the time of the discovery), even compared to VCs and proof assistant researchers. Disclaimer: possibly not applicable to physics/physiology laureates after 1970 :)

https://www.amazon.com/Dancing-Naked-Mind-Field-Mullis/dp/07...

Mullis succeeded in demonstrating PCR on December 16, 1983, but the staff remained circumspect as he continued to produce ambiguous results amid alleged methodological problems, including a perceived lack of "appropriate controls and repetition."

(From wiki)

by gsf_emergency_6

12/13/2025 at 2:38:26 PM

There was one day the bus was late so I drove in with a grad student who did density functional theory calculations of MOFs and asked him "How do you make a MOF?" and he said "Beats me, I'm a theorist" so I figured that I wanted a quick answer to that one myself and it turned out to be "mix up the ingredients and bake them in the oven"

by PaulHoule

12/13/2025 at 9:46:42 PM

It looks like that the "theorist" might be replaced sooner, given the narratives that are being driven now.. (after the entry level coder)

by gsf_emergency_6

12/13/2025 at 11:53:10 PM

I'll say grad students today often seem a bit sheepish and inarticulate. They're facing a very competitive market so I think it behooves the theorists to be able to talk about experiment a bit and vice versa. On the other hand they have a big hill to climb to just be successful with DFT.

One of my few regrets in grad school is that I didn't take a course in DFT, not like I was really going to use it, but DFT is an example of the kind of very complex calculation which takes a lot of care to apply. I got a little of this art from Sethna's class in renormalization groups and such but it was really

https://www.amazon.com/Introduction-Study-Stellar-Structure-...

by Chandrasekhar that taught me how to organize the kind of complex calculations that might involve numeric integration differential equations, using a computer, etc -- extracurricular for a cond-mat PhD but really a lot of fun.

I just made a breakthrough in selfobject technology (enough of a reformulation that I can take back the ideas that my evil twin published in such a way that I couldn't ever publish them under my name) and managed to get the evil out of my evil twin and I've been practicing "radiance drills" that get me into a state where I can really draw out 30y+ people but how it works with "kids these days" is an open question because since the pandemic grad students mostly seem like damp squibs -- I gotta give it a try.

I do regret I didn't figure this out much sooner (if I had I wouldn't have some things on my chart I do now) but right now I having so much fun I think other people should be jealous.

by PaulHoule

12/14/2025 at 3:29:39 AM

Have you asked LLMs about the VASP codebase? With special reference to Tomas Arias' flow-chart(s) [0]

Grad students these days will need to figure out their Altman-informed version of radiance (maybe easier if they spend more time on some dank corners of HN).

I'm jealous you found Chandrasekhar :) going to look at this to train understanding of human and/or AI pedagogy.

I too have my favorite Dover books (Lanczos, Yaglom, the "Green books") but I can't say I got any general techne out of them (yet)

https://www.amazon.com/Applied-Analysis-Cornelius-Lanczos/dp...

These are the underappreciated infra born of the preAI cold-war times (doubt postsoviet mathematicians have an equivalent. Especially not "Bourbaki" =P)!

Worth recommending to gen-A/Z so they have an inkling what semifunctional social infra looked like before *verflow/*stackexchange

[0] https://www.linkedin.com/posts/juarezlfdasilva_flowchart-of-...

Or page 95 https://dspace.mit.edu/bitstream/handle/1721.1/8282/50420077...

by gsf_emergency_6

12/13/2025 at 5:31:27 AM

When I was a kid I saw an ad for Feigenbaum's 3-volume "Handbook of AI" and got a used copy years later

There was a Volume IV added as well at some point[1]. I've had this entire set sitting on my shelf for ages now, intending to read the entire thing "one of these days" but somehow "one day" keeps not showing up. Still, if I live long enough, I still want to read it all eventually.

Hell maybe I'll pull Volume 1 off the shelf later tonight and read a few pages, just to put a stake in the ground and say I started it at least. :-)

[1]: https://www.amazon.com/Handbook-Artificial-Intelligence-IV/d...

by mindcrime

12/13/2025 at 8:18:30 PM

I picked these up at a used bookstore ages ago, since they had the three-volume set. My recommendation would be to familiarize yourself with just the table of contents that’s printed on the binding, and when you come across something adjacent in your day-to-day work (e.g. Search), review the papers in that section. Those books are an excellent snapshot of the field at the time.

by ebcode

12/15/2025 at 4:26:48 AM

I did wind up picking up Volume 1 this afternoon and starting to read some of it. It's a fascinating look back in time at some earlier days of AI. Which is right up my alley, as I'm pretty enthusiastic about studying the history of the field.

by mindcrime

12/13/2025 at 3:06:36 PM

> business rules engines, complex event processing, and related technologies are still marginal in the industry for reasons I don't completely understand

Translating between complex implicit intention in colloquial language and software and formal language used in proof assistants is usually very time consuming and difficult.

By the time you’ve formalized the rules, the context in which the rules made sense will have changed/a lot will be outdated. Plus time and money spent on formalizing rules is time and money not spent on core business needs.

by didericis

12/13/2025 at 10:10:15 PM

That's definitely true, but I do think production rules have some uses that are less obvious.

For instance, XSLT is not "an overcomplicated Jinja 2" but rather it is based on production rules but hardly anybody seems to know that, they just think it's a Jinja 2 that doesn't do what they want.

Production rules are remarkably effective at dealing with deep asynchrony, say a process that involves some steps done by people or some steps done by humans, like a loan application being processed by a bank that has to be looked at by a loan officer. They could be an answer to the async comm problems in the web browser. See also complex events processing.

Production rules could be a more disciplined way to address the issues addressed by stored procedures in databases.

I've written systems where production rules are used in the control plane to set up and tear down data pipelines with multiple phases in a way that can exploit the opportunistic parallelism that can be found in sprawling commercial batch jobs. (The Jena folks told me what I was doing wasn't supported but I'd spent a lot of time with the source code and there was no problem.)

by PaulHoule

12/13/2025 at 4:39:54 AM

I'd like to call out the work from Nada Amin in this area:

Dafny and verification-aware programming, including proof by induction to verify properties of programs (for example, that an optimizer preserves semantics). Dafny Sketcher (https://github.com/namin/dafny-sketcher)

Multi-stage programming, a principled approach to writing programs that write programs, and its incarnation in multi-stage relational programming for faster synthesis of programs with holes—with the theoretical insight that a staged interpreter is a compiler, and a staged relational interpreter for a functional language can turn functions into relations running backwards for synthesis. multi-stage miniKanren (https://github.com/namin/staged-miniKanren)

Monte Carlo Tree Search, specifically the VerMCTS variant, and when this exploration-exploitation sweet spot is a good match for synthesis problems. VerMCTS (https://github.com/namin/llm-verified-with-monte-carlo-tree-...), and Holey (https://github.com/namin/holey).

by juliangamble

12/13/2025 at 12:42:52 AM

> In 1994, came the Pentium with its FDIV bug: a probably insignificant but detectable error in floating-point division. The subsequent product recall cost Intel nearly half a billion dollars. John Harrison, a student of Mike’s, decided to devote his PhD research to the verification of floating-point arithmetic.

No mention of the effort by Boyer and Moore, then at their Computational Logic, Inc., to do a formal verification of the AMD FPU for the AMD5K86TM. The AMD chip shipped with no FDIV bug. [1]

[1] https://dl.acm.org/doi/abs/10.1109/12.713311

by Animats

12/13/2025 at 2:11:51 AM

ACL2 doesn't get a lot of love from the side of the verification community that focuses on the proof systems that are more academically popular (HOL family, CIC family, etc.). A lot of interesting industrial work has been done with ACL2 and related systems.

by porcoda

12/13/2025 at 4:58:21 AM

Yes. Been there, done that, with the pre-ACL2 Boyer-Moore prover. We had the Oppen-Nelson prover (the first SAT solver) handling the easy stuff, and used the Boyer-Moore prover for the hard stuff. Not that much manual work.

by Animats

12/13/2025 at 5:41:06 AM

I assume you mean first SMT solver when you refer to Oppen-Nelson? I thought their contribution was the basis for SMT methods.

by porcoda

12/13/2025 at 3:58:20 PM

I recently started reading "Specifying Systems: The TLA+ Language and Tools for Hardware and Software En" by Lawrence Lamport[0]. It is a good starting point for learning how to specify systems on the basis of mathematical proofs.

Since the new code is specifications in the age of AI, learning how to specify systems mathematically is a huge advantage because English is extremely ambiguous.

[0]: https://lamport.azurewebsites.net/tla/book-02-08-08.pdf

by hamiecod

12/13/2025 at 9:03:40 PM

I've had the same intuition. I've had mixed results in this area, although I'm certainly no expert. Recently I wanted to formalize a model of a runbook for a tricky system migration, to help me reason through some alternatives. I ended up writing a TLA+ spec before generating some visualizations, and also some possible prototypes in MiniZinc. All three (spec, visualizations, CP models) were vibe-coded in different sessions, in about that order, though most of my personal effort went into the spec.

While the later AIs quickly understood many aspects of the spec, they struggled with certain constraints whose intuitive meaning was concealed behind too much math. Matters which I had assumed were completely settled, because a precise constraint existed in the spec, had to be re-explained to the AI after implementation errors were found. Eventually, I added more spec comments to explain the motivation for some of the constraints, which helped somewhat. (While it's an untested idea, my next step was going to be to capture traces of the TLA+ spec being tested against some toy models, and including those traces as inputs when producing the implementations, e.g. to construct unit tests. Reasoning about traces seemed to be a fairly strong suit for the AI helper.)

In hindsight, I feel I set my sights a little too high. A human reader would have had similar comprehension problems with my spec, and they probably would have taken longer to prime themselves than the AI did. Perhaps my takeaway is that TLA+ is a great way to model certain systems mathematically, because precision in meaning is a great quality; but you still have to show sympathy to your reader.

by gmfawcett

12/14/2025 at 6:28:34 PM

Was the TLA spec just hard to understand for the reader or for a peer as well?

by hamiecod

12/14/2025 at 6:51:46 PM

That's a fair question, but I didn't have another person read it. (If I'm being honest, I think my colleagues would have looked at me funny. We don't exactly have a culture of using TLA+ to describe sysadmin processes here, and it felt a bit like a sledgehammer-swatting-fly even by my own standards! They thought the visualizations were cool, though...)

Many of my rules seemed pretty basic to me -- a lot of things like, "there is no target-node candidate whose ordinal is higher than the current target's and also satisfies the Good_Match predicate." But if I had been writing it for a human reader, rather than just to document constraints, I would have put in more effort to explain why the constraints existed in the first place (what's a Good match? Are there Poor matches? Why do we care? etc.). I didn't skip this step altogether but I didn't invest much time into it.

I did take care to separate "physics" rules from "strategy" rules (i.e, explicitly separating core actions and limits from objectives and approaches). That seemed to help the AI, and I'm sure it would have helped people too.

by gmfawcett

12/13/2025 at 10:09:21 AM

Lean4 seems to be very popular in the Math Olympics-solving AI startups (Harmonic etc).

by polskibus

12/13/2025 at 12:25:31 PM

…and is now being taught in combined “Formal Real Analysis”[1] courses to undergrads, and the lean prover community has a joint project to formalize the proof of Fermat’s Last Theorem, which is a lot of work but is progressing. It’s sort of weird to say there is no progress. It seems to me when you have a fields medal winner publishing lean4 formal proofs on github[2] to go with one of his books you are making a lot of progress.

[1] eg https://youtube.com/playlist?list=PLs6rMe3K87LHu03WWh9rEbEhh...

[2] https://github.com/teorth/analysis

by seanhunter

12/13/2025 at 11:50:35 AM

I think when Peter Thiel talks about stagnation it’s as much about the vibe of things as it is quantifying metrics of progress. I happen to agree with the idea that the vibe of progress has unilaterally focused on ai and computer technology even though this isn’t the case for metrics (e.g., CRISPR). I think the stagnation vibe has come from a series of issues such as decades of American political gridlock, Europes inability to commit to anything, the rise of the attention economy, the stagnation of Japan, the lack of a competitive focus for American markets (with no Soviet Union to defeat they seemed to have turned to defeating billionaire poverty). This list continues but it’s the confluence of all these things that gives the vibe of stagnation. It seems like there isn’t enough time to focus on anything anymore to actually get excited to drive it forward. Even though this isn’t the case. And there also isn’t the political space to celebrate things. Like it seems like any spacex accomplishment should be followed with the caveat that you don’t like Elon. Another way I think about this is that we live in this post cynicism world where we all have to couch every statement within some framework acknowledging harm to someone somehow. It’s hard to have a vibe of progress when every statement of progress includes an impact statement saying why that progress is harmful.

by mnky9800n

12/13/2025 at 11:09:10 PM

Very nice post thanks - I didn’t know about cakeml and bootstrapping formally verified compilers.

by Agingcoder

12/13/2025 at 12:59:09 AM

I wish he had just said 50 years of LCF, since he even mentions automath in the article but that was but that was late 60s

by ratmice

12/13/2025 at 7:29:36 AM

Yes, 50 years of LCF would have been much better. You should not talk about "50 years of proof assistants" and not mention Mizar which had the largest library of theorems for about half of that time.

by robinzfc

12/13/2025 at 6:35:44 AM

And now, Matthew Scherf has published "A Formal Specification of Advaita Vedānta in Classical High-Order Logic," and verified it in both Isabelle and Lean4. https://github.com/matthew-scherf/Advaita

by adyashakti

12/13/2025 at 3:54:18 PM

This is funny as well as amazing haha. This makes me wonder whether mathematics can prove the real truth or not since it does not take spirituality, conciousness and metaphysics (things we dont yet fully understand) into account.

by hamiecod