Sobre el Pesimismo Documental de Naur
En 1985, Peter Naur argumentó que programar es construir teoría, y que la teoría no puede capturarse completamente en documentación. Pero su pesimismo es más acotado de lo que se supone. Se aplica a la documentación técnica de artefactos, no a la documentación como empresa humana. La IA no “resuelve” el problema, pero crea condiciones donde la transmisión de teoría se vuelve más probable.
En 1985, el científico de la computación Peter Naur publicó “Programming as Theory Building”—un ensayo breve e influyente que argumenta que programar es fundamentalmente construir modelos mentales, no producir código. La teoría del programador sobre cómo los problemas del mundo real se mapean al software es el producto esencial; el código y la documentación son artefactos secundarios. Crucialmente, Naur afirmó que esta teoría no puede capturarse completamente en documentación, porque involucra conocimiento tácito que resiste la formalización. (Ver nuestro resumen o el ensayo original en versión española.)
Pero el pesimismo de Naur apunta a la documentación técnica—especificaciones, código, documentos de diseño—no a toda comunicación escrita. El Renacimiento demuestra que los documentos pueden transmitir teoría cuando están escritos para hacerlo.
La colaboración con IA no resuelve el problema de documentación reduciendo el esfuerzo (eso malinterpreta el argumento epistemológico de Naur). Pero sí crea condiciones novedosas: articulación forzada, diálogo preservado, iteración con menor fricción. Estas hacen más probable la transmisión de teoría, aunque nunca sea completa.
Capítulos
- Prefacio — Quién escribió esto y por qué importa la advertencia sobre el argumento falaz
- El Argumento Real de Naur — Epistemológico, no económico
- El Argumento Falaz a Evitar — Lo que la IA no resuelve
- El Alcance del Pesimismo — Solo documentación de artefactos
- Evidencia de la Transmisión Cultural — El argumento del Renacimiento
- Por Qué Falla la Documentación Técnica — El análisis de Cockburn
- Articulación Forzada — La IA como interlocutor
- Preservación del Diálogo — Capturando el proceso de resolución
- Lo Que Permanece Sin Resolver — El conocimiento tácito persiste
- Hacia una Documentación Resiliente — Recomendaciones prácticas
- Conclusión — Síntesis
Referencias
- Alexander, C. (1977). A Pattern Language. Oxford University Press.
- Alexander, C. (1979). The Timeless Way of Building. Oxford University Press.
- Cockburn, A. (2006). Agile Software Development (2da ed.). Addison-Wesley.
- Kernighan, B. W., & Plauger, P. J. (1976). Software Tools. Addison-Wesley.
- Kuhn, T. S. (1970). The Structure of Scientific Revolutions (2da ed.). University of Chicago Press.
- Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15.
- Polanyi, M. (1973). Personal Knowledge. Routledge & Kegan Paul.
- Ryle, G. (1949). The Concept of Mind. Hutchinson.
Este documento está vivo. Evoluciona con nuestra práctica.