How a 1936 paper on an abstract machine, a 1950 forecast on a wartime computer, and a controversial 1976 proof of a map-coloring puzzle became the ancestry of today's formally verified mathematics.

A recreated ENIAC-era plugboard bay, mid-rewire between problems — the machine had to be physically re-cabled for each new calculation. — Image prompt and art direction by Brecht Corbeel; generation pending.
This is a source-grounded history of four intertwined threads in twentieth- and twenty-first-century mathematics: the theoretical limits of computation established by Alan Turing in 1936, the first large-scale numerical simulation of a physical system on the ENIAC in 1950, the first computer-assisted proof of a major theorem (the four-color theorem, 1976), and the subsequent rise of machine-checked formal proof through systems such as Coq, HOL Light, Isabelle, and Lean. Each milestone is traced to a primary or peer-reviewed source, with vendor claims, expert disagreement, and forward-looking scenarios explicitly separated from established fact.
Every field has an origin story it tells about itself, and mathematics tells several at once, because “mathematics” in the twentieth century split into at least three practices that used to be one: proving theorems by hand, computing numerical approximations to physical systems, and — starting in the 1970s — using machines to check both. This is a history of how those three practices grew apart and then, by the 2010s, began growing back together. It follows four documented turning points: Alan Turing’s 1936 paper that defined, for the first time, what “computable” formally means [1]; the 1950 ENIAC run that produced the first computer-generated numerical weather forecast [2] [3]; the 1976 proof of the four-color theorem, the first major theorem whose proof leaned on a computer in a way mathematicians could not simply re-check by hand [4]; and the subsequent decades in which proof assistants — Coq, HOL Light, Isabelle, Lean — turned “the computer checked this” from a controversial claim into a routine one [5] [6] [8] [9].
Turing’s paper “On Computable Numbers, with an Application to the Entscheidungsproblem” was submitted to the London Mathematical Society in May 1936 and published later that year [1]. It answered a question posed by David Hilbert: is there a mechanical procedure that can decide, for any statement in a formal logical system, whether that statement is provable? Turing’s route to the answer was to first pin down, with total precision, what a “mechanical procedure” even is. He described an abstract machine — a strip of tape divided into cells, a read/write head, and a finite table of instructions — capable of moving along the tape, reading a symbol, writing a symbol, and changing its internal state according to the table. A number, or a decision problem, is “computable” if some such machine, given enough tape and enough time, produces it.
This is worth separating cleanly from what came after: Turing’s 1936 result is a piece of mathematical logic, not an engineering blueprint. No physical Turing machine was built in 1936, and none needed to be — the argument is about which problems admit any finite mechanical procedure, and the answer, for the Entscheidungsproblem, was no. Turing proved that no such general procedure exists, by constructing a statement equivalent to “does this machine halt on this input,” and showing that a machine that could answer that question for every machine and input would have to answer it for itself in a way that produces a contradiction — the now-famous halting problem. The independent significance for this history is that Turing’s abstract machine became the reference model against which every subsequent notion of “what a computer can do” — including every proof assistant and every numerical simulation described below — is still implicitly measured. When a modern formal-verification system checks a proof, it is checking a computation in Turing’s sense; when a numerical simulation approximates a weather system, it is running one.
None of that engineering existed yet in 1936. It took a second world war, and a shift from paper-and-pencil ballistics tables to electronic calculation, before a machine approximating the theoretical picture existed at any scale.

Figure 1. Hand-crank mechanical calculators of the kind used for pre-electronic numerical work, one still caught mid-turn. — Image prompt and art direction by Brecht Corbeel; generation pending.
The Electronic Numerical Integrator and Computer, built at the University of Pennsylvania’s Moore School of Electrical Engineering under U.S. Army contract, was completed in 1945 and publicly demonstrated on February 14–15, 1946 [3]. It contained roughly 18,000 vacuum tubes, was programmed by physically rearranging patch cables and setting switches on its function tables — there was no stored program in the modern sense — and was built primarily to compute artillery firing tables faster than human “computers” (the word then still meant a person with a desk calculator) could produce them by hand.
ENIAC’s significance for this history is not that it was fast — by later standards it was not — but that it made a new kind of mathematics practical: solving equations that have no closed-form solution by marching a numerical approximation forward in small time steps, a technique that existed on paper long before ENIAC but had been too laborious to carry out at any useful scale by hand. The clearest demonstration of this was meteorological. In 1950, Jule Charney, Ragnar Fjörtoft, and John von Neumann published “Numerical Integration of the Barotropic Vorticity Equation” in the journal Tellus, describing a series of 24-hour forecasts computed on ENIAC from real atmospheric data using a simplified single-layer model of the atmosphere [2]. Producing each 24-hour forecast took roughly 24 hours of machine time — a rough parity between simulated time and computation time that the paper itself treats as a practical milestone rather than a triumph, since it meant the method was not yet fast enough to forecast ahead of the weather it was predicting.
It is worth being precise about what the 1950 result actually showed, separate from later popular retelling. The barotropic vorticity equation is a considerable simplification of the full equations governing atmospheric flow — it ignores vertical motion and treats the atmosphere as a single layer — chosen specifically because it was the most complex model the available machine and the available data could handle in a tractable computation. The paper’s four 24-hour forecasts were compared against the observed pressure patterns and judged qualitatively reasonable, not quantitatively precise by later standards. What the experiment established, as a matter of documented fact rather than retrospective legend, is that a nonlinear partial differential equation describing a real physical system could be numerically integrated forward on an electronic machine from real observational data and produce a forecast a meteorologist judged useful. That single demonstration is the ancestor of every large-scale numerical simulation practiced today, climate models included, even though the equations, the resolution, and the hardware are now separated from 1950 by roughly nine orders of magnitude in computing power.

Figure 2. A forecasting room modeled on the 1950 ENIAC weather run: hand-plotted pressure contours beside the machine computing the next time step. — Image prompt and art direction by Brecht Corbeel; generation pending.
A model of the barotropic vorticity equation used in that 1950 work can be written, in simplified form, as
\frac{\partial \zeta}{\partial t} + J(\psi, \zeta) = 0, \qquad \zeta = \nabla^2 \psi,
where \psi is the stream function describing the horizontal flow, \zeta is the relative vorticity, and J(\psi,\zeta) is the Jacobian term expressing advection of vorticity by the flow itself. This is stated here not to reproduce the numerics of the original run but because the equation exposes exactly what made the problem hard to do by hand and tractable by machine: it is a single nonlinear evolution equation, and marching it forward requires repeating the same arithmetic over many small time steps across many grid points — precisely the kind of repetitive, exact, high-volume calculation electronic computation was built for and hand computation was not.
Three decades later, computation entered pure mathematics through a different door: not simulating a physical system, but exhaustively checking a large but finite number of logical cases inside a proof.
The four-color conjecture — that any map drawn on a plane, with regions sharing a border colored differently, can always be colored with only four colors — dates to 1852 and had resisted proof for over a century [4]. In 1976, Kenneth Appel and Wolfgang Haken, both at the University of Illinois, announced a proof [4]. Their strategy, building on decades of prior partial results, was to show that every possible planar map must contain at least one of a specific, finite set of local configurations (an “unavoidable set”), and that each configuration in that set could be shown “reducible” — meaning any map containing it could be four-colored if a smaller map could be. Carried out completely, this reduces the infinite claim (“every map”) to a finite claim about a specific list of local patterns. The catch was the size of that list: nearly two thousand configurations, each requiring its own case-by-case verification, a volume of checking no human mathematician could complete reliably by hand. Appel and Haken wrote programs to perform the reducibility checks by computer, running for well over a thousand hours of processing time across the full effort.

Figure 3. A university computing-center line printer mid-run during a large case-check, modeled on the 1976 four-color theorem verification. — Image prompt and art direction by Brecht Corbeel; generation pending.
This is the moment this history treats as pivotal, and it is worth stating plainly why it was controversial at the time rather than simply celebrated. A proof, in the mathematical tradition inherited from Euclid, is an argument a competent reader can follow and check step by step. Appel and Haken’s proof was not fully of that kind: no person could read the computer’s case analysis line by line and vouch for it the way a referee vouches for a hand-written argument; the confidence rested instead on the correctness of the program and the machine that ran it, which is a different — and, to many mathematicians at the time, a less satisfying — kind of certainty. The proof was accepted, but the discomfort it created did not go away; it instead became the seed of a research question that took another three decades to answer well: if a computer’s case-checking is part of the proof, how do you check the computer?
The direct response to that discomfort was to stop asking a general-purpose program to perform an unverified calculation, and instead build systems that check every logical step of a proof — including any step delegated to computation — against a small, formally specified logical kernel, so that trusting the proof reduces to trusting a short, independently auditable kernel rather than trusting an entire opaque program.
Systems along these lines had existed since the 1970s (de Bruijn’s Automath project is usually cited as the earliest full realization of the idea), but the four-color theorem became the test case that most visibly forced the question, because it was exactly the kind of proof the discomfort was about. In 2005, Georges Gonthier produced a complete formalization of the four-color theorem in the Coq proof assistant, checked by Coq’s kernel rather than by any unverified auxiliary program, and described the effort in a widely read 2008 account in the Notices of the American Mathematical Society [5]. The formalization did not merely re-run Appel and Haken’s case analysis; it re-derived the mathematical argument, including the combinatorial reducibility checks, inside a system whose trusted core is orders of magnitude smaller and more scrutable than an arbitrary Fortran or Pascal program from 1976.

Figure 4. A modern proof-assistant workstation mid-session: the current proof goal still open, one tactic not yet applied. — Image prompt and art direction by Brecht Corbeel; generation pending.
A second, harder test case followed. The Kepler conjecture — that no packing of equal spheres in three dimensions is denser than the familiar cubic and hexagonal close-packing arrangements — was proved by Thomas Hales and Samuel Ferguson in 1998 using a mix of conventional argument and large-scale numerical optimization over thousands of cases. Referees spent years attempting to certify the numerical portion and in the end could not certify it with full confidence, a genuinely unusual outcome for a mathematics journal. Hales responded by launching the Flyspeck project to re-derive the entire proof, including its numerical inequalities, inside the HOL Light and Isabelle proof assistants. The completed formalization was published in Forum of Mathematics, Pi in 2017, over a decade after the project began, with more than twenty contributors credited on the final paper [6]. That a proof combining discrete combinatorics with continuous nonlinear optimization could be pushed all the way to a machine-checked certificate is the historically significant fact here — a demonstration that the method generalizes beyond graph-coloring case counts to genuinely analytic arguments.

Figure 5. A physical sphere-packing model of the kind used to argue the Kepler conjecture, one sphere still being lowered into place. — Image prompt and art direction by Brecht Corbeel; generation pending.
A separate and stranger episode from the same broad period shows automated reasoning working in the opposite direction — not verifying a human proof, but finding one no human had constructed. In 1996, William McCune’s automated theorem prover EQP found a proof, entirely on its own, that Robbins algebras are Boolean algebras — a question about a minimal axiom set posed by Herbert Robbins in the 1930s and open for over sixty years [7]. The proof search ran for about eight days and produced a valid but famously terse sixteen-line proof object that mathematicians describe as logically airtight and, at the same time, close to unreadable as an explanation — correct without being illuminating, which is its own kind of lesson about what machine-found proofs can and cannot yet give a human reader.
The Robbins episode is a useful corrective to any tidy narrative in which computers only ever check what mathematicians already believed. EQP was not verifying a conjectured argument; it was searching an enormous space of possible equational derivations with no guidance beyond the axioms themselves, and it found a path through that space that no specialist in the area had located by hand across six decades of attempts, including attempts by mathematicians who had spent careers on lattice theory and Boolean algebra. The subsequent scholarly reaction split along a line that recurs throughout this history: some mathematicians treated the sixteen-line certificate as a complete answer, since every step is mechanically checkable and the axioms are unambiguous; others argued that a proof which cannot be narrated back to a human in a way that builds understanding has answered the formal question while leaving the mathematical question — why is it true, in terms a person can reason about — still open. Later researchers working from McCune’s certificate produced more readable reconstructions of the argument by hand, translating the machine’s derivation back into a form built for human comprehension rather than machine verification. That translation effort is itself informative: it shows that machine-found and human-readable proofs are not the same artifact even when they establish the same theorem, and that converting between the two is its own nontrivial mathematical labor rather than a formality.
The historical picture is genuinely two threads, not one, and it is worth resisting the temptation to collapse them into a single “computers entered mathematics” narrative, because they answer different questions and carry different kinds of risk. The simulation thread — descending from the 1950 ENIAC forecast through modern numerical weather and climate models — produces approximations whose accuracy is bounded by model simplification, resolution, and data quality; a simulation can be executed flawlessly and still be wrong about the world if its equations or inputs are wrong. The proof-checking thread — descending from Appel and Haken through Coq, HOL Light, Isabelle, and now Lean — produces claims that, if the kernel and the formal statement of the theorem are both correct, are true with the same certainty as any hand-checked proof, but that certainty says nothing about whether the formalized statement actually captures the mathematician’s intended claim in natural language, which remains a human judgment.
Modern proof-assistant projects increasingly draw on both threads at once. The Lean project — developed initially by Leonardo de Moura and now stewarded by a dedicated foundation — hosts Mathlib, a large community-built library of formalized mathematics, and by 2026 documents formalization collaborations touted by outside organizations including Google DeepMind, Amazon Web Services, and Microsoft Research [8]. Those are institutional and vendor claims about adoption and should be read as such — a project’s own website describing its partners is evidence of engagement, not an independent measurement of formal verification’s overall uptake in mathematics or software engineering. Coq, meanwhile, was renamed the Rocq Prover in its most recent major releases, continuing as an actively maintained system with its own platform releases through 2026 [9]. Where experts genuinely disagree is on how far the method generalizes: formalizing a single theorem, however deep, is a different task from formalizing a working mathematician’s everyday judgment about what is worth proving, and mathematicians in the field are divided on how much of ordinary research mathematics will ever be routinely formalized, as opposed to only its most prominent, disputed, or previously-uncertain results.
Stated as established fact, verifiable against the sources above: Turing’s 1936 paper defined computability and proved the Entscheidungsproblem unsolvable [1]; ENIAC produced the first electronically computed numerical weather forecasts in 1950 [2] [3]; the four-color theorem’s 1976 proof was the first major theorem to rely on machine computation for a portion no human fully hand-checked [4]; that proof was later independently re-derived inside the Coq kernel in 2005, published 2008 [5]; the Kepler conjecture’s Flyspeck formalization was completed and published in 2017 [6]; and EQP found a valid, if inscrutable, machine proof of the Robbins conjecture in 1996 [7].
Stated as vendor or project claim, not independently audited here: any specific figure a proof-assistant project’s own site gives for adoption, partner counts, or the fraction of a mathematical library formalized [8] [9] should be treated as self-reported until an independent survey states otherwise.
Stated as analysis rather than fact: the framing that simulation and formal verification are “two threads” answering different questions is this article’s interpretation of the historical record, offered to explain why a simulation being fast and a proof being machine-checked are not evidence of the same kind of correctness.
Stated as scenario, not prediction: it is plausible that within the next decade a majority of newly published results in at least some narrow subfields (finite group theory and parts of formalized analysis are the most-cited candidates) could carry machine-checked formal proofs as a condition of publication in specialist venues, on the observable indicator that the rate of new Mathlib-style library contributions continues to grow rather than plateau. This is not a prediction this article makes with confidence; the disconfirming condition would be a plateau or decline in formalization-library contribution rates over the next five years, which would indicate the practice has settled into a specialist niche rather than becoming a broader publication norm.
The throughline from 1936 to today is not that computers made mathematics easier; in several of the episodes above, they made it harder to trust in a new way, and the following decades of proof-assistant development were substantially a response to that discomfort rather than a simple victory lap. Turing’s paper supplied the abstract notion of what a mechanical check even is. ENIAC’s 1950 forecast showed that a machine could turn an intractable equation into a tractable approximation of the physical world. The four-color theorem showed that the same kind of machine could also participate in pure proof, and that doing so raised a legitimate question about what counts as having proved something. Coq, HOL Light, Isabelle, and Lean are the multi-decade answer to that question — not a replacement for mathematical judgment, but a way of making a machine’s contribution to a proof as scrutable, in principle, as a human argument on paper.
Originally published at https://absolutedigitalpublishers.com/articles/from-origins-to-frontier-a-history-of-mathematics-proof-and-scientific-computation.