Filosofía de la ingeniería: Thompson y Ritchie, haz una sola cosa bien

Ideas clave

• Herramientas pequeñas y afiladas. Cada programa hace una sola cosa bien y se resiste a hacer una segunda; las nuevas necesidades reciben una herramienta nueva, no otra opción más.
• Composición por encima de las funciones. El poder nace de unir programas a través de la interfaz universal de texto —los pipes—, de modo que la capacidad emerge en las uniones, no dentro de ningún programa en particular. La frase canónica «haz una sola cosa bien» es de Doug McIlroy, no de Thompson ni de Ritchie.
• Portabilidad gracias a C. Reescribir Unix en C permitió llevarlo a hardware nuevo portando un compilador en lugar de reescribir el sistema entero: la razón principal de que Unix se extendiera a todas partes.
• No confíes en nada que no hayas construido. «Reflections on Trusting Trust», de Thompson, muestra que una puerta trasera puede vivir en el binario sin dejar rastro en ningún código fuente que inspecciones: la intuición fundacional de la seguridad de la cadena de suministro.

El principio

«Escribe programas que hagan una sola cosa y la hagan bien. Escribe programas que trabajen juntos. Escribe programas que manejen flujos de texto, porque esa es una interfaz universal.» — Doug McIlroy, resumiendo la filosofía de Unix¹

Esa frase no es de Thompson ni de Ritchie. La escribió Doug McIlroy, su colega en los Bell Labs y el hombre que inventó el pipe de Unix, en su prólogo al número especial de 1978 del Bell System Technical Journal.¹ Pero es la formulación más limpia de aquello que Thompson y Ritchie construyeron de verdad, y la razón para abrir con ella en lugar de con una línea de cualquiera de los dos es, en sí misma, la idea central: la filosofía de Unix nunca fue un manifiesto escrito por un único genio. Fue una cultura, y la cultura era el artefacto.

El principio tiene tres movimientos, y son inseparables. Haz cada herramienta pequeña y afilada —un solo trabajo, bien hecho, sin ambición de hacer un segundo—. Haz que las herramientas se puedan componer —la salida de una es la entrada de la siguiente—, de modo que la capacidad venga de la combinación y no de que un programa crezca sin límite. Y haz que la interfaz entre ellas sea universal —texto plano—, para que cualquier herramienta pueda unirse a cualquier otra sin que ninguna sepa que la otra existe. El poder vive en las uniones, no en las piezas. Un programa que ordena líneas no sabe nada de registros web; un programa que cuenta duplicados no sabe nada de códigos de estado HTTP; unidos por un pipe, responden una pregunta que ninguno fue construido para responder.

Esto es lo contrario del instinto que produce la mayoría del software. La inclinación natural es hacer que un programa haga más —añadir una opción, añadir un modo, plegar el siguiente requisito dentro de lo que ya tienes—. La primera regla de McIlroy nombra esa inclinación y la rechaza: «Para hacer un trabajo nuevo, construye desde cero en lugar de complicar programas viejos añadiendo nuevas “funciones”.»¹ El sistema entero de Thompson y Ritchie es la demostración de que la simplicidad es la condición previa de todo lo demás, y de que la composición —no las funciones— es como las cosas pequeñas se vuelven poderosas.

Contexto

Unix nació de un fracaso. A lo largo de mediados de la década de 1960, los Bell Labs se habían asociado con el MIT y General Electric en Multics, un sistema operativo de tiempo compartido enormemente ambicioso, pensado para hacer casi todo. Hacia 1969 se había vuelto tan complejo y se había retrasado tanto que los Bell Labs se retiraron, y los investigadores que habían trabajado en él —Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna— quedaron frustrados, con la pérdida de un entorno de computación interactiva cómodo y una idea muy clara de cómo no construir un sistema.²

Ken Thompson, nacido el 4 de febrero de 1943 en Nueva Orleans, se había incorporado a los Bell Labs en 1966 tras una licenciatura y una maestría en ingeniería eléctrica y ciencias de la computación en UC Berkeley.³ Dennis Ritchie, nacido el 9 de septiembre de 1941 en Bronxville, Nueva York, se unió al Computing Sciences Research Center en 1967.⁴ En 1969 Thompson encontró un PDP-7 descartado —una minicomputadora pequeña y para entonces ya obsoleta— y empezó a construir en ella un sistema operativo diminuto, en parte para poder ejecutar un juego que había escrito llamado Space Travel. Thompson explicó después el reparto del trabajo sin rodeos: «Hice la primera de dos o tres versiones de UNIX completamente solo. Y Dennis se convirtió en el evangelista.»³ La primera versión se escribió en ensamblador del PDP-7.

El nombre surgió como una broma. Donde Multics era «Multiplexed», el nuevo sistema era deliberadamente pequeño, así que el grupo lo llamó «UNICS» —Uniplexed Information and Computing Service—, un juego de palabras a costa de Multics. La grafía derivó hacia «Unix», y Brian Kernighan, a quien suele atribuirse el nombre, comentó después que nadie recuerda del todo cómo surgió la forma final.² La pequeñez no fue un accidente ni una limitación que hubiera que superar. Era el diseño.

El trabajo

Unix y el sistema de archivos

Lo primero que Unix acertó fue un modelo de lo que son los recursos de una computadora. Los sistemas anteriores trataban los archivos, los dispositivos y los canales de comunicación como cosas distintas, cada una con su propia interfaz especial. Unix las unificó. Presentó un único sistema de archivos jerárquico —un árbol de directorios— y luego trató casi todo como un archivo dentro de él: no solo los documentos, sino también los dispositivos y los canales de comunicación entre procesos.² Un programa capaz de leer y escribir en un archivo podía, sin cambiar nada, leer de un terminal, de una unidad de cinta o de otro programa, porque para el programa todos eran simplemente archivos.

Esta es la interfaz universal en su primera forma. «Todo es un archivo» significa que una herramienta pequeña no necesita una versión distinta para cada tipo de entrada; necesita una sola. El costo de componer cae casi a cero, porque cada componente ya habla el mismo idioma. El sistema de archivos jerárquico y la interfaz uniforme open/read/write/close son la razón de que el resto de la filosofía fuera siquiera posible: no puedes componer herramientas que exijan, cada una, un conector hecho a medida.

C y la portabilidad

El segundo gran avance fue hacer el sistema portable, y eso exigía un lenguaje. Ritchie creó C entre 1969 y 1973, haciéndolo evolucionar a partir del lenguaje B de Thompson, que a su vez descendía de BCPL.⁴ B no tenía tipos y era interpretado; C añadió tipos de datos y estructuras y compilaba a código máquina eficiente, lo bastante cercano al hardware como para escribir un sistema operativo, lo bastante abstracto como para moverse entre máquinas.

El momento decisivo llegó alrededor de 1973, cuando la versión 4 de Unix se reescribió en C.² Hasta entonces, un sistema operativo era lenguaje ensamblador, soldado para siempre a la única máquina para la que se había escrito. Reescribir Unix en un lenguaje de alto nivel rozaba la herejía: la sabiduría convencional decía que el código de sistema tenía que ser ensamblador afinado a mano o sería demasiado lento. Thompson y Ritchie lo hicieron de todos modos, y la recompensa fue la portabilidad: ahora Unix podía llevarse a hardware nuevo portando un compilador en lugar de reescribir el sistema entero. Esa única decisión explica la mayor parte de por qué Unix se extendió a cada rincón de la computación mientras sus contemporáneos seguían atornillados a su hierro original. En 1978, Ritchie y Kernighan publicaron The C Programming Language —«K&R»—, el libro escueto y exacto que enseñó a una generación a escribir C y que sigue siendo un modelo de prosa técnica.⁵ Thompson y Ritchie presentaron el sistema en sí al mundo más amplio en el artículo «The UNIX Time-Sharing System», en el Communications of the ACM de julio de 1974.⁶

Los pipes y el modelo de composición

Si el sistema de archivos hizo que las herramientas hablaran el mismo idioma, los pipes las hicieron hablar entre sí. La idea era de Doug McIlroy: durante años había insistido en una forma de conectar programas de extremo a extremo, la salida de uno fluyendo directamente hacia el siguiente, como tramos de manguera de jardín. Thompson lo implementó en 1973 —célebremente en una sola noche—, añadiendo la llamada al sistema pipe() y el operador | al shell.⁷ McIlroy describió lo que ocurrió después: «Al día siguiente se vivió una orgía inolvidable de one-liners, mientras todos se sumaban a la emoción de hacer fontanería.»⁷

Esa orgía de one-liners es la filosofía en acción. Nadie tuvo que escribir un programa nuevo; descubrieron que los pequeños programas que ya tenían podían encadenarse para responder preguntas que ninguno había sido diseñado para responder. Una tubería como grep, luego cut, luego sort, luego uniq -c, luego sort -rn y luego head se construye a partir de seis etapas, cada una ignorante de las demás, cada una haciendo una sola cosa, compuestas de izquierda a derecha a través de un flujo de texto. La capacidad es emergente. Vive en el |, no en ningún comando individual.

Esta es la idea más profunda de todo el sistema. La mayor parte del software crece por acumulación: un programa absorbe cada nuevo requisito hasta volverse un monolito que solo sus autores comprenden. Unix crece por composición: el sistema sigue siendo un kit de piezas pequeñas, y la nueva capacidad viene de nuevas combinaciones de piezas viejas. El flujo de texto es la interfaz universal que vuelve gratuita la combinación. Es la razón de que un shell de Unix, cincuenta años después, siga siendo uno de los entornos de programación más expresivos que existen: no a pesar de estar hecho de diminutos programas de un solo propósito, sino gracias a ello.

«Trusting Trust» y el legado posterior

En 1983, Thompson y Ritchie compartieron el Premio Turing de la ACM. La mención dice «por su desarrollo de la teoría general de sistemas operativos y, en concreto, por la implementación del sistema operativo UNIX», y la declaración del comité nombra el principio con exactitud: «El éxito del sistema UNIX nace de su selección llena de buen gusto de unas pocas ideas clave y de su elegante implementación.»⁸ Una selección llena de buen gusto de unas pocas ideas clave — el premio se entregó, en efecto, por la contención.

La propia conferencia Turing de Thompson, publicada en 1984 como «Reflections on Trusting Trust», dirigió ese mismo rigor minimalista hacia la seguridad. Demostró que a un compilador se le podía enseñar a insertar una puerta trasera en el programa login, y a insertar esa inserción de la puerta trasera en cualquier compilador futuro que él mismo compilara, de modo que el código malicioso vivía únicamente en el binario, sin dejar rastro alguno en ningún código fuente que pudieras inspeccionar. Su conclusión es una de las frases más citadas de la computación: «No puedes confiar en código que no hayas creado totalmente tú mismo… Ninguna cantidad de verificación o escrutinio a nivel de código fuente te protegerá de usar código en el que no confías.»⁹ Es el texto fundacional del pensamiento sobre seguridad de la cadena de suministro: el reconocimiento de que aquello en lo que confías no es el código fuente, sino toda la cadena de herramientas que produjo el binario.

Las carreras posteriores de ambos prolongaron los mismos instintos. Thompson siguió inquieto: en los Bell Labs construyó el sistema operativo Plan 9 (llevando «todo es un archivo» aún más lejos, a través de una red), el editor ed y la teoría práctica de las expresiones regulares y grep. En 1992, él y Rob Pike diseñaron UTF-8 —la codificación de texto de ancho variable que hoy transporta casi todo el texto del mundo— en una sola tarde, célebremente esbozada en un individual de mesa.³ Y en 2007, en Google, Thompson codiseñó el lenguaje de programación Go junto a Robert Griesemer y Rob Pike, anunciado públicamente en 2009: un lenguaje deliberadamente pequeño, de compilación rápida y componible, que se lee como un regreso consciente a los valores de Unix.¹⁰ Ritchie, que murió el 12 de octubre de 2011, dejó una huella más callada pero más penetrante; como dijo el historiador Paul Ceruzzi: «si tuvieras un microscopio y pudieras mirar dentro de una computadora, verías su trabajo por todas partes ahí dentro.»⁴

El método

El método es coherente a lo largo de cuarenta años y de dos hombres que rara vez necesitaron explicarlo.

Construye herramientas pequeñas y afiladas. Cada programa hace un solo trabajo. La disciplina es la negativa: cuando aparece una nueva necesidad, la respuesta es una herramienta nueva, no una opción nueva atornillada a una vieja. «Construye desde cero en lugar de complicar programas viejos.»¹

Compón en lugar de acumular. La capacidad debe emerger de la combinación. Un sistema sigue siendo comprensible cuando es un kit de piezas pequeñas y crece por recombinación, no porque alguna pieza se hinche hasta volverse un monolito.

Estandariza la interfaz, no las herramientas. El movimiento unificador —«todo es un archivo», flujos de texto plano entre programas— consiste en hacer universal la conexión para que los componentes puedan permanecer ignorantes unos de otros. Las uniones baratas son lo que vuelve poderosas a las piezas pequeñas.

Elige unas pocas ideas clave, con buen gusto. La frase del comité del Turing no era halago; era el método. Unix es famoso por lo que dejó fuera. La portabilidad vía C, la abstracción de archivo, el pipe: un puñado de decisiones, cada una con un peso enorme, con el desorden deliberadamente ausente.

Desconfía de lo que no puedes inspeccionar. «Trusting Trust» es el método dirigido hacia adentro: la simplicidad y la legibilidad no son solo virtudes estéticas, sino la única base real para la confianza, porque la complejidad es donde pueden esconderse las cosas que no puedes ver.

Cadena de influencia

Quiénes los formaron

Multics, por contraejemplo. La influencia más formativa de todas fue un sistema que ayudaron a construir y del que luego se alejaron. Multics enseñó a Thompson y Ritchie, de la manera más cara posible, lo que cuesta la ambición desmedida, y Unix es en gran parte una reacción disciplinada contra él. (Influencia formativa)

Doug McIlroy. Director del Computing Sciences Research Center, McIlroy inventó el pipe, articuló por escrito la filosofía de «haz una sola cosa bien» y ejerció como el crítico de gusto incansable del grupo. El modelo de composición es tan suyo como de cualquiera, y es la atribución correcta de la frase canónica de la filosofía. (Influencia directa)

La cultura de investigación de los Bell Labs. Un pequeño grupo de pares, con libertad y buenas máquinas, optimizando para la elegancia entre ellos mismos antes que para una hoja de ruta de producto. Unix no fue especificado por la gerencia; se fue acumulando a partir de una cultura que valoraba lo de buen gusto y ridiculizaba lo recargado. (Influencia formativa)

A quiénes formaron

Cada descendiente de Unix. Linux, los BSD y macOS son herederos directos en línea recta; el sistema que Thompson y Ritchie escribieron en un PDP-7 descartado hoy hace funcionar la mayoría de los servidores, teléfonos y dispositivos embebidos de la Tierra.

Cada shell y cada línea de comandos. El pipe y el modelo de composición son el entorno de trabajo diario de prácticamente todos los programadores y administradores de sistemas, cincuenta años después, inalterados en lo esencial porque lo esencial estaba bien.

C y sus hijos. C se convirtió en la lingua franca de la programación de sistemas, y su sintaxis y su semántica resuenan en C++, Java, Go, Rust y en casi todo lo que se escribe hoy. K&R sigue siendo la plantilla de cómo documentar un lenguaje.

La propia filosofía de Unix. «Haz una sola cosa bien» superó a Unix hasta convertirse en un principio general de diseño: para los microservicios, para las herramientas de línea de comandos, para el enfoque sin compilación y de piezas pequeñas de la web y para cómo mantener los sistemas de IA lo bastante pequeños como para seguir siendo seguros y legibles.

El hilo conductor

Thompson y Ritchie son la expresión a nivel de sistemas de la misma convicción que recorre esta serie. Edsger Dijkstra sostuvo que la simplicidad es el requisito previo de la fiabilidad; Unix es ese argumento compilado y entregado: un núcleo de unas pocas ideas clave, mantenido lo bastante pequeño como para confiar en él. El «buen gusto» de Linus Torvalds, la reescritura donde el caso especial desaparece, es «haz una sola cosa bien» dentro de una sola función en vez de a lo largo de una tubería; y Torvalds construyó Linux y Git directamente sobre los cimientos que estos dos pusieron. El núcleo rápido y simple de John Carmack es la misma sustracción, apuntada al techo del hardware. Y el diseño de Ruby para la felicidad humana de Yukihiro Matsumoto es el instinto de Unix —piezas pequeñas, componibles y expresivas— llevado hasta un lenguaje de alto nivel. El hilo conductor es una sola frase: el poder debe venir de componer piezas pequeñas y comprensibles a través de una interfaz universal, no de que ninguna pieza crezca sin límite. (Puente de la serie)

Lo que me llevo de esto

La lección que conservo es que la interfaz es la arquitectura. Cuando diseño cualquier cosa ahora —un agente, un bucle de herramientas, una tubería de scripts—, la tentación es siempre hacer un componente más inteligente, plegar el siguiente requisito dentro de lo que ya tengo hasta que se vuelva un monolito que solo yo comprendo. El movimiento de Unix es el opuesto: mantén cada pieza lo bastante pequeña como para entenderla por completo, y pon la inteligencia en cómo se conectan las piezas. Una unión limpia y universal entre piezas tontas le gana a una pieza ingeniosa sin uniones limpias, siempre. Ese es el mismo estándar que la calidad como única variable: la pregunta nunca es «¿puede este programa hacer más?», sino «¿sigue estando este sistema hecho de piezas sobre las que puedo razonar?».

En el mundo en el que construyo ahora —agentes de IA conectados entre sí con herramientas y texto—, el diseño de Thompson y Ritchie es más relevante de lo que tendría derecho a ser con sus cincuenta y tantos años. Un agente es un programa pequeño; una herramienta es un programa pequeño; lo que los vuelve poderosos es una interfaz limpia y universal entre ellos, que hoy es sobre todo texto estructurado. Ese es el pipe, reconstruido. Y «Trusting Trust» es la advertencia que más en serio me tomo: cuando un sistema genera código más rápido de lo que cualquiera puede leerlo, la única base duradera para la confianza es mantener las piezas pequeñas y las uniones legibles, porque la complejidad es exactamente donde van a esconderse las cosas que no puedes ver. Esa convicción —que el buen gusto es un sistema técnico y que las piezas pequeñas, componibles e inspeccionables no son un lujo, sino el juego entero— corre en línea recta desde un PDP-7 de 1969 hasta una capa local de agentes de 2026.

Preguntas frecuentes

¿Qué es la filosofía de Unix?

La filosofía de Unix es un enfoque de diseño construido sobre herramientas pequeñas y de un solo propósito que se componen a través de una interfaz universal. Su formulación canónica, de Doug McIlroy en 1978, es: «Escribe programas que hagan una sola cosa y la hagan bien. Escribe programas que trabajen juntos. Escribe programas que manejen flujos de texto, porque esa es una interfaz universal.» El primer principio es construir una herramienta nueva en lugar de añadir funciones a una existente, y el poder del sistema viene de combinar piezas pequeñas —mediante pipes y texto plano— y no de que un solo programa crezca sin límite.¹

¿Dijo Ken Thompson «haz una sola cosa bien»?

No. La máxima «haz una sola cosa bien» y la filosofía de Unix más amplia fueron articuladas por escrito por Doug McIlroy, director del Computing Sciences Research Center de los Bell Labs, en su prólogo al número especial sobre Unix del Bell System Technical Journal de 1978.¹ Thompson y Ritchie construyeron el sistema que encarna la filosofía, y McIlroy —que además inventó el pipe de Unix— fue su articulador más claro y el crítico de gusto residente del grupo. Atribuir la máxima a Thompson es un atajo común, pero incorrecto.

¿Qué crearon realmente Thompson y Ritchie?

Ken Thompson construyó las primeras versiones del sistema operativo Unix en un PDP-7 a partir de 1969, y más tarde creó el lenguaje B, el editor ed, la búsqueda práctica con expresiones regulares (grep), el sistema Plan 9, UTF-8 (con Rob Pike) y codiseñó Go en Google.³ Dennis Ritchie creó el lenguaje de programación C (1969-1973), lo usó para reescribir Unix en 1973 y hacerlo portable, y coescribió The C Programming Language con Brian Kernighan en 1978.⁴⁵ Compartieron el Premio Turing de la ACM de 1983 por Unix.⁸

¿Qué es «Reflections on Trusting Trust»?

Es la conferencia del Premio Turing de la ACM de Ken Thompson en 1984, publicada en Communications of the ACM. Mostró que a un compilador se le podía hacer insertar una puerta trasera oculta en un programa, y reproducir esa puerta trasera cada vez que compilara una nueva versión de sí mismo, de modo que el código malicioso existía únicamente en el binario y no dejaba rastro en ningún código fuente que pudieras leer. Su conclusión: «No puedes confiar en código que no hayas creado totalmente tú mismo… Ninguna cantidad de verificación o escrutinio a nivel de código fuente te protegerá de usar código en el que no confías.» Es un texto fundacional de la seguridad de la cadena de suministro de software.⁹

Fuentes