Filosofia de engenharia: Rich Hickey, simples não é fácil

Principais lições

• Simples não é fácil. Simples significa não entrelaçado — uma preocupação por coisa — e é objetivo; fácil significa familiar e próximo da mão, e é subjetivo. O tempo todo escolhemos o fácil e o rotulamos erroneamente como simples.
• Entrelaçar é a raiz da complexidade. Complexidade não é o número de partes, mas o quanto elas estão emaranhadas. Entrelaçar estado com tempo, identidade com comportamento, ou política com mecanismo é o que cria um sistema sobre o qual você só consegue rezar.
• Desentrelace sem trégua. Separe as preocupações entrelaçadas em peças independentes que você compõe de forma deliberada. A simplicidade é “uma escolha” que “exige vigilância constante” — ela nunca chega quando se recorre à ferramenta familiar.
• Prefira valores a lugares, dados a objetos. Faça da imutabilidade o padrão e deixe o passado se acumular como fatos imutáveis em vez de sobrescrever o estado no lugar — a disciplina por trás tanto de Clojure quanto de Datomic.

O princípio

“As raízes dessa palavra são ‘sim’ e ‘plex’, e isso significa ‘uma dobra ou trança’ […] bem ao lado de, ou em oposição a, ‘complex’, que significa ‘trançados juntos’ ou ‘dobrados juntos’.” — Rich Hickey, Simple Made Easy¹

Quase toda discussão sobre qualidade de software é, na verdade, duas discussões vestindo uma só palavra, e a contribuição de Rich Hickey é separá-las. Simples e fácil não são sinônimos. Não estão sequer no mesmo eixo: uma mede a coisa, a outra mede a sua distância dela. Simples vem do latim simplex — uma dobra, uma trança, uma torção. Descreve a coisa em si: quantas preocupações estão entrelaçadas nela. É objetivo, e seu oposto é complexo — trançado junto, dobrado sobre si mesmo. Fácil, em contraste, deriva de uma raiz que significa “estar próximo”, a mesma raiz de adjacente.² Fácil descreve a sua relação com a coisa: o quão à mão ela está, o quão familiar, o quão pouco esforço lhe custa começar. É subjetivo, e seu oposto é difícil.¹²

Depois que você enxerga a distinção, não consegue mais deixar de vê-la. A ferramenta que você usa porque está a um npm install de distância é fácil. Se ela é simples — se ela entrelaça a persistência com a sua validação com a sua UI com as suas regras de negócio — é uma questão completamente separada, e a resposta costuma ser não. O tempo todo escolhemos o fácil e o chamamos de simples, e então nos afogamos na complexidade que convidamos a entrar. A palavra de Hickey para o ato de emaranhar é complect (“entrelaçar”): “interpor, enroscar ou trançar”.³ Entrelaçar é o pecado original. É o que transforma um sistema sobre o qual você conseguiria raciocinar em um sobre o qual você só consegue rezar, porque, uma vez que duas preocupações estão trançadas juntas, você não consegue mais tocar em uma sem entender e arriscar a outra.

A disciplina, então, é desentrelaçar — separar sem trégua as preocupações trançadas em peças independentes — e Hickey é direto quanto ao custo. “A simplicidade é uma escolha”, diz ele. “A culpa é sua se você não tem um sistema simples.”⁴ Ela não acontece quando se recorre à ferramenta familiar; ela acontece por meio de “vigilância constante” e cuidado deliberado.⁴ É o princípio inteiro em quatro palavras: simples não é fácil. A simplicidade é o caminho mais difícil, escolhido e não entrelaçado, e é o único que se acumula com o tempo. A mesma convicção sustenta o argumento de que qualidade é a única variável — você não chega a um sistema limpo dando o passo conveniente a cada vez; você o escolhe, contra a corrente, todas as vezes.

Contexto

Rich Hickey é um programador independente que passou cerca de duas décadas escrevendo sistemas em C++, Java e C# para viver antes de construir aquilo pelo que é conhecido.⁵ Ele sabia como fazer grandes sistemas nessas linguagens, e sua conclusão após vinte anos não foi de que elas careciam de recursos. Foi de que elas eram máquinas de entrelaçar — tornavam trivial trançar preocupações umas às outras e ofereciam quase nenhuma ajuda para separá-las.

Então ele construiu a alternativa por conta própria, sozinho. A partir de mais ou menos 2005, Hickey passou cerca de dois anos e meio desenvolvendo Clojure — boa parte com financiamento próprio, trabalhando sem salário em um Lisp para a Java Virtual Machine que tornaria a imutabilidade e a simplicidade o caminho de menor resistência, em vez de um ato de heroísmo.⁵ Ele o lançou publicamente em 2007. Não havia empresa por trás, nem comitê, nem subsídio. Era um programador que tinha visto a doença de perto decidindo gastar anos da própria reserva construindo a cura. Mais tarde ele criou o Datomic, um banco de dados imutável,⁵ e deu uma série de palestras em conferências — Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? — que são, coletivamente, o corpo de filosofia de design mais influente da programação funcional moderna.⁶

O trabalho

Simple Made Easy: simples vs. fácil, e o ato de entrelaçar

Apresentada no Strange Loop em setembro de 2011, Simple Made Easy é a palestra que reorganizou a forma como uma geração de programadores fala sobre complexidade.¹ Toda a sua força vem de se recusar a deixar simples e fácil significarem a mesma coisa. Simples diz respeito à construção — ela é uma dobra só ou muitas trançadas juntas? Fácil diz respeito a você — ela está à mão, é familiar, está dentro da sua capacidade atual? Você pode ter coisas que são simples mas não familiares (difíceis de aprender, fáceis de conviver) e coisas que são fáceis mas complexas (familiares, confortáveis e silenciosamente ruinosas). A maior parte do que a indústria vende como produtividade é do segundo tipo.¹

O verbo no centro de tudo é complect: trançar, interpor, enroscar.³ Entrelaçar é o que torna um sistema complexo — não o número de partes, mas o quanto elas estão emaranhadas. O estado entrelaça valor e tempo. Os objetos entrelaçam estado, identidade e comportamento. Herança, ORMs, condicionais espalhados por um método — cada um trança preocupações que poderiam ter ficado separadas. E o custo de uma trança não é pago uma vez só; é pago a cada mudança futura, porque você não consegue mais tocar em um fio sem perturbar todos os outros.

A cura é desentrelaçar — separar os fios em coisas independentes que você pode compor depois, nos seus próprios termos. A afirmação de Hickey, e ela é forte, é a de que desentrelaçar não é uma perda de poder. “Você pode escrever um sistema tão sofisticado com ferramentas drasticamente mais simples”, diz ele — os mesmos programas, só que agora você consegue de fato raciocinar sobre eles, mudá-los e confiar neles.⁴ A simplicidade não é o subconjunto de capacidade próprio do iniciante. É a disciplina do especialista de se recusar a trançar.

Clojure: um Lisp para a JVM, dados em vez de objetos

Clojure é o princípio tornado executável: um dialeto Lisp dinâmico e funcional que roda na JVM, projetado por Hickey como “um Lisp para programação funcional simbiótico com uma plataforma estabelecida projetada para concorrência”.⁷ Duas decisões codificam a filosofia. Primeira, a imutabilidade é o padrão, não uma opção — as estruturas de dados centrais de Clojure são imutáveis e persistentes, então a coisa mais natural de escrever é também a coisa que não pode ser corrompida por uma mutação distante.⁷ Segunda, dados em vez de objetos: em vez de uma profusão de classes sob medida, cada uma com estado privado e comportamento entrelaçados, Clojure favorece “muitas funções definidas sobre poucas estruturas de dados primárias” — sequências, mapas, vetores, conjuntos.⁷ Simplesmente use mapas. Simplesmente use dados.

Essa separação é o ato de desentrelaçar no nível da gramática de uma linguagem. Os objetos trançam estado, identidade e comportamento em uma única coisa lacrada; Clojure os separa — valores imutáveis para o que uma coisa é, funções simples para o que você faz com ela, tipos de referência explícitos para a mudança gerenciada ao longo do tempo. Ao fazer da JVM a plataforma em vez de lutar contra ela, Hickey também desentrelaçou linguagem de ambiente de execução: Clojure ganha a maturidade, as bibliotecas e o desempenho da JVM de graça, e gasta todo o seu orçamento de novidade no modelo de estado e tempo.⁷

The Value of Values: imutabilidade e Datomic

The Value of Values leva o argumento da imutabilidade a um nível acima, ao próprio banco de dados. O alvo de Hickey é o que ele chama de programação orientada a lugares (place-oriented programming, ou PLOP): “sempre que uma informação nova substitui uma informação antiga, você está fazendo programação orientada a lugares”.⁸ Atualizamos um registro no lugar, o valor antigo se perde e, com ele, a história. Ele argumenta que isso é um resquício de uma era de memória escassa, e que joga fora exatamente aquilo de que um negócio precisa para raciocinar — o passado. Um valor, em contraste, é imutável por definição: um fato é “algo que aconteceu, algo que se sabe ter acontecido”, e um fato não pode ser atualizado, apenas substituído por um fato mais novo.⁸ Um novo presidente não sobrescreve o anterior; ele se acrescenta.

O Datomic é essa ideia construída como banco de dados. Ele é fundamentalmente imutável: “Um banco de dados Datomic é um conjunto de fatos atômicos imutáveis chamados datoms”, e “as transações do Datomic adicionam datoms, nunca os atualizando ou removendo, então você tem uma trilha de auditoria completa”.⁹ Porque nada é jamais sobrescrito, o banco de dados pode ser tratado como um valor referente a um ponto no tempo — você pode consultá-lo “tal como em” (as-of) qualquer instante passado com as mesmas consultas que você roda contra o presente, sem nenhuma alteração.⁹ O banco de dados deixa de ser um único lugar mutável e se torna uma série de valores ao longo do tempo. Estado, identidade e tempo — desentrelaçados, em um repositório de dados de produção.

Hammock-Driven Development: pense primeiro

O complemento de tudo isso é uma palestra sobre quando o verdadeiro trabalho acontece, e a resposta de Hickey é: antes de você tocar no teclado. Em Hammock-Driven Development ele argumenta que “o lugar menos caro para corrigir bugs é quando você está projetando o seu software”, e que a maioria das falhas graves de software são falhas de concepção equivocada — não entendemos o problema antes de começar a resolvê-lo.¹⁰ O remédio é enunciar o problema de forma explícita, reunir os fatos e as restrições e então pensar — inclusive entregando o problema à sua “mente de fundo”, que faz as conexões que a sua “mente desperta” analítica não consegue forçar.¹⁰ A rede de descanso é o móvel literal para não fazer nada além de pensar, sem perturbações.

O desenvolvimento conduzido pela rede de descanso é a prática que torna a simplicidade possível, antes de mais nada. Você não consegue desentrelaçar um sistema que ainda não compreende, e não consegue compreendê-lo enquanto corre para compilar. Ele é a metade dianteira pouco glamorosa de simples não é fácil: o pensamento deliberado, lento e vigilante que tem de acontecer antes que o design não entrelaçado possa surgir.

O método

O método é uma única distinção — simples não é fácil — aplicada com teimosia incomum por toda uma linguagem, um banco de dados e um modo de trabalhar.

Separe “simples” de “fácil” antes de cada decisão. Pergunte de qualquer ferramenta ou design: isto é não entrelaçado (simples), ou apenas familiar e à mão (fácil)? São eixos diferentes, e confundi-los é como a complexidade se infiltra disfarçada de produtividade.¹²

Cace o entrelaçamento e o desentrelace. Complexidade não é a contagem de partes; é o quanto elas estão emaranhadas. Encontre onde o estado está trançado ao tempo, a identidade ao comportamento, a política ao mecanismo — e separe os fios em peças independentes que você compõe de forma deliberada.³

Prefira valores e dados a lugares e objetos. Faça da imutabilidade o padrão. Represente a informação como dados simples — mapas, vetores — e opere sobre ela com funções, em vez de lacrar estado e comportamento juntos dentro de objetos.⁷⁸

Trate o passado como um valor, não como estado sobrescrito. Uma informação nova deve se acrescentar, não destruir. Um sistema que acumula fatos imutáveis ao longo do tempo pode ser raciocinado, auditado e consultado tal como em qualquer momento — o que um lugar sobrescrito in loco nunca poderá.⁸⁹

Pense antes de digitar. O lugar mais barato para corrigir um defeito é no design. Enuncie o problema, alimente-o à sua mente de fundo e conquiste o design simples compreendendo o problema primeiro.¹⁰

Aceite que a simplicidade é difícil e escolhida. Ela não chega quando se recorre ao que é fácil. “A simplicidade é uma escolha”, e ela exige “vigilância constante”. O caminho conveniente e o caminho simples raramente são o mesmo caminho.⁴

Cadeia de influência

Quem o moldou

Lisp e John McCarthy. Clojure é, pela própria formulação de Hickey, “um Lisp não restringido pela compatibilidade retroativa” — a homoiconicidade do código-como-dados e o poder das macros vêm diretamente da linhagem de McCarthy, estendida a mapas e vetores em vez de apenas listas.⁷ (Influência direta)

John Backus e a tradição da programação funcional. A palestra do Prêmio Turing de Backus em 1977, Can Programming Be Liberated from the von Neumann Style?, é o argumento canônico contra a computação orientada a atribuições e a lugares. A guerra de Hickey contra a programação orientada a lugares e o estado mutável é esse argumento levado à produção. (Influência formativa)

A Java Virtual Machine. Em vez de tratar o ambiente de execução como um inimigo a ser abstraído para longe, Hickey fez da JVM a plataforma e construiu a linguagem em cima dela — um desentrelaçamento deliberado de “linguagem” e “ambiente de execução” que deu a Clojure maturidade e alcance desde o primeiro dia. (Influência direta)

O pensamento relacional e orientado a valores. A visão do Datomic dos dados como fatos imutáveis acumulados ao longo do tempo, consultáveis tal como em qualquer ponto, descende da separação, na tradição relacional, dos fatos em relação ao seu armazenamento — a ideia de que a informação tem uma existência independente do lugar que a contém no momento.⁸⁹ (Influência formativa)

Quem ele moldou

O renascimento da programação funcional. Clojure, ao lado de Scala e de outros na JVM, ajudou a mover a programação funcional da curiosidade acadêmica para a produção mainstream, e as palestras de Hickey se tornaram o vocabulário compartilhado — “simples”, “fácil”, “entrelaçar” — que os programadores em atividade agora usam para discutir design.

A imutabilidade, levada ao mainstream. A ideia de que dados imutáveis por padrão são o padrão sensato, e não uma restrição exótica, propagou-se muito além de Clojure. Hoje é o mínimo esperado no design de linguagens e bibliotecas em toda a indústria.

React, Redux e o mundo do front-end. O modelo orientado a valores — estado imutável, transformações puras sobre dados, identidade e estado separados — é a espinha conceitual do React e, especialmente, do Redux. Uma geração de engenheiros de front-end absorveu o pensamento de valores de Hickey sem nem sempre saber de quem ele era.

O fio condutor

John Carmack reduz um renderizador ao seu núcleo rápido e simples e recusa qualquer recurso que trançaria lentidão ao laço interno; Hickey reduz um sistema às suas preocupações não entrelaçadas e recusa qualquer abstração que as entrelaçaria. Ambos tratam a simplicidade como a coisa difícil e escolhida, não como o padrão. E onde Linus Torvalds preza o “bom gosto” que faz um caso especial desaparecer dentro do caso geral, Hickey preza o desentrelaçamento que faz duas preocupações emaranhadas se separarem como uma só — o mesmo instinto visto de pontas opostas: a estrutura certa não é decoração sobre o problema, é o problema corretamente separado em suas partes reais. Yukihiro Matsumoto otimizou Ruby para como é a sensação de escrevê-lo — o fácil, no vocabulário de Hickey — enquanto Hickey otimizou para o que a coisa é — o simples; juntos, eles mapeiam os dois eixos que Hickey passou uma palestra inteira insistindo para que parássemos de confundir. (Ponte da série)

O que eu tiro disto

A lição que guardo é a de que o fácil é uma armadilha disfarçada de virtude. Quase todo arrependimento em uma base de código começou como um recurso razoável àquilo que estava à mão — a biblioteca conveniente, a mutação rápida, a responsabilidade extra dobrada para dentro de uma classe que já existia. Nada disso pareceu um erro, porque o fácil nunca parece. O dom de Hickey é o vocabulário para flagrá-lo no momento: parar e perguntar isto é simples, ou só fácil? e saber que a resposta honesta costuma ser a inconveniente. É o mesmo padrão de qualidade ser a única variável — a pergunta nunca é “o que eu alcanço mais rápido?”, mas “o que está de fato não entrelaçado aqui?”.

No mundo em que construo agora — agentes, laços de ferramentas, código de estrutura local em que estado, prompts, retentativas e efeitos colaterais adoram se trançar numa única coisa ingovernável — a tentação é o fácil máximo: empilhar frameworks, espalhar estado pelo laço, entrelaçar a lógica de decisão com a I/O com o registro até que ninguém consiga mudar uma parte sem arriscar o todo. A jogada de Hickey é desentrelaçar: tirar a política de dentro do mecanismo, tornar o estado imutável onde for possível, tratar cada execução como um valor em vez de um lugar que eu sobrescrevo. Essa convicção — a de que o bom gosto é um sistema técnico que você escolhe com vigilância, não um feeling que você herda ao recorrer ao que está perto — é o fio condutor de um Lisp autofinanciado em 2007 até uma estrutura local de agentes em 2026. Simples não é fácil. Escolha-o mesmo assim.

FAQ

Qual é a diferença entre simples e fácil?

Na formulação de Rich Hickey em Simple Made Easy, simples e fácil são eixos inteiramente diferentes. Simples vem do latim simplex — “uma dobra ou trança” — e descreve a coisa em si: quão poucas preocupações estão entrelaçadas nela. É objetivo, e seu oposto é complexo (“trançado junto”).¹ Fácil deriva de uma raiz que significa “estar próximo”, a mesma raiz de adjacente; descreve a sua relação com a coisa — quão familiar e à mão ela está.² É subjetivo, e seu oposto é difícil. Algo pode ser simples mas não familiar, ou fácil mas profundamente complexo. O ponto de Hickey é que o tempo todo escolhemos o fácil e o rotulamos erroneamente como simples, e pagamos pela complexidade mais tarde.¹

O que significa “complect” (entrelaçar)?

Complect é o verbo que Hickey ressuscitou em Simple Made Easy para o ato de trançar preocupações juntas. Ele o define diretamente: “Significa interpor, enroscar ou trançar”.³ Entrelaçar é o que torna um sistema complexo — não o número de partes, mas o quanto elas estão emaranhadas. Quando duas preocupações estão entrelaçadas (digamos, estado e tempo, ou identidade e comportamento), você não consegue mais mudar uma sem entender e arriscar a outra. O remédio é desentrelaçar: separar os fios em peças independentes que você pode compor de forma deliberada. Hickey trata o desentrelaçamento como a disciplina central de construir sistemas simples.³

O que Rich Hickey construiu?

Rich Hickey é um programador independente que criou Clojure, um dialeto Lisp dinâmico e funcional que roda na Java Virtual Machine. Ele o desenvolveu em grande parte sozinho ao longo de cerca de dois anos e meio, boa parte disso com financiamento próprio, sem salário, e o lançou em 2007.⁵⁷ Mais tarde ele criou o Datomic, um banco de dados imutável que nunca sobrescreve dados, mas acumula fatos imutáveis (“datoms”) ao longo do tempo, de modo que o banco pode ser consultado como um valor referente a qualquer ponto passado.⁹ Ele também é amplamente conhecido por uma série de palestras em conferências — Simple Made Easy, The Value of Values, Hammock-Driven Development e Are We There Yet? — que moldaram a forma como a indústria fala sobre complexidade, imutabilidade e design.⁵⁶

Rich Hickey disse “os programadores conhecem os benefícios de tudo e os trade-offs de nada”?

Essa frase de efeito é amplamente atribuída a Hickey e captura o pensamento dele com exatidão, mas não aparece literalmente nas transcrições de sua palestra principal; é uma paráfrase cristalizada que circulou por livros e palestras em conferências.¹¹ A versão primária literal mais próxima está em Design, Composition, and Performance, onde ele defende desmontar uma solução “para ver não só os benefícios, certo? Esses costumam ser bastante evidentes. Mas também os trade-offs: que parte disto não vai funcionar?”.¹² O sentimento é inequivocamente dele — o de que engenheiros dão peso demais ao que uma ferramenta lhes oferece e examinam de menos o que ela custa — mas o aforismo incisivo é mais bem tratado como uma paráfrase do que como uma citação direta.

Fontes