07.10.2026 · Signal Titans Editorial

Douglas McIlroy quería que los programas hablaran entre sí. Los pipes de Unix lo hicieron práctico.

Gran retrato de Douglas McIlroy sobre panel oscuro a la izquierda, con símbolo pipe, titular y pipeline de comandos a la derecha.

Una de las ideas más poderosas de Unix se escribe con un solo carácter: |. Un pipe permite que la salida de un programa se convierta en la entrada de otro, de modo que herramientas pequeñas puedan combinarse en flujos de trabajo que sus autores nunca diseñaron explícitamente. La idea está estrechamente asociada con M. Douglas McIlroy, quien dirigió el departamento de investigación de Bell Labs donde nació Unix y defendió durante años que los programas pudieran comunicarse mediante flujos de datos.

El problema no era la falta de programas potentes

Muchos sistemas tempranos reunían funciones relacionadas dentro de grandes programas. Para ordenar datos, transformar texto, contar registros o formatear una salida, era común utilizar distintos modos de una misma utilidad monolítica. McIlroy prefería otra dirección: construir programas pequeños con tareas claras y facilitar su conexión. Su resumen posterior de la filosofía Unix se haría célebre: programas que hagan una cosa bien, que puedan trabajar juntos y que manejen flujos de texto como una interfaz universal.

La idea era filosófica, pero también muy práctica. Los primeros computadores tenían fuertes restricciones de memoria, de manera que los programas pequeños eran más fáciles de escribir y de hacer caber en la máquina. Sin embargo, cuando el patrón demostró su utilidad, Unix lo mantuvo incluso cuando mejoró el hardware. Así nació una cultura en la que la composición pasó a ser una característica fundamental.

McIlroy insistió en conectar procesos directamente

Antes de que Unix tuviera pipes, McIlroy ya estaba interesado en stream processing y en mecanismos que permitieran a los programas enviarse datos sin depender de archivos temporales. En Bell Labs defendió repetidamente un mecanismo por el que un proceso pudiera alimentar a otro. Ken Thompson terminó implementando los pipes en Unix, convirtiendo la idea en una función sencilla del sistema operativo que podía usarse desde el shell.

El cambio conceptual fue mayor que el símbolo. Con pipes, el shell se convirtió en un lugar donde los usuarios podían construir comportamientos nuevos encadenando comandos existentes. Una herramienta no necesitaba saber quién generaba su entrada ni a dónde iría su salida. Solo tenía que respetar una convención común. Ese acoplamiento débil explica por qué utilidades simples como grep, sort, uniq, tr o wc pueden recombinarse de tantas maneras.

El pipe convirtió una interfaz pequeña en una enorme ventaja

La contribución de McIlroy recuerda que la arquitectura de software depende muchas veces de las fronteras entre componentes, no únicamente de los componentes mismos. El pipe funciona porque los comandos aceptan una interfaz sencilla: un flujo de bytes, frecuentemente interpretado como texto. Es una interfaz estrecha, y precisamente esa limitación es lo que la hace reutilizable.

El mismo enfoque aparece hoy por todas partes. Los data pipelines conectan etapas independientes. Los servicios web se comunican mediante API. Los sistemas de build pasan artefactos de una herramienta a otra. Las arquitecturas basadas en eventos permiten que productores y consumidores evolucionen por separado. Incluso contenedores y herramientas de línea de comandos siguen aprovechando el modelo de streams de Unix.

La carrera de McIlroy fue mucho más amplia que un solo operador

Su biografía en Dartmouth enumera trabajos sobre macro processors, lenguajes de programación, expresiones regulares, gestión de memoria, seguridad, gráficos, proyecciones cartográficas, documentación y numerosas utilidades Unix. Dirigió un departamento de Bell Labs en el que trabajaban varios de los principales creadores de Unix y, al mismo tiempo, contribuyó con herramientas e ideas propias. Su carrera muestra una forma de influencia técnica que suele pasar desapercibida: diseñar entornos en los que otras personas pueden crear.

También valoraba enormemente la claridad. La tradición Unix que surgió en Bell Labs favorecía manuales breves, herramientas reutilizables e interfaces que pudieran comprenderse localmente. McIlroy explicó más tarde que la regla de “hacer una cosa” nació en parte de las restricciones de recursos, pero sobrevivió porque producía programas fáciles de componer.

Un conector diminuto cambió la forma de hacer crecer el software

El pipe no volvió más inteligentes a los comandos individuales. Volvió más útil la relación entre ellos. Esa diferencia sigue siendo importante. Los sistemas complejos suelen evolucionar mejor cuando la inteligencia se distribuye entre componentes pequeños con interfaces estables, en lugar de concentrarse en un programa enorme.

Cada vez que un desarrollador escribe algo como cat log | grep error | sort | uniq -c, está usando una idea de diseño nacida en una etapa mucho más temprana de la informática. El hardware cambió, la escala cambió y el software alrededor es muchísimo más sofisticado. Pero el principio sigue siendo sorprendentemente moderno: construir piezas pequeñas que puedan conectarse y dejar que la composición genere la complejidad.