Durante sua palestra no Clojure South, Alex Miller, Engenheiro de Software Principal no Nubank, abordou um problema que est\u00e1 no cerne do trabalho di\u00e1rio de todo desenvolvedor: as formas dolorosas como frequentemente lidamos com dados. Nossa ind\u00fastria est\u00e1 repleta de formatos fr\u00e1geis, objetos sobrecarregados com c\u00f3digo repetitivo (boilerplate) como getters e setters, e as complexidades onipresentes do estado mut\u00e1vel que exigem camada ap\u00f3s camada de prote\u00e7\u00e3o. Esse atrito n\u00e3o \u00e9 apenas uma d\u00edvida t\u00e9cnica; \u00e9 um imposto sobre nossa criatividade e nossa alegria.<\/p>\n\n\n\n
Clojure oferece uma alternativa poderosa a esse paradigma. A linguagem coloca dados simples e imut\u00e1veis e fun\u00e7\u00f5es puras no centro de sua filosofia. Trata-se de uma forma fundamentalmente diferente de pensar sobre software, e n\u00e3o apenas uma sintaxe distinta. Ao adotar esse modelo, podemos construir modelos mentais mais limpos, mais matem\u00e1ticos e incrivelmente poderosos. Essa abordagem, como Alex demonstrou, leva a sistemas que n\u00e3o s\u00e3o apenas mais robustos, mas tamb\u00e9m mais prazerosos de criar.<\/p>\n\n\n\n
A jornada para essa maneira mais simples e poderosa de programar come\u00e7a ao repensarmos uma palavra que usamos todos os dias: “valor”.<\/p>\n\n\n\n
Embora a programa\u00e7\u00e3o envolva a manipula\u00e7\u00e3o de v\u00e1rias entidades, o poder de Clojure deriva de uma defini\u00e7\u00e3o rigorosa de “valores”. Essa distin\u00e7\u00e3o est\u00e1 longe de ser uma trivialidade sem\u00e2ntica; \u00e9 o princ\u00edpio central de design que confere \u00e0 linguagem sua eleg\u00e2ncia caracter\u00edstica. Neste contexto, um valor representa uma categoria espec\u00edfica de dados, definida por propriedades imut\u00e1veis que mudam a forma como raciocinamos sobre o estado.<\/p>\n\n\n\n
Segundo Alex, para que algo seja considerado um valor real, deve possuir quatro caracter\u00edsticas fundamentais:<\/p>\n\n\n\n
Esta defini\u00e7\u00e3o esclarece o que n\u00e3o \u00e9 um valor. Itens como sockets de rede, manipuladores de arquivos (file handles), streams e objetos mut\u00e1veis falham nesse teste.<\/p>\n\n\n\n
Se o Clojure South teve um protagonista silencioso, foi o humilde mapa (map). Isso n\u00e3o \u00e9 por acaso. Clojure rejeita deliberadamente um ecossistema disperso de tipos de cole\u00e7\u00e3o em favor de uma base pequena e poderosa de quatro estruturas fundamentais. Essa escolha estrat\u00e9gica de priorizar um conjunto m\u00ednimo de estruturas de dados promove uma imensa clareza e reutiliza\u00e7\u00e3o de c\u00f3digo.<\/p>\n\n\n\n
Clojure \u00e9 constru\u00edda sobre quatro tipos principais de cole\u00e7\u00e3o, cada um servindo a um prop\u00f3sito estrutural distinto:<\/p>\n\n\n\n
O que torna essas cole\u00e7\u00f5es t\u00e3o poderosas n\u00e3o \u00e9 apenas o fato de serem imut\u00e1veis, mas sim que todas s\u00e3o acess\u00edveis atrav\u00e9s de um vocabul\u00e1rio \u00fanico e universal de fun\u00e7\u00f5es. Em muitas linguagens orientadas a objetos, “cada classe inventa uma nova linguagem”. Para obter o nome de um usu\u00e1rio, voc\u00ea chama user.getFirstName(); para o total de um pedido, order.getTotal(). Essa \u00e9 uma grande fonte de atrito; os desenvolvedores precisam constantemente trocar de contexto, aprendendo um novo “mini-protocolo” para cada objeto que encontram.<\/p>\n\n\n\n
Clojure rejeita essa complexidade sob medida. Em vez disso, a linguagem fornece um conjunto unificado de fun\u00e7\u00f5es \u2014 get, keys, vals, seq, count \u2014 que funcionam em todos os dados. Esse vocabul\u00e1rio comum reduz drasticamente a carga cognitiva. Como observou Alex Miller:<\/p>\n\n\n\n
\n\u201cAprenda a usar map, filter, remove e voc\u00ea saber\u00e1 como navegar por todo o seu conjunto de dados.\u201d <\/p>\n\n\n\n
Alex Miller, Engenheiro de Software Principal no Nubank<\/p>\n<\/blockquote>\n\n\n\n
As mesmas ferramentas funcionam em qualquer lugar, fazendo com que os dados pare\u00e7am pr\u00f3ximos, transparentes e f\u00e1ceis de remodelar.<\/p>\n\n\n\n
Essa linguagem comum para manipular dados \u00e9 a chave que desbloqueia o algoritmo central \u2014 e notavelmente simples \u2014 de Clojure para resolver problemas.<\/p>\n\n\n\n
O algoritmo central da programa\u00e7\u00e3o<\/h2>\n\n\n\n
No cora\u00e7\u00e3o da palestra, Alex apresentou o slide principal \u2014 um algoritmo simples de dois passos que resume toda a filosofia de desenvolvimento em Clojure. \u00c9 uma ideia t\u00e3o poderosa que pode remodelar fundamentalmente a maneira como se aborda a constru\u00e7\u00e3o de software.<\/p>\n\n\n\n
\n“Existe um algoritmo muito simples para programar em Clojure: represente seu dom\u00ednio como dados e escreva fun\u00e7\u00f5es que transformam esses dados. S\u00f3 isso.” <\/p>\n\n\n\n
Alex Miller, Engenheiro de Software Principal no Nubank<\/p>\n<\/blockquote>\n\n\n\n
Este modelo de dois passos de “dados entram, dados saem” \u00e9 profundamente eficaz por v\u00e1rios motivos:<\/p>\n\n\n\n
\n
- Previs\u00edvel e Test\u00e1vel<\/strong>: Fun\u00e7\u00f5es puras que operam sobre valores imut\u00e1veis s\u00e3o a base da previsibilidade. Dada a mesma entrada, elas sempre produzir\u00e3o a mesma sa\u00edda, o que as torna triviais de raciocinar, testar isoladamente e depurar.<\/li>\n\n\n\n
- Compon\u00edvel<\/strong>: Fun\u00e7\u00f5es puras e pequenas s\u00e3o como blocos de Lego. Elas podem ser combinadas e compostas em fun\u00e7\u00f5es maiores e mais complexas que mant\u00eam as mesmas propriedades desej\u00e1veis de previsibilidade e testabilidade.<\/li>\n\n\n\n
- Seguro para Concorr\u00eancia<\/strong>: Ao eliminar o estado mut\u00e1vel compartilhado, este modelo evita toda uma classe de bugs de concorr\u00eancia notoriamente dif\u00edceis. N\u00e3o existem condi\u00e7\u00f5es de corrida (race conditions) ou impasses (deadlocks) quando as fun\u00e7\u00f5es est\u00e3o simplesmente transformando dados imut\u00e1veis.<\/li>\n\n\n\n
- Est\u00e1vel e Evolu\u00edvel<\/strong>: Sistemas constru\u00eddos desta forma s\u00e3o notavelmente est\u00e1veis e f\u00e1ceis de evoluir. Adicionar uma nova funcionalidade muitas vezes significa apenas adicionar uma nova chave a um mapa. As fun\u00e7\u00f5es existentes que n\u00e3o conhecem a nova chave continuar\u00e3o funcionando, completamente inalteradas. Isso permite que os sistemas cres\u00e7am por adi\u00e7\u00e3o, em vez de modifica\u00e7\u00e3o, reduzindo o risco de quebrar o c\u00f3digo existente.<\/li>\n<\/ul>\n\n\n\n
Isso pode soar elegante na teoria, mas seu verdadeiro poder fica claro quando aplicado a problemas do mundo real.<\/p>\n\n\n\n
De listas de tarefas a m\u00fasica: dados em a\u00e7\u00e3o <\/h2>\n\n\n\n
Para demonstrar o algoritmo central na pr\u00e1tica, Alex percorreu uma s\u00e9rie de exemplos diversos, mostrando como qualquer dom\u00ednio pode ser modelado como dados e manipulado com fun\u00e7\u00f5es.<\/p>\n\n\n\n
Uma simples lista de tarefas<\/h4>\n\n\n\n
Um item de uma lista de tarefas n\u00e3o \u00e9 um objeto com m\u00e9todos; \u00e9 simplesmente um mapa contendo chaves como :task (tarefa), :errand (recado) e :duration (dura\u00e7\u00e3o). O conselho de Miller aqui \u00e9 um pilar do design pragm\u00e1tico em Clojure:<\/p>\n\n\n\n
\n“Tenha sempre uma camada de dados base que chegue ao fundo, e use mapas verbosos \u2014 voc\u00ea vai me agradecer depois.” <\/p>\n\n\n\n
Alex Miller, Engenheiro de Software Principal no Nubank<\/p>\n<\/blockquote>\n\n\n\n
A partir dessa base, surge um padr\u00e3o comum: escrever uma pequena fun\u00e7\u00e3o para lidar com um \u00fanico item e, em seguida, outra para lidar com a cole\u00e7\u00e3o. A tarefa de transformar itens de uma lista em HTML segue isso perfeitamente, com uma fun\u00e7\u00e3o convertendo um \u00fanico mapa em uma estrutura de dados Hiccup, e uma segunda aplicando essa fun\u00e7\u00e3o (mapping) sobre a cole\u00e7\u00e3o. Essa \u00eanfase em fun\u00e7\u00f5es pequenas e de prop\u00f3sito \u00fanico \u00e9 onipresente. Como observou Miller: “n\u00e3o \u00e9 incomum olhar para uma base de c\u00f3digo Clojure e ver que… o tamanho m\u00e9dio de uma fun\u00e7\u00e3o \u00e9 de cinco linhas”.<\/p>\n\n\n\n
O Jogo da Vida de Conway<\/h4>\n\n\n\n
A grade infinita do Jogo da Vida de Conway \u00e9 representada elegantemente n\u00e3o com uma matriz bidimensional massiva de zeros e uns, mas com uma representa\u00e7\u00e3o esparsa: um simples conjunto (set) contendo as coordenadas [x, y] das c\u00e9lulas “vivas”. Essa escolha de modelagem de dados \u00e9 incrivelmente poderosa. Toda a l\u00f3gica do jogo torna-se um pipeline de fun\u00e7\u00f5es puras que recebe um conjunto de coordenadas como entrada e produz o pr\u00f3ximo conjunto como sa\u00edda, implementando as regras do jogo com clareza matem\u00e1tica.<\/p>\n\n\n\n
Gr\u00e1ficos e m\u00fasica como dados<\/h4>\n\n\n\n
O padr\u00e3o se estende at\u00e9 mesmo para dom\u00ednios criativos. Um c\u00edrculo em uma tela pode ser representado como um mapa com as chaves :x, :y, :radius (raio) e :color. Da mesma forma, uma nota musical pode ser um mapa com :pitch (tom), :octave (oitava) e :duration. Ao modelar essas entidades como dados, Alex Miller foi capaz de construir um mini-sintetizador no palco, usando uma sequ\u00eancia de mapas para tocar o ic\u00f4nico tema de cinco notas de “Contatos Imediatos do Terceiro Grau”.<\/p>\n\n\n\n
Em todos os casos, a solu\u00e7\u00e3o foi encontrada n\u00e3o pelo design de hierarquias complexas de classes, mas perguntando primeiro: “Qual \u00e9 a estrutura de dados mais simples que pode representar este problema?”, e ent\u00e3o aplicando fun\u00e7\u00f5es simples e compos\u00e1veis para transform\u00e1-la.<\/p>\n\n\n\n
Embora esse modelo cubra a grande maioria das tarefas de programa\u00e7\u00e3o, Clojure tamb\u00e9m oferece uma abordagem baseada em princ\u00edpios para os raros momentos em que os valores realmente precisam mudar ao longo do tempo.<\/p>\n\n\n\n
Gerenciando mudan\u00e7as: uma abordagem baseada em princ\u00edpios para o estado<\/h2>\n\n\n\n
Inevitavelmente, algumas partes de uma aplica\u00e7\u00e3o precisam mudar. A sess\u00e3o de um usu\u00e1rio, uma conex\u00e3o de banco de dados, o estado de um componente de interface \u2014 tudo isso exige o gerenciamento de mudan\u00e7as ao longo do tempo. Para esses cen\u00e1rios, o Clojure oferece uma resposta clara que evita o caos da mutabilidade n\u00e3o gerenciada. O objetivo \u00e9 criar uma “identidade l\u00f3gica est\u00e1vel que ter\u00e1 diferentes valores imut\u00e1veis ao longo do tempo”.<\/p>\n\n\n\n
O Clojure oferece um pequeno conjunto de construtos de estado para esse fim, principalmente atoms, refs e agents. Em vez de sofrerem muta\u00e7\u00e3o direta do valor que cont\u00eam, voc\u00ea fornece a eles uma fun\u00e7\u00e3o pura que calcula o pr\u00f3ximo estado a partir do atual. Esse design significa que os desenvolvedores n\u00e3o realizam travamentos manuais (locking); as leituras est\u00e3o sempre dispon\u00edveis sem coordena\u00e7\u00e3o, e as escritas s\u00e3o gerenciadas com seguran\u00e7a pelo runtime do Clojure.<\/p>\n\n\n\n
O que \u00e9 mais revelador \u00e9 como isso se desenrola na pr\u00e1tica. Quando o Clojure foi criado, seu sistema de Mem\u00f3ria Transacional de Software (STM), constru\u00eddo em torno de refs, era visto como um recurso fundamental. No entanto, ap\u00f3s anos de uso em produ\u00e7\u00e3o, uma verdade surpreendente surgiu. Como Miller observou, os desenvolvedores descobriram que “\u00e9 poss\u00edvel sobreviver com uma quantidade incrivelmente pequena de estado no seu sistema”. A abordagem disciplinada, priorizando os dados, leva naturalmente a arquiteturas onde a grande maioria do c\u00f3digo \u00e9 pura e sem estado, refor\u00e7ando a filosofia central da linguagem.<\/p>\n\n\n\n
Conclus\u00e3o: construindo sobre a rocha, n\u00e3o sobre a areia<\/h2>\n\n\n\n
A mensagem central da palestra de Alex \u00e9 um chamado para o retorno \u00e0 simplicidade. A filosofia \u00e9 clara: construa sistemas sobre uma base de valores imut\u00e1veis e fun\u00e7\u00f5es puras, e gerencie o estado apenas quando for absolutamente necess\u00e1rio. Essa abordagem resulta em programas mais f\u00e1ceis de entender, evoluir e manter.<\/p>\n\n\n\n
Miller concluiu com uma met\u00e1fora poderosa que captura perfeitamente a diferen\u00e7a entre essa abordagem e os paradigmas convencionais, carregados de estados mut\u00e1veis. Seguir essa filosofia \u00e9 como “construir sobre a rocha em vez de construir sobre a areia”.<\/p>\n\n\n\n
A estabilidade e a clareza que adv\u00eam dessa base n\u00e3o s\u00e3o apenas conquistas t\u00e9cnicas; elas s\u00e3o a fonte de uma verdadeira satisfa\u00e7\u00e3o profissional. Isso permite que os desenvolvedores se concentrem em resolver problemas em vez de lutar contra a complexidade acidental de suas ferramentas. A ova\u00e7\u00e3o de p\u00e9 que Alex recebeu n\u00e3o foi apenas por uma palestra bem proferida, mas por articular uma filosofia que traz a alegria de volta ao of\u00edcio da programa\u00e7\u00e3o.<\/p>\n\n\n\n
<\/p>\n\n\n\n