Filosofia de engenharia: Thompson e Ritchie, faça uma coisa bem feita

Pontos principais

• Ferramentas pequenas e afiadas. Cada programa faz uma coisa bem feita e resiste à tentação de fazer uma segunda; necessidades novas ganham uma ferramenta nova, não mais uma flag.
• Composição acima de recursos. O poder vem de unir programas por uma interface de texto universal – os pipes – de modo que a capacidade surge nas junções, e não dentro de nenhum programa isolado. A frase canônica “faça uma coisa bem feita” é de Doug McIlroy, não de Thompson nem de Ritchie.
• Portabilidade pelo C. Reescrever o Unix em C permitiu levá-lo a novos equipamentos portando um compilador em vez de reescrever o sistema – a maior razão pela qual o Unix se espalhou por toda parte.
• Não confie em nada que você mesmo não construiu. O ensaio “Reflections on Trusting Trust”, de Thompson, mostra que um backdoor pode viver no binário sem deixar rastro algum em nenhum código-fonte que você inspecione – a percepção fundadora da segurança de cadeia de suprimentos.

O princípio

“Escreva programas que façam uma coisa e a façam bem. Escreva programas que trabalhem juntos. Escreva programas que lidem com fluxos de texto, porque essa é uma interface universal.” – Doug McIlroy, resumindo a filosofia Unix¹

Essa frase não é de Thompson nem de Ritchie. Foi escrita por Doug McIlroy, colega deles nos Bell Labs e o homem que inventou o pipe do Unix, no prefácio que escreveu para a edição especial de 1978 do Bell System Technical Journal.¹ Mas ela é a formulação mais limpa daquilo que Thompson e Ritchie de fato construíram, e a razão para abrir com ela, em vez de com uma frase de um dos dois, é ela mesma o ponto: a filosofia Unix nunca foi um manifesto assinado por um único gênio. Foi uma cultura – e a cultura era o artefato.

O princípio tem três movimentos, e eles são inseparáveis. Faça cada ferramenta pequena e afiada – um trabalho, bem feito, sem nenhuma ambição de fazer um segundo. Torne as ferramentas combináveis – a saída de uma é a entrada da seguinte, de modo que a capacidade vem da combinação, e não de um programa crescendo até virar um gigante. E faça a interface entre elas universal – texto puro, para que qualquer ferramenta possa se unir a qualquer outra sem que nenhuma das duas saiba que a outra existe. O poder mora nas junções, não nas partes. Um programa que ordena linhas não sabe nada sobre logs da web; um programa que conta duplicatas não sabe nada sobre códigos de status HTTP; unidos por um pipe, respondem a uma pergunta que nenhum deles foi feito para responder.

Isso é o oposto do instinto que produz a maior parte do software. A tendência natural é fazer um único programa fazer mais – acrescentar uma flag, acrescentar um modo, embutir o próximo requisito naquilo que você já tem. A primeira regra de McIlroy nomeia essa tendência e a recusa: “Para fazer um trabalho novo, construa do zero em vez de complicar programas antigos acrescentando novos ‘recursos’.”¹ O sistema inteiro de Thompson e Ritchie é a demonstração de que a simplicidade é a precondição para todo o resto, e de que a composição – não os recursos – é o caminho pelo qual coisas pequenas se tornam poderosas.

Contexto

O Unix nasceu de um fracasso. Ao longo de meados da década de 1960, os Bell Labs haviam se associado ao MIT e à General Electric no Multics, um sistema operacional de tempo compartilhado de ambição enorme, pensado para fazer quase tudo. Em 1969 ele havia ficado tão complexo e tão atrasado que os Bell Labs se retiraram, e os pesquisadores que haviam trabalhado nele – Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna – ficaram frustrados, com a perda de um ambiente de computação interativa confortável e uma noção forte de como não construir um sistema.²

Ken Thompson, nascido em 4 de fevereiro de 1943, em Nova Orleans, havia entrado nos Bell Labs em 1966, depois de um bacharelado e um mestrado em engenharia elétrica e ciência da computação na UC Berkeley.³ Dennis Ritchie, nascido em 9 de setembro de 1941, em Bronxville, Nova York, entrou no Computing Sciences Research Center em 1967.⁴ Em 1969, Thompson encontrou um PDP-7 descartado – um minicomputador pequeno e, àquela altura, obsoleto – e começou a construir um sistema operacional minúsculo nele, em parte para rodar um jogo que havia escrito, chamado Space Travel. Mais tarde, Thompson resumiu a divisão de trabalho sem rodeios: “Eu fiz a primeira de duas ou três versões do UNIX completamente sozinho. E o Dennis virou evangelista.”³ A primeira versão foi escrita em assembly do PDP-7.

O nome veio como piada. Onde o Multics era “multiplexado”, o novo sistema era deliberadamente pequeno, e por isso o grupo o chamou de “UNICS” – Uniplexed Information and Computing Service –, um trocadilho às custas do Multics. A grafia derivou para “Unix”, e Brian Kernighan, a quem o nome costuma ser atribuído, observou mais tarde que ninguém consegue lembrar direito como a forma final surgiu.² A pequenez não foi acidente nem uma limitação a ser superada. Era o projeto.

O trabalho

O Unix e o sistema de arquivos

A primeira coisa que o Unix acertou foi um modelo do que são os recursos de um computador. Sistemas anteriores tratavam arquivos, dispositivos e canais de comunicação como coisas de tipos diferentes, cada um com sua própria interface especial. O Unix as colapsou. Apresentou um único sistema de arquivos hierárquico – uma árvore de diretórios – e então tratou quase tudo como um arquivo dentro dela: não só documentos, mas também dispositivos e canais de comunicação entre processos.² Um programa que conseguisse ler de um arquivo e escrever nele conseguia, sem nenhuma alteração, ler de um terminal, de uma unidade de fita ou de outro programa, porque, para o programa, todos eram apenas arquivos.

Essa é a interface universal em sua primeira forma. “Tudo é um arquivo” significa que uma ferramenta pequena não precisa de uma versão diferente para cada tipo de entrada; precisa de uma só. O custo da composição cai a quase zero, porque cada componente já fala a mesma língua. O sistema de arquivos hierárquico e a interface uniforme de open/read/write/close são a razão de a parte restante da filosofia ter sido possível: você não consegue compor ferramentas que exigem, cada uma, um conector sob medida.

O C e a portabilidade

O segundo avanço foi tornar o sistema portável, e isso exigiu uma linguagem. Ritchie criou o C entre 1969 e 1973, fazendo-o evoluir a partir da linguagem B, de Thompson, que por sua vez descendia do BCPL.⁴ O B não tinha tipos e era interpretado; o C acrescentou tipos de dados e estruturas e compilava para código de máquina eficiente, próximo o bastante do hardware para escrever um sistema operacional, abstrato o bastante para circular entre máquinas.

O momento decisivo veio por volta de 1973, quando a Versão 4 do Unix foi reescrita em C.² Até então, um sistema operacional era linguagem assembly, soldado permanentemente à única máquina para a qual fora escrito. Reescrever o Unix em uma linguagem de alto nível beirava a heresia – a sabedoria convencional dizia que código de sistema tinha de ser assembly ajustado à mão, ou seria lento demais. Thompson e Ritchie fizeram isso assim mesmo, e a recompensa foi a portabilidade: o Unix agora podia ser levado a novos equipamentos portando um compilador, em vez de reescrever o sistema inteiro. Essa única decisão é a maior parte da razão pela qual o Unix se espalhou por todos os cantos da computação, enquanto seus contemporâneos seguiram parafusados ao ferro original. Em 1978, Ritchie e Kernighan publicaram The C Programming Language – o “K&R” –, o livro enxuto e exato que ensinou uma geração a escrever C e que continua sendo um modelo de prosa técnica.⁵ Thompson e Ritchie anunciaram o próprio sistema ao mundo mais amplo no artigo “The UNIX Time-Sharing System”, publicado na Communications of the ACM de julho de 1974.⁶

Os pipes e o modelo de composição

Se o sistema de arquivos fez as ferramentas falarem a mesma língua, os pipes as fizeram conversar entre si. A ideia era de Doug McIlroy: durante anos ele defendeu uma forma de conectar programas ponta a ponta, com a saída de um fluindo diretamente para o seguinte, como seções de uma mangueira de jardim. Thompson a implementou em 1973 – segundo a lenda, em uma única noite –, acrescentando a chamada de sistema pipe() e o operador | ao shell.⁷ McIlroy descreveu o que aconteceu em seguida: “O dia seguinte viu uma orgia inesquecível de one-liners, com todo mundo entrando na empolgação do encanamento.”⁷

Essa orgia de one-liners é a filosofia em ação. Ninguém precisou escrever um programa novo; eles descobriram que os pequenos programas que já tinham podiam ser amarrados uns aos outros para responder a perguntas para as quais nenhum deles fora projetado. Um pipeline como grep, depois cut, depois sort, depois uniq -c, depois sort -rn e, por fim, head é construído com seis estágios, cada um ignorando os demais, cada um fazendo uma coisa, compostos da esquerda para a direita por um fluxo de texto. A capacidade é emergente. Ela mora no |, não em nenhum comando isolado.

Essa é a ideia mais profunda de todo o sistema. A maior parte do software cresce por acúmulo: um programa absorve cada novo requisito até virar um monolito que só os próprios autores entendem. O Unix cresce por composição: o sistema continua sendo um kit de partes pequenas, e a capacidade nova vem de novos arranjos das partes antigas. O fluxo de texto é a interface universal que torna o arranjo gratuito. É por isso que um shell Unix, cinquenta anos depois, ainda é um dos ambientes de programação mais expressivos que existem – não apesar de ser feito de programas minúsculos e de propósito único, mas justamente por causa disso.

Trusting Trust e o legado posterior

Em 1983, Thompson e Ritchie dividiram o Prêmio Turing da ACM. A justificativa diz “pelo desenvolvimento de uma teoria genérica de sistemas operacionais e, especificamente, pela implementação do sistema operacional UNIX”, e a declaração do comitê nomeia o princípio com exatidão: “O sucesso do sistema UNIX decorre de sua seleção criteriosa de algumas poucas ideias-chave e de sua implementação elegante.”⁸ Seleção criteriosa de algumas poucas ideias-chave – o prêmio foi dado, na prática, pela contenção.

A própria conferência Turing de Thompson, publicada em 1984 como “Reflections on Trusting Trust”, voltou esse mesmo rigor minimalista para a segurança. Ele demonstrou que era possível ensinar um compilador a inserir um backdoor no programa login, e a inserir a própria inserção-de-backdoor em qualquer compilador futuro que ele compilasse – de modo que o código malicioso vivia apenas no binário, sem deixar rastro algum em nenhum fonte que você pudesse inspecionar. Sua conclusão é uma das frases mais citadas da computação: “Você não pode confiar em código que não criou inteiramente por conta própria… Nenhuma quantidade de verificação ou escrutínio em nível de fonte vai protegê-lo de usar código não confiável.”⁹ É o texto fundador do pensamento sobre segurança de cadeia de suprimentos – o reconhecimento de que aquilo em que você confia não é o fonte, mas toda a cadeia de ferramentas que produziu o binário.

As carreiras posteriores da dupla estenderam os mesmos instintos. Thompson seguiu inquieto: nos Bell Labs ele construiu o sistema operacional Plan 9 (levando o “tudo é um arquivo” ainda mais longe, através de uma rede), o editor ed e a teoria prática das expressões regulares e do grep. Em 1992, ele e Rob Pike projetaram o UTF-8 – a codificação de texto de largura variável que hoje carrega quase todo o texto do mundo – em uma única noite, segundo a lenda esboçada num descanso de mesa de restaurante.³ E em 2007, no Google, Thompson coprojetou a linguagem de programação Go com Robert Griesemer e Rob Pike, anunciada publicamente em 2009: uma linguagem deliberadamente pequena, de compilação rápida e combinável, que se lê como um retorno consciente aos valores do Unix.¹⁰ Ritchie, que morreu em 12 de outubro de 2011, deixou uma marca mais silenciosa, porém mais difundida; como disse o historiador Paul Ceruzzi, “se você tivesse um microscópio e pudesse olhar dentro de um computador, veria o trabalho dele por toda parte ali dentro.”⁴

O método

O método é consistente ao longo de quarenta anos e de dois homens que raramente precisaram explicá-lo.

Construa ferramentas pequenas e afiadas. Cada programa faz um trabalho. A disciplina está na recusa: quando aparece uma necessidade nova, a resposta é uma ferramenta nova, não uma flag nova parafusada numa antiga. “Construa do zero em vez de complicar programas antigos.”¹

Componha em vez de acumular. A capacidade deve emergir da combinação. Um sistema permanece compreensível quando é um kit de partes pequenas e cresce por rearranjo, não por uma parte qualquer inchar até virar um monolito.

Padronize a interface, não as ferramentas. O movimento unificador – “tudo é um arquivo”, fluxos de texto puro entre os programas – consiste em tornar a conexão universal para que os componentes possam continuar ignorando uns aos outros. Junções baratas são o que torna poderosas as partes pequenas.

Escolha algumas poucas ideias-chave, com critério. A expressão do comitê do Turing não foi elogio; foi o método. O Unix é famoso pelo que deixou de fora. Portabilidade via C, a abstração de arquivo, o pipe – um punhado de decisões, cada uma carregando um peso enorme, com o entulho deliberadamente ausente.

Desconfie do que você não pode inspecionar. “Trusting Trust” é o método voltado para dentro: simplicidade e legibilidade não são apenas virtudes estéticas, mas a única base real de confiança, porque a complexidade é onde as coisas que você não consegue ver podem se esconder.

Cadeia de influência

Quem os moldou

O Multics, por contraexemplo. A influência mais formadora de todas foi um sistema que eles ajudaram a construir e do qual depois se afastaram. O Multics ensinou a Thompson e Ritchie, da forma mais cara possível, o que custa a ambição em excesso – e o Unix é, em grande parte, uma reação disciplinada contra ele. (Influência formadora)

Doug McIlroy. Chefe do Computing Sciences Research Center, McIlroy inventou o pipe, articulou por escrito a filosofia do “faça uma coisa bem feita” e atuou como o implacável crítico de bom gosto do grupo. O modelo de composição é tão dele quanto de qualquer um, e ele é a atribuição correta da formulação canônica da filosofia. (Influência direta)

A cultura de pesquisa dos Bell Labs. Um pequeno grupo de pares, dotado de liberdade e de boas máquinas, otimizando para a elegância entre si, e não para um roteiro de produto. O Unix não foi especificado pela gerência; ele se sedimentou a partir de uma cultura que valorizava o que tinha bom gosto e ridicularizava o que era inchado. (Influência formadora)

Quem eles moldaram

Todo descendente do Unix. O Linux, os BSDs e o macOS são herdeiros diretos da linhagem; o sistema que Thompson e Ritchie escreveram num PDP-7 descartado hoje roda na maioria dos servidores, telefones e dispositivos embarcados da Terra.

Todo shell e linha de comando. O pipe e o modelo de composição são o ambiente de trabalho diário de praticamente todo programador e administrador de sistemas, cinquenta anos depois – inalterados em sua essência, porque a essência estava certa.

O C e seus filhos. O C virou a língua franca da programação de sistemas, e sua sintaxe e semântica ecoam em C++, Java, Go, Rust e em boa parte do que se escreve hoje. O K&R continua sendo o modelo de como documentar uma linguagem.

A própria filosofia Unix. O “faça uma coisa bem feita” extrapolou o Unix e se tornou um princípio de projeto geral – para microsserviços, para ferramentas de linha de comando, para a abordagem sem build, de pequenas peças, da web e para a maneira de manter sistemas de IA pequenos o bastante para permanecerem seguros e legíveis.

O fio condutor

Thompson e Ritchie são a expressão, em nível de sistemas, da mesma convicção que percorre esta série. Edsger Dijkstra defendia que a simplicidade é o pré-requisito da confiabilidade; o Unix é esse argumento compilado e entregue – um núcleo de algumas poucas ideias-chave, mantido pequeno o bastante para ser confiável. O “bom gosto” de Linus Torvalds, a reescrita em que o caso especial desaparece, é o “faça uma coisa bem feita” dentro de uma única função, em vez de ao longo de um pipeline; e Torvalds construiu o Linux e o Git diretamente sobre a base que esses dois assentaram. O núcleo rápido e simples de John Carmack é a mesma subtração, mirando o teto do hardware. E o projeto de Ruby por Yukihiro Matsumoto, em prol da felicidade humana, é o instinto Unix – peças pequenas, combináveis e expressivas – levado para o alto, até uma linguagem de alto nível. O fio condutor cabe em uma frase: o poder deve vir de compor partes pequenas e compreensíveis por meio de uma interface universal, não de uma parte qualquer crescendo até ficar grande. (Ponte da série)

O que eu levo disto

A lição que guardo é que a interface é a arquitetura. Quando projeto qualquer coisa hoje – um agente, um laço de ferramentas, um pipeline de scripts –, a tentação é sempre tornar um componente mais inteligente, embutir o próximo requisito naquilo que já tenho até que vire um monolito que só eu entendo. O movimento Unix é o oposto: mantenha cada peça pequena o bastante para entendê-la por inteiro e coloque a inteligência em como as peças se conectam. Uma junção limpa e universal entre partes burras ganha de uma parte esperta sem nenhuma junção limpa, sempre. É o mesmo padrão de a qualidade ser a única variável – a pergunta nunca é “este único programa consegue fazer mais?”, mas “este sistema ainda é feito de peças sobre as quais consigo raciocinar?”.

No mundo em que construo agora – agentes de IA ligados uns aos outros por ferramentas e texto –, o projeto de Thompson e Ritchie é mais relevante do que teria o direito de ser aos cinquenta e tantos anos de idade. Um agente é um programa pequeno; uma ferramenta é um programa pequeno; o que os torna poderosos é uma interface limpa e universal entre eles, que hoje é, em grande parte, texto estruturado. É o pipe, reconstruído. E “Trusting Trust” é o alerta que levo mais a sério: quando um sistema gera código mais rápido do que qualquer um consegue ler, a única base durável de confiança é manter as partes pequenas e as junções legíveis, porque a complexidade é exatamente onde as coisas que você não consegue ver vão se esconder. Essa convicção – a de que o bom gosto é um sistema técnico e a de que peças pequenas, combináveis e inspecionáveis não são um capricho, mas o jogo inteiro – corre em linha reta de um PDP-7 de 1969 até uma estrutura local de agentes de 2026.

Perguntas frequentes

O que é a filosofia Unix?

A filosofia Unix é uma abordagem de projeto construída sobre ferramentas pequenas e de propósito único que se compõem por uma interface universal. Sua formulação canônica, de Doug McIlroy em 1978, é: “Escreva programas que façam uma coisa e a façam bem. Escreva programas que trabalhem juntos. Escreva programas que lidem com fluxos de texto, porque essa é uma interface universal.” O primeiro princípio é construir uma ferramenta nova em vez de acrescentar recursos a uma já existente, e o poder do sistema vem de combinar partes pequenas – via pipes e texto puro – e não de um único programa crescendo até ficar grande.¹

Ken Thompson disse “faça uma coisa bem feita”?

Não. A máxima “faça uma coisa bem feita” e a filosofia Unix mais ampla foram articuladas por escrito por Doug McIlroy, chefe do Computing Sciences Research Center dos Bell Labs, no prefácio que escreveu para a edição especial sobre Unix do Bell System Technical Journal de 1978.¹ Thompson e Ritchie construíram o sistema que encarna a filosofia, e McIlroy – que também inventou o pipe do Unix – foi seu articulador mais claro e o crítico de bom gosto residente do grupo. Atribuir a máxima a Thompson é um atalho comum, mas incorreto.

O que Thompson e Ritchie de fato criaram?

Ken Thompson construiu as primeiras versões do sistema operacional Unix em um PDP-7 a partir de 1969, e mais tarde criou a linguagem B, o editor ed, a busca prática por expressões regulares (grep), o sistema Plan 9, o UTF-8 (com Rob Pike) e coprojetou o Go no Google.³ Dennis Ritchie criou a linguagem de programação C (1969–1973), usou-a para reescrever o Unix em 1973 e torná-lo portável, e foi coautor de The C Programming Language com Brian Kernighan em 1978.⁴⁵ Eles dividiram o Prêmio Turing da ACM de 1983 pelo Unix.⁸

O que é “Reflections on Trusting Trust”?

É a conferência do Prêmio Turing da ACM de Ken Thompson, de 1984, publicada na Communications of the ACM. Ele mostrou que era possível fazer um compilador inserir um backdoor escondido em um programa e reproduzir esse backdoor sempre que compilasse uma nova versão de si mesmo – de modo que o código malicioso existia apenas no binário e não deixava rastro algum em nenhum fonte que você pudesse ler. Sua conclusão: “Você não pode confiar em código que não criou inteiramente por conta própria… Nenhuma quantidade de verificação ou escrutínio em nível de fonte vai protegê-lo de usar código não confiável.” É um texto fundador da segurança de cadeia de suprimentos de software.⁹

Fontes