07.10.2026 · Signal Titans Editorial

Douglas McIlroy queria que programas conversassem. Os pipes do Unix tornaram isso prático.

Grande retrato de Douglas McIlroy em painel escuro à esquerda, com símbolo pipe, título e pipeline de comandos à direita.

Uma das ideias mais poderosas do Unix cabe em um único caractere: |. Um pipe faz a saída de um programa se tornar a entrada de outro, permitindo combinar pequenas ferramentas em workflows que seus autores nunca planejaram explicitamente. A ideia está fortemente associada a M. Douglas McIlroy, que liderava o departamento de pesquisa da Bell Labs onde Unix nasceu e insistiu durante anos que programas deveriam se comunicar por streams.

O problema não era a falta de programas poderosos

Sistemas antigos frequentemente reuniam muitas funções relacionadas em programas grandes. Para ordenar dados, transformar texto, contar registros ou formatar uma saída, era comum usar diferentes modos de uma aplicação monolítica. McIlroy preferia outro caminho: construir programas pequenos com responsabilidades claras e facilitar sua conexão. Seu resumo posterior da filosofia Unix tornou-se famoso: programas devem fazer uma coisa bem, trabalhar juntos e manipular streams de texto como uma interface universal.

Esse princípio era filosófico e prático. Computadores antigos tinham limitações severas de memória, então programas pequenos eram mais fáceis de construir e fazer caber na máquina. Mas, depois que o padrão mostrou seu valor, Unix o preservou mesmo com hardware mais poderoso. Surgiu assim uma cultura em que composição virou uma feature, e não um detalhe posterior.

McIlroy continuou pedindo um jeito de conectar processos

Antes da existência de pipes em Unix, McIlroy já se interessava por stream processing e por formas de fazer programas passarem dados diretamente entre si. Na Bell Labs, ele defendeu repetidamente um mecanismo que permitisse a um processo alimentar outro sem exigir arquivos temporários entre cada etapa. Ken Thompson acabou implementando pipes em Unix, transformando a ideia em um recurso simples do sistema operacional disponível no shell.

A mudança conceitual era maior do que o símbolo. Com pipes, o shell virou um lugar onde usuários podiam criar novos comportamentos encadeando comandos existentes. Uma ferramenta não precisava saber quem produzia sua entrada nem para onde sua saída iria. Bastava seguir uma convenção comum. Esse acoplamento fraco explica por que utilitários simples como grep, sort, uniq, tr e wc podem ser recombinados de tantas maneiras.

O pipe transformou uma interface estreita em grande alavancagem

A contribuição de McIlroy lembra que arquitetura de software muitas vezes depende das fronteiras entre componentes, e não apenas dos componentes em si. O pipe funciona porque comandos concordam com uma interface simples: um fluxo de bytes, muitas vezes interpretado como texto. A interface é estreita, e justamente por isso é tão reutilizável.

Esse padrão aparece em todo lugar hoje. Data pipelines conectam estágios independentes. Serviços web conversam por APIs. Sistemas de build passam artefatos de uma ferramenta para outra. Arquiteturas orientadas a eventos deixam produtores e consumidores evoluírem separadamente. Containers e ferramentas de linha de comando continuam sendo combinados pelo mesmo modelo de streams do Unix.

O trabalho de McIlroy foi muito além de um único operador

Sua biografia em Dartmouth lista trabalhos com macro processors, linguagens de programação, expressões regulares, alocação de memória, segurança, gráficos, projeções cartográficas, documentação e muitos utilitários Unix. Ele liderou um departamento da Bell Labs que incluía vários criadores centrais do Unix e também contribuiu com ferramentas e ideias próprias. Sua carreira mostra uma forma de influência técnica fácil de subestimar: criar ambientes em que outras pessoas conseguem inventar.

McIlroy também valorizava clareza. A tradição Unix que cresceu na Bell Labs favorecia manuais curtos, ferramentas reutilizáveis e interfaces que pudessem ser compreendidas localmente. Ele explicou depois que a regra de “fazer uma coisa” surgiu em parte das limitações de recursos, mas sobreviveu porque gerava programas fáceis de compor.

Um conector minúsculo mudou a maneira como software pode crescer

O pipe não tornou cada comando individual mais inteligente. Tornou mais útil a relação entre comandos. Essa diferença continua importante. Sistemas complexos costumam evoluir melhor quando inteligência é distribuída entre componentes pequenos com interfaces estáveis, em vez de concentrada em um programa enorme.

Toda vez que um desenvolvedor digita cat log | grep error | sort | uniq -c, está usando uma ideia de design de uma era muito anterior da computação. Hardware, escala e software ao redor mudaram completamente. O princípio, porém, continua surpreendentemente moderno: construir peças pequenas que consigam se conectar e deixar a composição gerar a complexidade.