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.
>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)
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...
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.
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.)
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]
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).
Nada Amin website - https://namin.seas.harvard.edu/
[1] eg https://youtube.com/playlist?list=PLs6rMe3K87LHu03WWh9rEbEhh...
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
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.
