⏱️ Lectura: 13 min
Cada vez que alguien propone formalizar matemáticas en 2026, la pregunta llega casi automática: ¿por qué no usar Lean?. La pregunta es legítima, pero esconde un sesgo histórico fuerte. Para la mayoría de programadores que llegaron a este mundo en los últimos dos o tres años, los demostradores de teoremas nacieron con Lean, con la prueba del teorema de Liquid Tensor de Scholze y con la migración masiva de mathlib. Lawrence Paulson, profesor en Cambridge y arquitecto del sistema Isabelle desde hace cuatro décadas, publicó el 23 de abril de 2026 un ensayo titulado Why not just use Lean? que se viralizó en Hacker News, Reddit y Twitter académico, y que pone las cosas en perspectiva.
📑 En este artículo
El argumento de Paulson no es un ataque a Lean. Lean es, en sus propias palabras, un gran lenguaje con buenas herramientas, una librería enorme y una comunidad entusiasta. Su crítica es otra: la formalización matemática lleva casi 60 años en marcha, y el monocultivo es peligroso. Para los desarrolladores en LATAM que están descubriendo este campo, entender la historia detrás del debate cambia completamente la forma de elegir herramienta.
Qué pasó: el ensayo de Paulson y la reacción
El 23 de abril de 2026, Paulson publicó en su blog personal el texto Why not just use Lean?. En menos de 48 horas, el post llegó a la portada de Hacker News con más de 600 comentarios y disparó una ola de discusiones en r/math, r/programming y comunidades académicas en Discord. El detonante fue una frase: me han dicho que cuando uno propone formalizar matemáticas hoy, hay que explicar por qué no se está usando Lean.
Paulson, que hace 40 años abandonó el mundo de los tipos dependientes (la familia teórica donde viven Coq/Rocq y Lean), dice que la presión actual le recuerda exactamente por qué se fue: cultismo, insularidad y conformidad. No son palabras menores viniendo de alguien que conoció a Robin Milner, vio nacer LCF en Edimburgo y construyó uno de los demostradores más usados en industria.
El ensayo se estructura en cinco partes: el origen real de la formalización (AUTOMATH, 1968), la rama Boyer-Moore que casi nadie recuerda, la familia LCF que dio HOL e Isabelle, la emergencia de la comunidad Lean, y el problema filosófico de equiparar todo a propositions as types. Lo provocativo no es ninguno de esos puntos por separado, sino el conjunto: la idea de que la formalización matemática es un campo joven es, según Paulson, falsa.
Contexto e historia: los demostradores de teoremas no empezaron en 2020
Para entender por qué el ensayo importa, hay que reconstruir la genealogía real. Aquí es donde la mayoría de tutoriales modernos tienen un agujero de varias décadas.
1968: AUTOMATH y la primera formalización completa
NG de Bruijn, matemático holandés, presentó AUTOMATH en 1968. Para 1977, su estudiante van Benthem Jutting ya había formalizado el libro Foundations of Analysis de Edmund Landau, que construye los números complejos partiendo solamente de lógica pura. Jutting trabajó con clases de equivalencia y con conjuntos de números racionales. Probó formalmente la completitud de Dedekind de la recta real. Esa hazaña no se igualó hasta los años 90, cuando John Harrison la repitió en HOL Light y Jacques Fleuriot en Isabelle/HOL.
Paulson sostiene que casi cualquier cosa formalizada hoy en cualquier sistema podría haberse formalizado en AUTOMATH. Sus problemas eran prácticos: notación horrible y cero automatización. Las pruebas eran largas e ilegibles. Pero la base teórica ya estaba.
1973: Boyer, Moore y la rama paralela
Desde otro rincón completamente distinto, Robert Boyer y J Moore presentaron en 1973 un sistema bajo el título Proving theorems about LISP functions. Su objetivo no era matemática general sino verificación de código. Sin embargo, su computational logic terminó usándose para resultados profundos: el teorema de incompletitud de Gödel, la reciprocidad cuadrática, el teorema de Banach-Tarski. La encarnación actual se llama ACL2 y se usa de forma rutinaria en Intel y AMD para verificar hardware. Ser diferente, dice Paulson, también lleva lejos.
Los 80 y 90: la familia LCF
El sistema Edinburgh LCF, dirigido por Robin Milner, se enfocaba en teoría de lenguajes de programación. Pero su idea de usar un lenguaje funcional como metalenguaje (de ahí ML) tuvo un impacto enorme. De ahí salieron HOL en Cambridge, Coq en INRIA, Nuprl en Cornell, e Isabelle. La verificación de hardware de punto flotante (ese mismo bug del Pentium FDIV de 1994 que costó 475 millones de dólares a Intel) trajo la necesidad de análisis real serio. Harrison probó el teorema de los números primos vía la fórmula integral de Cauchy. Para 2014, los sistemas LCF ya tenían a su haber:
- El teorema de los cuatro colores (Coq, Gonthier 2005)
- El teorema de Feit-Thompson sobre orden impar (Coq, 2012)
- La consistencia relativa del axioma de elección
- El segundo teorema de incompletitud de Gödel
- La prueba de Hales de la conjetura de Kepler (HOL Light + Isabelle, 2014)
2017 en adelante: la ola Lean
Paulson reconoce que sabe poco del desarrollo interno de Lean, pero sí del fenómeno social. Tom Hales, después de probar la conjetura de Kepler, propuso construir una librería con definiciones modernas (esquemas de Grothendieck, espacios perfectoides) y eligió Lean. Habló del proyecto en el Newton Institute. Kevin Buzzard, en Imperial College, lo escuchó y decidió usar Lean para enseñar topología a estudiantes de licenciatura. Lo demás es historia: nació mathlib, llegó la prueba de Liquid Tensor de Scholze formalizada por la comunidad, y Lean se volvió sinónimo de formalización matemática moderna.
Datos y cifras: cómo se compara el ecosistema en 2026
Para dimensionar el debate, conviene mirar números. Aunque las cifras varían según fuente y fecha, los órdenes de magnitud cuentan una historia clara:
- mathlib (Lean 4): alrededor de 1.7 millones de líneas de código, más de 300 contribuidores activos, decenas de miles de teoremas formalizados.
- Archive of Formal Proofs (Isabelle): más de 800 entradas revisadas por pares desde 2004, cubriendo desde criptografía hasta análisis funcional.
- HOL Light: mantenido principalmente por Harrison, sigue liderando la lista de los Formalizing 100 Theorems.
- Rocq (antes Coq): base del sistema CompCert (compilador C verificado, usado en aviónica) y de la prueba del teorema de los cuatro colores.
- ACL2: usado por Intel, AMD y Centaur para verificar millones de líneas de RTL en chips de producción.
El punto que Paulson resalta no es qué sistema tiene más teoremas, sino que cada uno cubre nichos donde los demás flaquean. Si necesitás verificar hardware, ACL2 sigue siendo la mejor herramienta. Si querés trabajar con clases de equivalencia, Isabelle o incluso AUTOMATH son más cómodos que Rocq, donde los usuarios bromean con el setoid hell.
💭 Clave: El debate sobre cuál demostrador usar es muy similar al debate sobre cuál lenguaje de programación usar. La respuesta correcta depende del problema, del equipo y de qué librerías ya existen para tu dominio.
Impacto y análisis: el problema del monocultivo
El argumento más fuerte de Paulson no es histórico sino científico. La diversidad de fundamentos lógicos es un activo, no un defecto. Lean usa Calculus of Inductive Constructions con teoría de tipos dependientes. Isabelle/HOL usa Higher-Order Logic clásica. ACL2 usa lógica computacional de primer orden. Cuando un teorema profundo se formaliza en sistemas con fundamentos distintos, la confianza en el resultado crece de forma multiplicativa, no aditiva.
El obsesión con “propositions as types”
Paulson dedica varias secciones a desarmar la idea de que todo debería verse a través de la lente de propositions as types (la correspondencia de Curry-Howard). Sí, $\forall$, $\exists$, $\to$ tienen una lectura natural como tipos. Pero forzar esa lectura sobre todo, incluyendo igualdad, conjuntos cociente y razonamiento clásico, genera fricción innecesaria. La comunidad Lean tomó una decisión clave al abandonar la obsesión constructivista que había dominado Coq durante décadas. Esa fue, dice Paulson, la razón por la que Lean despegó en matemáticas mientras Coq se quedaba.
Qué significa para LATAM
Para un desarrollador en Buenos Aires, México DF o San Salvador que quiere meterse al mundo de la verificación formal en 2026, el ensayo de Paulson da tres pistas prácticas:
- No elegir herramienta por moda. Si vas a aprender uno solo, Lean tiene la curva más amigable, mathlib enorme y comunidad activa. Pero si tu trabajo es verificación de software (no matemáticas puras), Isabelle, ACL2 o incluso Why3 pueden ser mejores.
- Aprender la lógica subyacente, no solo el sintaxis. Los conceptos de tipos dependientes, lógica de orden superior y lógica computacional son transferibles. La sintaxis de cada sistema, no.
- Cuidado con la evangelización. Cuando una comunidad insiste demasiado en que su herramienta es la única válida, suele estar pasando algo más que técnica.
Comparación práctica: probar conmutatividad de la suma
Para que el debate no quede en abstracto, mirá cómo se prueba un teorema básico (la conmutatividad de la suma de naturales) en tres sistemas distintos:
(* Isabelle/HOL — estilo Isar, declarativo *)
lemma add_commute: "(m::nat) + n = n + m"
proof (induct m)
case 0 show ?case by simp
next
case (Suc m) thus ?case by simp
qed
-- Lean 4 — táctico, tipos dependientes
theorem add_commute (m n : Nat) : m + n = n + m := by
induction m with
| zero => simp
| succ m ih => simp [Nat.add_succ, ih]
; ACL2 — Lisp, automatizado
(defthm add-commute
(equal (+ m n) (+ n m)))Los tres prueban exactamente lo mismo. Cada uno representa una filosofía distinta: Isabelle prioriza la legibilidad humana, Lean la composición algebraica de tácticas, ACL2 la automatización agresiva. Ninguno es mejor; son trade-offs.
Qué sigue: la genealogía visual
Para cerrar el panorama histórico, este es el árbol genealógico simplificado de los principales demostradores. Notá cómo casi todas las ramas modernas convergen en algún momento con ML, el lenguaje creado para LCF en los 70:
graph TD
A["AUTOMATH (1968)"] --> B["de Bruijn / Jutting"]
C["LCF (1972)"] --> D["HOL (1988)"]
C --> E["Coq (1989)"]
C --> F["Isabelle (1986)"]
C --> G["Nuprl (1984)"]
D --> H["HOL Light (1996)"]
E --> I["Rocq (2024)"]
J["NQTHM (1973)"] --> K["ACL2 (1996)"]
L["Lean 1 (2013)"] --> M["Lean 4 (2021)"]
M --> N["mathlib4"]
F --> O["Isabelle/HOL"]
O --> P["AFP"]💡 Tip: Si estás empezando, instalá Lean 4 conelan(similar a rustup) en Windows conwinget install LeanProver.Lean4, en macOS/Linux concurl https://elan.lean-lang.org/elan-init.sh -sSf | sh. Para Isabelle, descargá el bundle desde isabelle.in.tum.de, que incluye IDE y todas las dependencias.
El futuro inmediato
Lean seguirá creciendo y mathlib seguirá siendo referencia obligatoria para matemáticas. Pero la respuesta de Paulson va a tener efecto: ya hay grupos planeando formalizaciones cruzadas, donde el mismo teorema se prueba en Lean y en Isabelle para chequeo independiente. La integración con asistentes de IA (LLM-augmented theorem proving) está ocurriendo en paralelo en todos los sistemas. Y el debate filosófico sobre constructivismo, clásicos vs intuicionistas, propositions as types vs lógica clásica, sigue siendo material vivo, no historia muerta.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es un demostrador de teoremas?
Es un programa que permite escribir definiciones matemáticas y demostraciones en un lenguaje formal, y verifica mecánicamente que cada paso lógico es correcto. A diferencia de un compilador (que verifica sintaxis y tipos), un demostrador verifica que tu razonamiento matemático no tiene huecos.
¿Lean reemplazará a Isabelle, Coq y los otros?
Es muy improbable. Cada sistema tiene fortalezas distintas: Isabelle domina en lógica clásica y archivos de pruebas industriales, ACL2 en verificación de hardware, HOL Light en análisis real, Rocq en teoría de lenguajes de programación. Lean lidera en matemáticas modernas, pero liderar no es monopolizar.
¿Qué sistema debería aprender primero en 2026?
Si tu interés son matemáticas modernas, Lean 4 con mathlib4. Si tu interés es verificar software, Isabelle/HOL o Why3. Si querés verificar hardware, ACL2. Si te interesa la teoría de tipos pura, Rocq o Agda. La curva inicial es similar en todos; lo que cambia es la librería disponible.
¿Quién es Lawrence Paulson?
Profesor de Computational Logic en la Universidad de Cambridge desde los 80. Fundador y arquitecto principal del sistema Isabelle. Autor de libros clásicos sobre demostración asistida por computador. Su crítica a Lean no viene de un outsider, sino de uno de los pocos actores activos que ha vivido todas las olas del campo.
¿Mathlib es realmente tan grande como dicen?
Sí. Con más de 1.7 millones de líneas y cientos de contribuidores activos, mathlib4 es probablemente la librería de matemáticas formalizada más extensa que ha existido. Eso, sin embargo, no implica que sea la única: el Archive of Formal Proofs de Isabelle tiene 800+ entradas revisadas por pares desde 2004.
¿Vale la pena aprender estos sistemas si no soy matemático?
Para muchos casos sí. La verificación formal de software crítico (aviónica, medicina, criptografía, contratos inteligentes) es un campo en crecimiento. Empresas como AWS, Galois, Runtime Verification y proyectos como CompCert demuestran que el conocimiento es comerciable, no solo académico.
Referencias
- Lawrence Paulson — Why not just use Lean? — el ensayo original que disparó el debate.
- Lean Prover Community — sitio oficial del lenguaje Lean 4 y mathlib.
- Isabelle Theorem Prover — sistema desarrollado por Cambridge y TU München.
- Wikipedia — AUTOMATH — historia del primer demostrador para formalizar matemáticas, NG de Bruijn 1968.
- Wikipedia — Lean (proof assistant) — entrada con cronología y referencias académicas del proyecto Lean.
- Hacker News — discusión comunitaria del ensayo de Paulson en abril de 2026.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios