Filosofía de la ingeniería: Donald Knuth, programar es un arte

Puntos clave

• Programar es un arte, no solo ingeniería. Knuth tituló la obra de su vida The Art of Computer Programming a propósito, exigiéndole al código un estándar de belleza que ninguna batería de pruebas puede medir.
• El código es literatura escrita para humanos. La primera audiencia es la próxima persona que leerá el programa; el compilador es apenas la segunda. La legibilidad es un requisito de ingeniería de primer orden, no una cortesía.
• Gasta rigor solo donde cuenta; gasta contención en lo demás. Demuestra los algoritmos, analiza su costo con exactitud, lleva el oficio hasta el último glifo, y rehúsa volcar esfuerzo en el 97 % del código que no importa.
• «Optimización prematura» significa medir primero. La famosa frase es una disciplina de medición, no una excusa para el código lento: encuentra el puñado de puntos porcentuales críticos mediante perfilado, ataca solo esos y deja el resto legible.

El principio

«En lugar de imaginar que nuestra tarea principal es instruir a una computadora qué hacer, concentrémonos más bien en explicarles a los seres humanos qué queremos que haga una computadora.» —Donald Knuth¹

Una sola frase contiene toda la postura. Para Knuth, un programa no es ante todo un flujo de instrucciones dirigido a una máquina; es una pieza de escritura dirigida a una persona: el próximo lector, que normalmente eres tú mismo, seis meses después, habiéndolo olvidado todo. El compilador es una audiencia secundaria. La primera audiencia es humana, y el programa es literatura para esa audiencia o es un fracaso, por correcto que corra.

Es por eso que Knuth tituló la obra de su vida The Art of Computer Programming y no The Science ni The Engineering. Lo dice art de forma literal: un oficio perseguido por la calidad de lo hecho, sostenido en un estándar de belleza que ninguna batería de pruebas mide. La disciplina que se sigue es exigente de un modo muy específico. Dice: haz el pequeño número de cosas que de verdad importan, y hazlas exactamente bien. Demuestra que tus algoritmos son correctos. Analiza su costo con precisión en vez de adivinar. Compón la página para que pueda leerse sin fricción. Y —la parte que todos citan y casi todos malinterpretan— no gastes tu oficio en el 97 % del código que no importa, porque el esfuerzo vertido en el lugar equivocado no es artesanía, es desperdicio disfrazado de diligencia.

Así que el principio tiene dos caras que parecen opuestas y en realidad son una sola. Rigor en todo lo que cuenta; contención en todo lo que no. La destreza está en saber cuál es cuál, y la respuesta de Knuth a cómo lo sabes es la misma que recorre toda esta serie: mides. La famosa frase sobre la optimización prematura no es una licencia para escribir código lento. Es una exigencia de que encuentres el puñado de puntos porcentuales críticos por evidencia antes de tocar nada, la misma convicción de que el rendimiento es una propiedad que construyes y mides, no un repaso que añades al final.

Contexto

Donald Ervin Knuth nació el 10 de enero de 1938 en Milwaukee, Wisconsin.² Obtuvo licenciatura y maestría en el Case Institute of Technology —Case quedó tan impresionado que le otorgó la maestría a la vez que la licenciatura en 1960— y un doctorado en matemáticas en Caltech en 1963.² Se incorporó al profesorado de Stanford en 1969, fue nombrado Fletcher Jones Professor of Computer Science en 1977 y, en 1990, asumió un título que prácticamente inventó para sí mismo: Professor of The Art of Computer Programming.² Lleva años como profesor emérito en Stanford y aún trabaja, a mano y por correo, en el mismo proyecto que lo ocupa desde hace más de seis décadas.

Ese proyecto empezó como un accidente de alcance. En 1962, Addison-Wesley le encargó al joven Knuth escribir un libro sobre compiladores.³ Empezó a escribir y concluyó que no podía explicar honestamente cómo construir un compilador sin antes asentar la teoría fundamental que lo sustenta: ordenamiento, búsqueda, estructuras de datos, el análisis de cuánto tardan realmente los algoritmos. El libro único se convirtió en una serie planificada. El primer volumen, Fundamental Algorithms, apareció en 1968. El plan creció con el tiempo hasta siete volúmenes, y la obra sigue inconclusa hoy.³ American Scientist lo nombró después uno del centenar de libros que dieron forma a un siglo de ciencia, y el New York Times lo llamó «el tratado que define la profesión».³ Es, por consenso razonable, lo más cercano que tiene la informática a una biblia.

En 1974, Knuth recibió el Premio A.M. Turing de la ACM —el máximo honor de la computación— «por una serie de contribuciones mayores al análisis de algoritmos y al diseño de lenguajes de programación, y en particular por sus contribuciones más significativas al “arte de la programación de computadoras” a través de su serie de conocidos libros».⁴ Su conferencia Turing se tituló, de modo característico, «Computer Programming as an Art».⁴

La obra

The Art of Computer Programming y el análisis de algoritmos

A Knuth se le llama el padre del análisis de algoritmos, y el título está ganado.² Antes de TAOCP, los programadores razonaban sobre los algoritmos en gran medida de manera informal: este se siente más rápido, ese parece derrochador. El proyecto de Knuth fue poner ese razonamiento sobre una base matemática rigurosa: derivar, con exactitud, cuántas operaciones realiza un algoritmo en función de su entrada, y hacerlo con la misma precisión que un matemático lleva a un teorema. Popularizó la notación asintótica «O grande» que todo programador usa ahora para describir cómo escala el costo.² El punto nunca fue la notación; fue la convicción de que el costo de un programa es una cantidad cognoscible que deberías calcular, no una sensación que deberías tener.

Los propios volúmenes son célebres por una especie de completitud obsesiva —cada afirmación demostrada, cada algoritmo analizado, cada caso límite atendido— y por los cheques de recompensa que Knuth ofrece por cualquier error encontrado. El cheque es de 2,56 dólares, que él describe como «un dólar hexadecimal», porque 256 centavos son 100 en base dieciséis.⁵ La cantidad es un chiste; la disciplina que hay detrás no lo es. Knuth está poniendo dinero sobre la mesa apostando a que su obra es correcta, e invita al mundo a demostrarle lo contrario. El estado pulido y todavía autorizado de TAOCP décadas después es, en parte, producto de esa apuesta permanente.⁵ (Dejó de enviar cheques literales en 2008 tras un fraude bancario, y ahora emite certificados contra un imaginario «Bank of San Serriffe»: el rigor sobrevivió; el rastro de papel cambió de forma.)⁵

La optimización prematura y el 3 % crítico

La frase más citada de la ingeniería de software es de Knuth, y casi siempre se cita mal, despojada de la cláusula que le da sentido. Aquí está el pasaje completo, de su artículo de 1974 «Structured Programming with go to Statements», en ACM Computing Surveys:

«Los programadores malgastan enormes cantidades de tiempo pensando en —o preocupándose por— la velocidad de las partes no críticas de sus programas, y esos intentos de eficiencia tienen en realidad un fuerte impacto negativo cuando se consideran la depuración y el mantenimiento. Deberíamos olvidarnos de las pequeñas eficiencias, digamos en torno al 97 % de las veces: la optimización prematura es la raíz de todos los males. Sin embargo, no deberíamos dejar pasar nuestras oportunidades en ese 3 % crítico.»⁶

Leída entera, no es un argumento contra el rendimiento. Es un argumento a favor de la medición. El punto de Knuth es empírico: un programa pasa casi todo su tiempo en una fracción minúscula de su código, y optimizar el otro 97 % —las partes que apenas se ejecutan— cuesta esfuerzo real, rinde casi nada y vuelve el código más difícil de leer y de confiar en él. El «mal» no es la optimización. El mal es optimizar antes de saber adónde se va el tiempo: gastar el oficio en fe en lugar de en evidencia. La disciplina que receta es lo opuesto a la pereza: encuentra el 3 % crítico mediante perfilado y luego atácalo con fuerza.

Una palabra sobre la atribución, porque le importa a cualquiera que cite la frase con honestidad. La frase aparece en el artículo de Knuth de 1974, en su propia prosa. Pero quince años después el propio Knuth se refirió a ella como «el dictum de Hoare», atribuyéndola a Tony Hoare, y cuando se le preguntó a Hoare directamente, él también la repudió, sugiriendo que podría ser de Dijkstra y que era mejor tratarla como «cultura común o folclore».⁷ Así que la afirmación más limpia y exacta es esta: la redacción que todos citamos es de Knuth, publicada por Knuth en 1974; la idea él generosamente se negó a reclamar como solo suya. Esa negativa es ella misma característica. El hombre que te paga por encontrar sus errores no está interesado en arrogarse un mérito que no está seguro de merecer.

TeX, METAFONT y la tipografía digital como oficio

En 1976, Knuth recibió las pruebas de galera de la segunda edición del Volumen 2 y quedó horrorizado. La composición en metal caliente que había hecho hermosa la primera edición estaba siendo reemplazada por la fotocomposición temprana, y el resultado era feo: las matemáticas, en particular, se veían mal.³ Otra persona lo habría aceptado como el costo del progreso. Knuth, que no podía permitir que sus propios libros se compusieran mal, decidió en 1977 dedicar un poco de tiempo a construir algo mejor. El poco de tiempo se volvió casi una década. El resultado fue TeX, el sistema de composición tipográfica, y METAFONT, el sistema acompañante para diseñar las propias fuentes; ambos quedaron terminados y publicados como libros en 1986.³

Ningún rodeo de su carrera revela más. Un matemático interrumpió su magna obra durante ocho años para resolver, desde primeros principios, el problema de poner caracteres hermosos en una página, porque la apariencia de la página no era separable, en su mente, de la calidad del trabajo. TeX sigue siendo el estándar para componer matemáticas en todo el mundo, cuarenta años después. Es la declaración más clara posible de que, para Knuth, el artefacto se extiende hasta el último píxel del último glifo: el oficio no se detiene en el código. Es la versión del ingeniero de rematar la parte trasera de la cerca: la parte que el lector nunca nota conscientemente es la parte que él se negó a hacer mal.

La programación literaria

Si un programa está hecho para que lo lean humanos, entonces la manera en que lo escribimos —en orden de compilador, con comentarios añadidos como una ocurrencia tardía— está al revés. En 1984, en un artículo en The Computer Journal, Knuth propuso invertirla. Llamó a la práctica programación literaria, y construyó un sistema llamado WEB para llevarla a cabo.¹

En la programación literaria escribes un único documento en el orden del pensamiento humano: prosa que explica lo que pretendes, con fragmentos de código entretejidos donde la explicación los pide, en cualquier secuencia que se lea mejor. Luego dos herramientas lo procesan: tangle extrae el código en el orden que necesita el compilador, y weave produce la documentación formateada y compuesta que lee una persona.⁸ WEB combinaba Pascal y TeX; el posterior CWEB, con Silvio Levy, hizo lo mismo para C.⁸ La propia descripción de Knuth es que «un programa se concibe mejor como una red… la tarea del programador es enunciar esas partes y esas relaciones, en el orden que sea mejor para la comprensión humana».⁸

La programación literaria nunca se volvió práctica generalizada, y vale la pena ser honesto al respecto. Pero la convicción que la sustenta —que la explicación no es documentación del programa sino que es el programa, que la legibilidad es un requisito de ingeniería de primer orden y no una cortesía— ha vencido en silencio. Es el mismo instinto que nos hace valorar el código que se explica solo, y es la respuesta más profunda que da Knuth a la pregunta de para qué sirve programar.

El método

El método es consistente a lo largo de sesenta años y cuatro dominios: algoritmos, tipografía, diseño de lenguajes y la propia escritura.

Escribe primero para el lector humano. La máquina es la segunda audiencia. Un programa, como una demostración o un párrafo, se juzga por si la próxima persona puede seguirlo. La programación literaria es esta convicción convertida en herramienta.¹⁸

Demuéstralo, luego pruébalo. «Cuidado con los errores en el código de arriba; solo lo he demostrado correcto, no lo he probado», escribió Knuth en un memorando de 1977: una frase que resulta graciosa precisamente porque él es la rara persona que de verdad demuestra su código.⁹ El chiste contiene la disciplina: la corrección se argumenta, no se da por sentada, y una demostración es necesaria pero aun así no suficiente. Debes ambas.

Analiza el costo; no lo adivines. El tiempo de ejecución de un algoritmo es una cantidad que se deriva matemáticamente, no una corazonada. Este es el acto fundacional del análisis de algoritmos, y es por eso que la «O grande» está en boca de todo programador.²

Mide antes de optimizar. La optimización prematura es la raíz de todos los males porque gasta el oficio en fe. Encuentra el 3 % crítico por evidencia; optimiza solo allí; deja el resto legible.⁶

Deja que el oficio llegue hasta el último glifo. Detener la obra de su vida durante ocho años para construir TeX es el método en su forma más pura: la calidad del artefacto no se detiene donde se detiene el código. Termina en el borde de la página.³

Protege la concentración profunda. Knuth renunció al correo electrónico el 1 de enero de 1990 —«he sido un hombre feliz desde entonces», escribió— con el razonamiento de que el correo es para las personas cuyo trabajo es estar al tanto de las cosas, mientras que su trabajo es estar en el fondo de las cosas, estudiando un tema con suficiente profundidad para explicarlo bien.¹⁰ El rechazo de la interrupción no es excentricidad; es la condición previa del trabajo.

Cadena de influencia

Quiénes lo moldearon

La tradición matemática, en especial la combinatoria y la teoría de números. Knuth llegó a la programación como matemático, y trajo el estándar innegociable del matemático —una afirmación no es conocimiento hasta que se demuestra— a un campo que venía arreglándoselas con la intuición. (Influencia formativa)

El encargo de Addison-Wesley de 1962. El accidente que fijó la trayectoria. Cuando le pidieron un libro sobre compiladores, Knuth siguió el problema hasta sus cimientos y nunca volvió a subir; el análisis de algoritmos existe en su forma moderna porque él se negó a escribir el libro fácil que le habían pedido. (Influencia directa)

La tipografía en metal caliente y el libro impreso. Su estándar de cómo debía verse una página compuesta se formó con la artesanía de una era anterior de la imprenta, que es exactamente por qué las galeras fotocompuestas de 1976 fueron intolerables y TeX se volvió necesario. (Influencia formativa)

A quiénes moldeó

A todo programador en activo. El análisis O grande, el estudio riguroso de los algoritmos y el propio TAOCP son alfabetización básica. Una generación aprendió lo que cuesta un algoritmo gracias a Knuth, hubiera o no abierto sus libros.

A la publicación matemática y científica del mundo. TeX y LaTeX son el sustrato de prácticamente todo artículo de matemáticas, todo preprint de física y todo libro técnico compuesto en los últimos cuarenta años. El rodeo de ocho años de Knuth se convirtió en infraestructura.

A la cultura de la corrección y la legibilidad. La programación literaria, los cheques de recompensa, «demostrado correcto, no probado»: estos marcaron un tono. La expectativa de que el código serio deba ser a la vez demostrablemente correcto y agradable de leer es, en parte, legado de Knuth.

El hilo conductor

Knuth y Edsger Dijkstra son los dos grandes apóstoles de la corrección en esta serie, y la tensión productiva entre ellos es lo más instructivo de ella. Ambos escribían a mano, desconfiaban de la máquina como árbitro de la verdad e insistían en que un programa debía razonarse, no solo ejecutarse. Pero donde Dijkstra sostenía que las pruebas solo pueden mostrar la presencia de errores y nunca su ausencia —e inclinaba con fuerza hacia la demostración como único terreno real—, el «solo lo he demostrado correcto, no lo he probado» de Knuth le guiña un ojo al límite de la propia demostración: él demuestra y prueba, y te paga cuando ambas fallan. Pragmatismo dentro del rigor. John Carmack se sitúa en el mismo eje desde el otro extremo —perfilar el punto caliente, entender la máquina hasta sus cimientos, atacar el bucle crítico—, que es exactamente el «3 % crítico» de Knuth apuntado al techo del hardware en lugar de a la demostración. Y el Unix de Thompson y Ritchie, donde C se construyó para que un sistema operativo pudiera leerse y portarse en vez de soldarse a mano a una máquina, es la misma creencia que Knuth hizo explícita: los programas se escriben para humanos. (Puente de la serie)

Lo que extraigo de esto

La lección que conservo es que la frase más citada de mi campo es una disciplina de medición vestida con el disfraz de un aforismo. «La optimización prematura es la raíz de todos los males» se usa para excusar el código lento y perezoso, que es el inverso exacto de lo que Knuth quiso decir. Lo que él en realidad exige es más difícil que optimizarlo todo u optimizar nada: perfila primero, localiza el 3 % crítico por evidencia, vuelca tu oficio exactamente en eso y deja el resto legible. Es el mismo estándar que la calidad es la única variable: la pregunta nunca es «¿es lo bastante rápido?» ni «¿es lo bastante ingenioso?», sino «¿tengo evidencia de dónde está realmente el costo?». Es la verja de la evidencia aplicada al rendimiento: una corazonada sobre el punto caliente no es conocimiento hasta que la has medido.

En el mundo en el que construyo ahora —agentes, bucles de herramientas, llamadas a modelos— las dos caras de Knuth son ambas estructurales. La contención: no optimices una instrucción ni una ruta de recuperación que no hayas medido; casi toda la latencia vive en unas pocas llamadas, y el resto es ruido que deberías dejar legible. El rigor: donde cuenta, demuéstralo, pruébalo y pon algo en juego apostando a que tienes razón. Y la convicción de la programación literaria es la que encuentro más relevante a los cincuenta años: cuando un sistema puede generar código más rápido de lo que nadie puede leerlo, escribir primero para el lector humano deja de ser una gentileza y se vuelve lo único que mantiene inspeccionable al sistema. Esa convicción —que el gusto es un sistema técnico que mides y defiendes, no una sensación que afirmas— corre en línea recta desde un encargo de libro de 1962 hasta un arnés de agentes de 2026.

Preguntas frecuentes

¿Cuál es la filosofía de ingeniería de Donald Knuth?

Knuth trata la programación como un arte cuya primera audiencia es humana, no la máquina: «explicarles a los seres humanos qué queremos que haga una computadora».¹ La disciplina que se sigue empareja un rigor exigente con una contención deliberada: demuestra que los algoritmos son correctos, analiza su costo matemáticamente y remata el oficio hasta la página compuesta, mientras rehúsa gastar esfuerzo en optimizar las partes de un programa que no importan. Resuelve cuál es cuál mediante la medición, que es el verdadero significado de su frase sobre la optimización prematura.⁶

¿Qué significaba en realidad «la optimización prematura es la raíz de todos los males»?

Es una exigencia de medición, no un rechazo del rendimiento. La cita completa de 1974 es: «Deberíamos olvidarnos de las pequeñas eficiencias, digamos en torno al 97 % de las veces: la optimización prematura es la raíz de todos los males. Sin embargo, no deberíamos dejar pasar nuestras oportunidades en ese 3 % crítico.»⁶ El punto de Knuth es que un programa pasa casi todo su tiempo en una pequeña fracción de su código; optimizar el otro 97 % malgasta esfuerzo y daña la legibilidad. La disciplina es perfilar primero, encontrar el puñado de puntos porcentuales críticos y optimizar solo esos. Usar la frase para excusar el código lento invierte su significado.

¿Inventó Knuth la frase de la «optimización prematura», o fue Hoare?

La redacción que todos citan es de Knuth, publicada en su propio artículo de 1974 en Computing Surveys, «Structured Programming with go to Statements».⁶ Quince años después, sin embargo, el propio Knuth se refirió a ella como «el dictum de Hoare» y la atribuyó a Tony Hoare; cuando se le preguntó a Hoare directamente, él también repudió la autoría, sugirió que podría remontarse a Dijkstra y dijo que era mejor tratarla como «cultura común o folclore».⁷ El resumen honesto: la frase tal como la citamos es de Knuth, pero él generosamente declinó reclamar la idea como solo suya.

¿Qué creó Donald Knuth?

Knuth escribió The Art of Computer Programming (comenzado en 1962, primer volumen en 1968, en curso: el tratado que define la informática) y fundó el análisis moderno de algoritmos, popularizando la notación O grande.²³ Frustrado por la mala composición tipográfica de sus propios libros, creó el sistema de composición TeX y el sistema de fuentes METAFONT, ambos publicados en 1986 y todavía estándar para la publicación matemática.³ También originó la programación literaria y el sistema WEB, la práctica de escribir programas para que los lean humanos.¹⁸ Recibió el Premio Turing de la ACM de 1974.⁴

Fuentes