Lamport, que ahora tiene 73 años y es investigador en Microsoft, ha sido reconocido por una serie de importantes avances que empezaron en la década de 1970. Diseñó algoritmos que permiten el funcionamiento fiable del software incluso aunque se ejecute en una colección de ordenadores independientes o en componentes que sufren retrasos de comunicación o fallan.
Ese trabajo, en un campo que se conoce como computación distribuida, sigue siendo clave para los amplios centros de datos usados por los gigantes de inte et y también sirve para la coordinación de los núcleos múltiples de los procesadores mode os que contienen los ordenadores y dispositivos móviles. Lamport habló con Tom Simonite de MIT Technology Review sobre por qué sus ideas han perdurado.
¿Por qué es importante la computación distribuida?
La distribución no es algo que hagas limitándote a decir: "Vamos a distribuir las cosas". La cuestión es: "¿Cómo consigues que se comporten de forma coherente?"
Mi trabajo Byzantine Generals [sobre cómo hacer que el software tolere los errores, publicado en 1980] surgió porque fui a SRI y tenía un contrato para construir un prototipo de ordenador fiable para volar aviones para la NASA. Se usaban múltiples ordenadores que podían fallar, un sistema distribuido. Hoy hay ordenadores en Palo Alto [EEUU] y en Pekín [China] y otros lugares y queremos usarlos juntos, así que creamos sistemas distribuidos. Los ordenadores que cuentan con múltiples procesadores también son sistemas distribuidos.
Ya no usamos ordenadores como con los que trabajabas en las décadas de 1970 y 1980, ¿por qué han sobrevivido tus algoritmos de computación distribuida?
En algunos campos ha habido enormes cambios, pero el aspecto de lo que yo analizaba, las nociones fundamentales de la sincronización, siguen siendo las mismas.
Ejecutar procesos múltiples en un único ordenador es muy distinto a una serie de ordenadores distintos que se hacen con una red relativamente lenta, por ejemplo. Pero cuando intentas razonar matemáticamente sobre su corrección, no existe una diferencia fundamental entre los dos sistemas.
Desarrollé Paxos [en 1989] porque los de DEC [Digital Equipment Corporation] estaban construyendo un sistema de archivos distribuidos. El algoritmo Paxos ahora es de uso generalizado. Si miras dentro de Bing o Google o Amazon, donde tienen salas llenas de ordenadores, probablemente estén ejecutando alguna variación de Paxos.
Últimamente has trabajado en formas de mejorar la construcción del software. ¿Qué tiene de malo como se hace ahora?
La gente parece establecer una equivalencia entre programar y escribir código, y eso es un problema. Antes de escribir el código tienes que entender lo que estás haciendo. Si no escribes lo que haces, no sabes si lo entiendes y probablemente no lo entiendas si lo primero que escribes es el código. Si intentas construir un puente o una casa sin un plano, lo que nosotros conocemos como especificación, no será ni muy bonito ni muy fiable. Así se escribe la mayoría del código. Cada vez que echas pestes contra tu ordenador, estás echando pestes contra alguien que escribió un programa sin pensar en él antes.
Hay algo en la cultura del software que ha impedido el uso de la especificación. Tenemos una forma maravillosa, desarrollada a lo largo del último par de milenios, de describir las cosas con precisión y se llama matemática. Y creo que eso es lo que deberíamos estar usando como forma de pensar en lo que construimos.