Simples não é pequeno: o que define simplicidade em código

A tese: pequeno não é simples

A autora, programadora, parte de uma experiência concreta: após dar uma palestra sobre um bug que levou nove meses para ser depurado em sua empresa, respondeu à pergunta de um amigo, Predrag, sobre como construir ferramentas que evitem essas histórias épicas de depuração com "precisamos priorizar a simplicidade" - mas não ficou satisfeita com a resposta e decide investigar o que simplicidade realmente significa.

O argumento central é que "simples" e "pequeno" são qualidades diferentes. Usando a definição de Rich Hickey em "Simple Made Easy", "simples" deriva de "sim-plex" (uma só trança), enquanto "complexo" significa coisas trançadas juntas - a autora usa "acoplado" como sinônimo de complexo.

Unix pipelines: pequenos, mas acoplados

O exemplo central compara duas formas de contar frequência de palavras em um arquivo: um pipeline Unix (cat | tr | sort | uniq | sort) e um programa em Clojure. O pipeline parece simples - pequeno, conciso, legível. Mas ao pedir uma mudança (exibir a saída na ordem original do arquivo), o Clojure permite uma solução direta (guardar a sequência de palavras e um mapa de frequências, iterar e consultar), enquanto o Bash exige arquivos temporários, expressões regulares opacas, ordenações e junções.

O motivo: o pipeline original era pequeno, mas não simples. O trecho sort | uniq --count acopla agregação à ordenação - a página de manual do uniq avisa que linhas repetidas só são detectadas se adjacentes, exigindo ordenação prévia. Isso torna a solução menos eficiente (coleta toda a entrada em memória) e dificulta separar ordenação de agregação. Para a autora, o lema da Filosofia Unix, "escreva programas que fazem uma coisa e a fazem bem", é na prática sobre tamanho, não simplicidade: ferramentas Unix são pequenas, mas não simples.

Grande não é o mesmo que acoplado

O contraponto é o Google Drive para Desktop: um programa massivamente grande, dependente de observadores de arquivos específicos de plataforma, do cliente de sincronização e da lógica de resolução de conflitos - mas que se sente simples para o usuário, que apenas instala, escolhe a pasta e decide se mantém arquivos locais.

Descasoplamento na prática

A autora ilustra acoplamento com Rust: uma struct acopla verificação de tipos a uma representação fixa de dados - garante campos presentes conhecidos em tempo de compilação, mas perde informação em tempo de execução (não dá para iterar sobre os campos de uma struct facilmente). Em Clojure, structs são mapas: a tipagem é feita por anotações verificáveis em runtime com bibliotecas como Malli, e as anotações são inspecionáveis - dá até para escrever uma função que gera documentação a partir do esquema. Typed Racket faz algo semelhante com macros, verificando tipos em tempo de compilação.

Quando ser pequeno faz sentido

Programas pequenos são justificáveis quando falta recurso: um mantenedor de código aberto com poucas horas por mês, restrições de hardware ou ambiente hostil. Mas a resposta para "quando o programa deve ser simples?" é: sempre - acoplamento dificulta manutenção e reduz flexibilidade para usuários.

Como fazer programas simples

Exige bom modelo mental e "bom gosto", que a autora admite não saber ensinar. CSS e SQL são exemplos de plataformas majoritariamente descasopladas: o usuário declara o que quer e o motor (navegador ou banco) resolve como - trabalho extremamente difícil, com SQLite acumulando séculos de anos-pessoa e o Blink provavelmente dezenas de milhares. Nem sempre vale esse investimento; trabalho técnico árduo pode atrair pessoas que sonham com como o código poderia funcionar, e às vezes é melhor descansar.

A autora encerra com o retorno ao caso inicial: após a correção, seu pipeline de cobertura de código ficou maior, não menor - mas mais simples, porque havia menos dependências ocultas entre as partes do grafo de fluxo de dados. Posts futuros devem tratar de como desenvolver gosto, como programas podem ser verticalmente integrados permanecendo descasoplados, e como construir sistemas grandes sem torná-los complexos.