Filosofía de la ingeniería: Edsger Dijkstra, la elegancia no es opcional

Ideas clave

• La elegancia no es opcional. Para Dijkstra, la simplicidad es la condición previa para la corrección, no una recompensa que se cobra después: no puedes demostrar lo que no puedes comprender por completo.
• La demostración supera a las pruebas. “Las pruebas muestran la presencia, no la ausencia de errores.” La confianza en la corrección nace de razonar sobre un programa, nunca de acumular pruebas que pasan.
• Piensa antes de programar. Diseñó su algoritmo de la ruta más corta sin lápiz ni papel, obligándolo a ser lo bastante pequeño para sostenerlo en una sola cabeza: la restricción produjo la elegancia.
• Escribir es pensar. Los manuscritos EWD, compuestos a mano con pluma estilográfica y sin deshacer, hacían que un argumento se sostuviera o fallara en tinta; la misma disciplina aplicada a la prosa.

El principio

“La simplicidad es requisito previo para la fiabilidad.” – Edsger W. Dijkstra, atribuida (c. 1975)¹

La frase pervive como un aforismo de una sola línea, casi una nota al margen, asociada a sus memorandos deliberadamente provocadores de alrededor de 1975. Despojada de su contexto suena a eslogan, pero Dijkstra la entendía como una afirmación lógica estricta. La fiabilidad no es algo que se añada a un sistema complicado probándolo con más empeño. Un sistema que no puedes entender por completo es un sistema que no puedes demostrar correcto, y un sistema que no puedes demostrar correcto fallará de formas que no anticipaste. La simplicidad no es una preferencia estilística que compite con la corrección. Es aquello de lo que la corrección está hecha. No te está permitido tener lo segundo sin lo primero.

Esto invierte la forma en que realmente se escribe la mayoría del software. El instinto común es construir la cosa, hacerla funcionar y luego probarla hasta que dejen de aparecer errores, tratando la simplicidad como un lujo que perseguir más adelante, si queda tiempo. Toda la carrera de Dijkstra fue un argumento de que ese orden está invertido y es peligroso. Su frase más citada es la advertencia que se deriva directamente de él: “Las pruebas muestran la presencia, no la ausencia de errores.”² Una prueba que pasa no te dice nada sobre las entradas que no intentaste. La única manera de saber que un programa no tiene errores es razonar sobre él, y solo puedes razonar sobre lo que es lo bastante simple para sostenerlo en una sola cabeza humana. La elegancia, para Dijkstra, “no es un lujo prescindible, sino un factor que a menudo decide entre el éxito y el fracaso.”³

Esa convicción lo sitúa en el nacimiento de esta serie. Donde Linus Torvalds remodela un problema hasta que el caso especial desaparece y John Carmack reduce un problema a su núcleo veloz, Dijkstra aportó la afirmación de fondo que ambos heredaron: la solución elegante y la solución correcta son la misma solución. Es el argumento original para tratar el gusto como un sistema técnico en lugar de como una indulgencia estética, y el argumento a favor de la demostración por encima de la plausibilidad décadas antes de que alguien lo llamara así.

Contexto

Edsger Wybe Dijkstra nació el 11 de mayo de 1930 en Róterdam, Países Bajos, y murió el 6 de agosto de 2002 en Nuenen.⁴ Su padre era químico y presidente de la Sociedad Química Neerlandesa; su madre era matemática con, según él mismo contaba, un sentido inusualmente claro de cuándo un argumento matemático era elegante y cuándo simplemente funcionaba. Estudió matemáticas y física teórica en Leiden, y luego aceptó un empleo de programación en el Centro Matemático de Ámsterdam en 1952, en un momento en que “programador” todavía no era una profesión reconocida. Cuando intentó registrarlo como su ocupación en su acta de matrimonio en 1957, las autoridades neerlandesas, según se cuenta, no lo aceptaron, porque oficialmente no existía tal trabajo; tuvo que escribir “físico teórico” en su lugar.⁴

Ese detalle no es una anécdota trivial. Dijkstra pasó el resto de su vida insistiendo en que la programación era una disciplina intelectual rigurosa y no un oficio administrativo, y la insistencia comenzó antes de que la disciplina tuviera nombre. Ocupó un puesto en el Centro Matemático, después se convirtió en profesor en la Universidad Tecnológica de Eindhoven en 1962, pasó la década de 1970 como investigador en Burroughs Corporation y en 1984 asumió la Cátedra Centenaria Schlumberger de Ciencias de la Computación en la Universidad de Texas en Austin, donde permaneció hasta su jubilación en 1999.⁴

En 1972 recibió el Premio Turing de la ACM. Vale la pena leer la mención completa, porque nombra el principio mejor que cualquier resumen: “Por sus contribuciones fundamentales a la programación como un desafío intelectual elevado; por su elocuente insistencia y demostración práctica de que los programas deben componerse correctamente, no solo depurarse hasta la corrección; por su iluminadora percepción de los problemas en los fundamentos del diseño de programas.”⁵ Compuestos correctamente, no solo depurados hasta la corrección. Esa frase es el hombre entero.

La obra

El algoritmo de la ruta más corta (1956, publicado en 1959)

En 1956 le pidieron a Dijkstra que encontrara un problema que luciera la nueva computadora ARMAC en su inauguración oficial: algo que una audiencia no técnica pudiera seguir. Eligió la ruta más corta entre dos de 64 ciudades neerlandesas, porque cualquiera podía entender la pregunta y comprobar la respuesta. La solución le llegó de una forma que nunca se cansó de relatar: “Una mañana estaba de compras en Ámsterdam con mi joven prometida y, cansados, nos sentamos en la terraza de un café a tomar una taza de café, y yo estaba pensando justamente en si podría resolverlo, y entonces diseñé el algoritmo de la ruta más corta.”⁶ Le llevó unos veinte minutos.

El método con el que lo encontró es la lección. “Una de las razones por las que es tan bonito”, dijo más tarde, “fue que lo diseñé sin lápiz ni papel. Aprendí después que una de las ventajas de diseñar sin lápiz ni papel es que casi te ves obligado a evitar todas las complejidades evitables.”⁶ No podía apoyarse en borradores, así que la idea tenía que ser lo bastante pequeña para sostenerla por completo en su mente. La restricción produjo la elegancia. No lo publicó hasta tres años después – el artículo de 1959 “A Note on Two Problems in Connexion with Graphs”, en Numerische Mathematik, apenas supera una página – porque, como él decía, la programación todavía no se consideraba una actividad lo bastante respetable como para escribir sobre ella.⁶

El algoritmo es voraz: siempre expande primero el nodo no visitado más cercano, un frente de onda que se expande y alcanza cada punto por su distancia más corta a su debido turno. Es lo bastante simple como para explicarlo en la mesa de un café, y es demostrablemente óptimo: la primera vez que el frente de onda toca la meta, esa ruta no puede ser superada. Aquí lo simple y lo correcto no están en tensión. Son el mismo hecho.

“Go To Statement Considered Harmful” y la programación estructurada (1968)

En 1968 Dijkstra envió una carta a Communications of the ACM bajo el título “A Case Against the Goto Statement”. El editor, Niklaus Wirth, la retituló “Go To Statement Considered Harmful”, una frase que dio origen a todo un género de imitaciones y que hoy es más famosa que cualquier cosa de la carta en sí.⁷ El argumento de Dijkstra no era una guía de estilo. Era epistemológico. Un goto sin restricciones permite que el control salte a cualquier parte, lo que significa que, para entender qué hace un programa en una línea dada, quizá tengas que rastrear cada camino que pudo haber llevado hasta allí. El texto del programa y el comportamiento del programa se separan. Con control estructurado – secuencia, selección y bucles – el texto y la ejecución se mantienen en correspondencia, y puedes razonar sobre un bloque leyendo el bloque.

El argumento es el mismo principio que la restricción de la ruta más corta, aplicado al diseño de lenguajes: mantén la cosa lo bastante pequeña para razonar sobre ella. La programación estructurada no consistía en prohibir una palabra clave. Consistía en preservar la capacidad del humano de demostrar, leyendo, que el programa es correcto. La lista de su vocabulario que recita la mención del Turing – “abrazo mortal”, “semáforo”, “programación sin go-to”, “programación estructurada” – es un registro de hasta qué punto remodeló el lenguaje en el que piensan los programadores.⁵

Su trabajo en sistemas operativos llevaba el mismo ADN. El sistema multiprogramación THE (1968) se construyó como niveles de abstracción estrictamente estratificados, cada uno verificable por sí mismo. Para coordinar procesos concurrentes inventó el semáforo y sus operaciones P y V, y planteó el problema de los Filósofos comensales como una destilación didáctica del bloqueo mutuo y la inanición: una pregunta difícil de concurrencia hecha lo bastante pequeña para sostenerla en la mente.⁴⁵ Más tarde llegaron la autoestabilización y, en A Discipline of Programming (1976), el cálculo de transformadores de predicados / precondición más débil: un método para derivar un programa y su demostración de corrección juntos, de la mano, en lugar de escribir código y esperar verificarlo después.⁴⁵

El programador humilde: la demostración por encima de las pruebas (1972)

La conferencia del Premio Turing de Dijkstra, “The Humble Programmer” (EWD340), es la formulación más clara de por qué la simplicidad es una preocupación moral y no meramente práctica. Su afirmación central trata sobre el tamaño de la mente humana. “El programador competente es plenamente consciente del tamaño estrictamente limitado de su propio cráneo; por lo tanto, aborda la tarea de programar con total humildad y, entre otras cosas, evita los trucos ingeniosos como la peste.”⁸ El ingenio no es una virtud. Es una apuesta a que puedes sostener en tu cabeza más de lo que en realidad puedes, y la apuesta se salda en producción, en tu contra.

La conferencia desemboca en una receta que se lee como la carta fundacional del software correcto por construcción: “Haremos un trabajo de programación mucho mejor, siempre que abordemos la tarea con plena conciencia de su tremenda dificultad, siempre que nos ciñamos a lenguajes de programación modestos y elegantes, siempre que respetemos las limitaciones intrínsecas de la mente humana y abordemos la tarea como Programadores Muy Humildes.”⁸ Las pruebas, en este marco, son fundamentalmente inadecuadas, no porque sean inútiles, sino porque solo pueden muestrear el espacio de entradas. La forma canónica más larga de su advertencia, de “Notes on Structured Programming”, es inequívoca: “¡Las pruebas de un programa pueden usarse para mostrar la presencia de errores, pero nunca para mostrar su ausencia!”⁹ Si quieres ausencia de errores, tienes que demostrarla, y solo puedes demostrar lo que puedes comprender.

Los manuscritos EWD como práctica (1960s–2002)

Durante aproximadamente cuarenta años Dijkstra escribió una serie numerada de manuscritos – memorandos, demostraciones, informes de viaje, ensayos y argumentos – antepuestos con sus iniciales, “EWD”. La serie llega hasta EWD1318, con más de mil documentos reales; los números superan a los documentos porque asignaba un número cuando empezaba una pieza, y no todas se terminaban.⁴¹⁰ La mayoría se compusieron a mano, con una caligrafía célebremente precisa y una pluma estilográfica. No redactaba en una computadora. Escribía un manuscrito, lo fotocopiaba y lo enviaba por correo a un pequeño círculo de colegas, que lo copiaban y lo reenviaban a su vez: un samizdat anterior a internet que dio a los EWD una influencia desproporcionada en relación con el hecho de que casi ninguno se publicó formalmente.⁴¹⁰ La serie completa está hoy digitalizada y disponible de forma gratuita en el E.W. Dijkstra Archive de UT Austin.¹⁰

La práctica era inseparable de la filosofía. Escribir a mano, despacio, sin deshacer, impone la misma disciplina que diseñar sin lápiz ni papel: no puedes esconderte detrás del volumen ni de la revisión. Un argumento se sostiene o no, y te comprometes con él en tinta. Los EWD son lo que se ve cuando un ingeniero trata la escritura misma como una herramienta para pensar con claridad, y la claridad como el objetivo entero.

El método

El método es una única convicción aplicada sin tregua a lo largo de cuarenta años.

Hazlo lo bastante pequeño para razonar sobre ello. El algoritmo del café, el flujo de control estructurado, el sistema estratificado THE, la destilación de los Filósofos comensales: cada uno es un acto de encoger un problema hasta que una mente humana pueda sostenerlo entero y comprobarlo. La complejidad que no puedes inspeccionar es complejidad en la que no puedes confiar.

Demuestra, no pruebes. Las pruebas muestrean; la demostración certifica. El cálculo de transformadores de predicados de Dijkstra existe para que la demostración y el programa se deriven juntos, no para que uno se escriba y el otro se atornille encima. “Compuestos correctamente, no solo depurados hasta la corrección” es el método en cinco palabras.⁵

Trata la elegancia como evidencia, no como adorno. Cuando una solución es fea, esa fealdad suele ser una señal de que el problema no se ha entendido. La elegancia “decide entre el éxito y el fracaso” porque la forma elegante es la que tiene menos lugares donde estar equivocada.³

Escribe para pensar. Los EWD no eran documentación producida después del trabajo. Eran el trabajo: el razonamiento hecho visible, en un medio que castigaba los manotazos al aire. Diseñar sin lápiz ni papel y luego comprometer el resultado a la pluma estilográfica es la misma disciplina dos veces.

Cadena de influencia

Quiénes lo formaron

Su madre, la matemática. Dijkstra le atribuía su sentido de la elegancia matemática: el instinto entrenado para distinguir cuándo una demostración no solo es válida, sino limpia. Esa distinción, entre un argumento que funciona y un argumento que es bello, se convirtió en el eje de toda su carrera. (Influencia formativa)

El esfuerzo de Algol 60. Dijkstra coconstruyó uno de los primeros compiladores de Algol 60, y la estructura de bloques y la recursión del lenguaje le dieron la materia prima para la programación estructurada. Algol fue la prueba de que un lenguaje de programación podía diseñarse para la claridad en lugar de acumularse por conveniencia. (Influencia directa)

La tradición matemática de la demostración. Formado como matemático y físico antes de que existiera la “ciencia de la computación”, Dijkstra importó por completo el estándar de la demostración. Para él, un programa era un objeto matemático, y la pregunta nunca era “¿parece que funciona?”, sino “¿puedes demostrar que tiene que funcionar?”. (Influencia formativa)

A quiénes formó

Todo programador que escribe código estructurado. La desaparición del goto de la programación cotidiana, la universalidad de la secuencia/selección/iteración y todo el vocabulario de la concurrencia – semáforos, bloqueo mutuo, exclusión mutua – son su legado operando de forma invisible en cada base de código escrita desde entonces.

Los métodos formales y la verificación de programas. El cálculo de transformadores de predicados y el ideal del correcto por construcción son los ancestros directos de la verificación moderna, la comprobación de modelos y el código que carga su propia demostración. El resurgimiento actual del software de sistemas formalmente verificado es el argumento de Dijkstra encontrándose por fin con un hardware lo bastante rápido para ejecutarlo.

La autoimagen de la disciplina. Más que cualquier artefacto concreto, Dijkstra estableció la idea de que la programación es una rama de las matemáticas aplicadas que merece rigor, no un oficio que se aprende por ensayo y error. La conciencia del campo, para bien y para mal, todavía habla en su cadencia.

El hilo conductor

Dijkstra es la fuente de la que fluye el resto de esta serie. El “buen gusto” de Linus Torvalds – la reescritura donde el caso especial se desvanece – es la simplicidad-como-corrección de Dijkstra en el idioma de un hacker del kernel: menos ramas significa menos lugares donde estar equivocado. El núcleo veloz y simple de John Carmack es la misma sustracción apuntada al techo del hardware en lugar de a la demostración. Y la insistencia de Andrej Karpathy en reconstruir un sistema desde cero para entenderlo de verdad es el “diseñar sin lápiz ni papel” de Dijkstra con un sombrero de aprendizaje profundo. Los cuatro discrepan en casi todo salvo en lo único que importa: la estructura elegante no se aplica encima de la solución correcta. Es la solución correcta. (Puente de la serie)

Lo que me llevo de esto

La frase a la que vuelvo es la inversión: la simplicidad es el requisito previo para la fiabilidad, no una recompensa que cobras después de alcanzarla. La mayoría del software lento y frágil no es lento y frágil porque alguien se saltara las pruebas. Es lento y frágil porque nadie lo hizo nunca lo bastante pequeño para entenderlo, así que nadie pudo razonar sobre él, así que la única estrategia de calidad disponible fue probar hasta que los errores visibles dejaran de aparecer, lo cual, como dijo Dijkstra, no certifica nada. La inversión es el mismo estándar que la calidad como única variable: la pregunta nunca es “¿pasaron las pruebas?”, sino “¿entiendo esto lo bastante bien como para saber que es correcto?”.

En el mundo en el que construyo ahora – agentes de IA, bucles de herramientas, sistemas que generan código más rápido de lo que ningún humano puede leerlo – la advertencia de Dijkstra es más aguda que nunca. Cuando un agente escribe mil líneas y las pruebas están en verde, esa es exactamente la situación que él describió: no se ha mostrado la presencia de errores, y su ausencia no puede mostrarse. El movimiento Dijkstra consiste en negarse a dejar que la comprensión se reduzca a medida que la generación crece: en insistir en que el sistema siga siendo lo bastante pequeño, lo bastante estratificado y lo bastante legible como para que alguien todavía pueda demostrar que es correcto. Esa disciplina es la razón por la que trato la capa de verificación como portante incluso cuando ningún humano lee el código: las pruebas muestran presencia, no ausencia, y un frente de onda de marcas de verificación verdes no es una demostración.

Preguntas frecuentes

¿Cuál es la filosofía de ingeniería de Edsger Dijkstra?

Dijkstra sostenía que la simplicidad es el requisito previo para la fiabilidad: un programa debe ser lo bastante simple para que un humano lo comprenda por completo, porque solo un programa comprensible puede ser razonado y demostrado correcto. Argumentaba que los programas deben “componerse correctamente, no solo depurarse hasta la corrección”, que las pruebas pueden mostrar la presencia de errores pero nunca su ausencia, y que la elegancia no es adorno sino “un factor que a menudo decide entre el éxito y el fracaso”. El ingenio, a su juicio, era un vicio, porque excedía la capacidad limitada de la mente humana.³⁵⁸⁹

¿Qué inventó Edsger Dijkstra?

Dijkstra inventó el algoritmo de la ruta más corta que lleva su nombre (concebido en 1956, publicado en 1959), introdujo el semáforo y las operaciones P/V para coordinar procesos concurrentes, construyó el sistema multiprogramación estratificado THE, formuló el problema de los Filósofos comensales, impulsó la programación estructurada, originó el concepto de autoestabilización en sistemas distribuidos y desarrolló el cálculo de transformadores de predicados / precondición más débil para derivar programas junto con sus demostraciones de corrección (en A Discipline of Programming, 1976). Recibió el Premio Turing de la ACM en 1972.⁴⁵

¿Qué significa “Las pruebas muestran la presencia, no la ausencia de errores”?

Significa que una prueba solo puede demostrar que un error existe, al desencadenarlo; nunca puede demostrar que no existen errores, porque ningún conjunto finito de pruebas cubre toda entrada posible. Dijkstra lo enunció en la Conferencia de Ingeniería de Software de la OTAN de 1969 y dio la forma canónica más larga en “Notes on Structured Programming”: “¡Las pruebas de un programa pueden usarse para mostrar la presencia de errores, pero nunca para mostrar su ausencia!”. Su conclusión era que la confianza en la corrección debe venir de la demostración y de diseñar programas lo bastante simples para razonar sobre ellos, no de acumular pruebas que pasan.²⁹

¿Por qué escribía Dijkstra a mano y distribuía los manuscritos EWD por fotocopia?

Los EWD eran una serie de más de mil manuscritos numerados que Dijkstra escribió a lo largo de aproximadamente cuatro décadas, la mayoría a mano con pluma estilográfica, que luego fotocopiaba y enviaba por correo a un pequeño círculo que los copiaba y reenviaba a su vez. Escribir despacio a mano, sin una tecla para deshacer, imponía la misma disciplina que su costumbre de diseñar algoritmos sin lápiz ni papel: obligaba a la claridad y castigaba los manotazos al aire, porque un argumento comprometido en tinta tenía que sostenerse de verdad. La serie completa está archivada y disponible de forma gratuita en la Universidad de Texas en Austin.⁶¹⁰

Fuentes