Por que o Common Lisp não é a linguagem de programação mais popular?

Artigo original ↗ Discussão no Hacker News ↗

O fascínio duradouro do Common Lisp contrasta com sua adoção limitada: muitos programadores elogiam seu sistema de macros, REPL interativo, tratamento de conditions e estabilidade de longo prazo, mas consideram a sintaxe, o uso intenso de listas encadeadas e a semântica de múltiplos namespaces difíceis de ler e ensinar. Os comentaristas argumentam que ferramentas e bibliotecas fragmentadas, a falta de uma implementação dominante ou de um ecossistema de pacotes único, e a ausência de um grande patrocinador corporativo impediram o CL de se tornar uma escolha padrão na indústria, especialmente em comparação com linguagens derivadas de C, Python ou JavaScript. Há um amplo consenso de que, embora Lisp continue sendo uma “caixa de ferramentas” poderosa e flexível para pequenas equipes especializadas e domínios de nicho, sua flexibilidade, estilo pesado em DSLs e bagagem histórica o tornam uma má opção para grandes organizações de engenharia com desenvolvedores fungíveis e onboarding mainstream.

Efeitos Históricos e de Rede

  • Os primeiros Lisps precisavam de hardware caro; quando as máquinas acompanharam e o CL foi padronizado, C e Unix já haviam conquistado a mente das pessoas.
  • O inverno da IA acabou com fornecedores comerciais de Lisp; hoje não há um grande patrocinador visível análogo à Sun/Oracle para Java ou aos grandes usuários de Python.
  • A popularidade é vista como sendo impulsionada mais por efeitos de rede e patrocínio corporativo do que por mérito técnico.

Ecossistema, Ferramentas e Implantação

  • O gerenciamento de pacotes é descrito como fragmentado e fraco; existem várias ferramentas concorrentes e pouca convergência em torno de “uma única opção óbvia” para coisas como serialização ou async.
  • Alguns argumentam que o ecossistema é mais amplo e mais estável do que os de fora imaginam (Quicklisp, auxiliares de FFI, muitas bibliotecas), mas é mais difícil de descobrir e carece de suporte no estilo do Stack Overflow.
  • REPLs e fluxos de trabalho baseados em imagens são elogiados (conditions, restarts, depuração remota, desenvolvimento incremental), mas a experiência de REPL via CLI nas implementações livres é considerada áspera sem integração com o editor.
  • O tamanho dos binários e a implantação são debatidos: o SBCL pode gerar binários standalone, mas eles são relativamente grandes; implementações comerciais fazem melhor.

Design da Linguagem: Poder vs Acessibilidade

  • Os defensores destacam macros, design baseado em expressões, múltipla dispatch (CLOS), o sistema de conditions/restarts, tipagem incremental, FFI e a estabilidade de longo prazo da especificação.
  • Os críticos veem o CL como um “canivete suíço” com bagagem histórica (namespace separado para funções, listas centradas em cons, modelo de pathname arcaico).
  • Alguns argumentam que o CL “tornou coisas difíceis fáceis, mas coisas fáceis difíceis”: estruturas de dados do dia a dia (vetores, mapas) e a ergonomia de listas parecem piores do que em linguagens modernas.

Listas, Parênteses e Sintaxe

  • Muitos comentaristas dizem que a principal barreira é a sintaxe: parênteses em excesso e idioms centrados em listas encadeadas parecem estranhos e difíceis de ler.
  • Outros contrapõem que, com editores estruturais, indentação e familiaridade, os parênteses “desaparecem”; o verdadeiro problema é que o estilo idiomático de processamento de listas é estranho.
  • Há debate sobre as próprias listas encadeadas: alguns as veem como obsoletas em comparação com arrays e mapas; outros dizem que elas são ideais para programação exploratória, mas precisam ser substituídas por desempenho.

Macros, DSLs e Manutenibilidade

  • Macros e reader macros são vistos ao mesmo tempo como o principal recurso do CL e como sua maldição.
  • Entusiastas valorizam “código que escreve código” e abstrações específicas de domínio; detratores argumentam que cada codebase se torna seu próprio dialeto, aumentando a carga cognitiva e dificultando a manutenção em equipes grandes.
  • São feitas comparações com extensões de Haskell e “subsets” de C++: flexibilidade sem convenções fortes pode produzir código ilegível ou altamente idiossincrático.

Corporativo, Comunidade e Cultura

  • Vários argumentam que o CL se adapta melhor a equipes pequenas e expertas do que a grandes organizações que querem desenvolvedores fungíveis, convenções rígidas e contratação fácil.
  • Alguns veem a comunidade de CL como individualista, lenta para padronizar ou aceitar patches, e sem estruturas coesas de conferência/fundação.
  • Outros relatam uso profissional de CL com satisfação e contestam a ideia de que ele seja impossível de manter ou especialmente problemático para juniores.

Comparações com Outras Linguagens

  • Clojure é citado como um “Lisp moderno” que aproveita o ecossistema Java e estruturas de dados imutáveis.
  • Julia é apontada como influenciada por Lisp, com macros e múltipla dispatch, mas ainda jovem e lidando com questões como tamanho de binários e restarts.
  • Rust, Go, Python e JavaScript são frequentemente contrastados: eles surfam ecossistemas fortes, ferramentas e apoio corporativo, mesmo quando impõem mais restrições ou complexidade do que o CL.