Por que o Common Lisp agora é a melhor linguagem de programação

Artigo original ↗ Discussão no Hacker News ↗

Common Lisp é apresentado aqui como a linguagem ideal para a “era dos LLMs” por causa de seu desenvolvimento vivo baseado em imagens, depurador poderoso e sistema de macros para construir linguagens específicas de domínio concisas que poderiam reduzir o uso de tokens e acelerar a programação guiada por agentes. Muitos respondentes rebatem, argumentando que tipos estáticos fortes (Rust, OCaml, F#, Go etc.), ferramentas maduras e ecossistemas grandes importam mais para desenvolvimento assistido por IA, e que hot reload e depuração interativa já existem em outras plataformas também. A conclusão mais ampla é que nenhuma única “melhor” linguagem emergiu para programação baseada em LLMs: a escolha da linguagem ainda depende de domínio, arquitetura e manutenção por humanos, mesmo que as pessoas relatem resultados promissores com vários Lisps, Python e outros ecossistemas.

Depurador, condições e recarga a quente

  • Muitos comentários focam no sistema de condições do Common Lisp: erros não capturados podem cair em um depurador interativo sem desfazer a pilha, permitindo alterar valores ou recompilar funções e depois retomar a execução.
  • Os defensores dizem que isso encurta o ciclo de depuração, funciona mesmo com código compilado e é especialmente poderoso em sistemas de longa duração ou no desenvolvimento orientado por REPL.
  • Os críticos argumentam que isso é arriscado em produção (alterações “ao vivo” sem rastreamento, possíveis armadilhas) e que, na prática, servidores em CL normalmente apenas registram backtraces e encerram a requisição, como em outras linguagens.
  • Vários observam que outros ecossistemas (.NET, Java, Dart, JavaScript, Smalltalk) também suportam depuração remota, edit-and-continue ou hot reload, então o CL não é único nesse aspecto.

Macros, DSLs e eficiência de tokens para LLMs

  • Vozes pró-Lisp enfatizam macros para construir DSLs que codificam opiniões de domínio e reduzem muito o tamanho das bases de código, o que poderia diminuir o uso de tokens por LLMs e melhorar a legibilidade.
  • Outros contrapõem que:
    • DSLs trazem sua própria carga de aprendizado/manutenção e podem facilmente virar um macro-hell opaco.
    • LLMs não precisam de DSLs para serem produtivos e podem preferir linguagens populares com abundante dados de treinamento e convenções.
    • Hosts estáticos e tipados (Rust, OCaml, Lean) talvez sejam plataformas melhores para DSLs devido a garantias mais fortes.
  • Há um debate amplo sobre se brevidade e “plasticidade da linguagem” realmente dominam o desempenho de LLMs em comparação com arquitetura, tipos e ecossistema.

Desenvolvimento baseado em imagens e agentes

  • Vários relatam bons resultados conectando agentes LLM a Lisps vivos (Common Lisp, Clojure, imagens no estilo Smalltalk, Janet): os agentes se conectam a REPLs, recarregam código, executam testes e introspectam o estado dentro de um sistema em execução.
  • Esse fluxo de trabalho é descrito como rápido e “tecnologia alienígena”, mas também nichado e em desacordo com a implantação descartável baseada em contêineres; alguns acham padrões semelhantes viáveis em Python/iPython ou Node com autoreload.

Tipagem estática vs dinâmica

  • Um lado argumenta que tipos estáticos fortes (Rust, OCaml, Haskell, Scala, F#) são especialmente valiosos para LLMs: eles funcionam como especificações executáveis, fornecem feedback preciso do compilador, restringem o espaço de busca e ajudam grandes equipes a refatorar.
  • Outros observam que:
    • Common Lisp é fortemente tipado em tempo de execução e pode suportar sistemas estáticos (por exemplo, no estilo Coalton) por cima.
    • Ecossistemas dinâmicos podem usar especificações em tempo de execução, predicados e testes gerativos para capturar invariantes ricos que muitos sistemas estáticos populares não expressam facilmente.
  • Não há consenso; ambos os lados citam experiência pessoal com LLMs favorecendo seu paradigma preferido.

Desempenho, bibliotecas e segurança

  • O desempenho do CL (especialmente SBCL) é descrito como competitivo com outras linguagens gerenciadas, embora bem atrás de C/C++ otimizados em benchmarks.
  • Preocupações com o ecossistema: menos bibliotecas, e menos auditadas; suporte ausente ou mais fraco para peças “fundamentais” como SDKs de nuvem, drivers de banco de dados, ASN.1, etc.
  • Alguns argumentam que LLMs podem portar ou reimplementar bibliotecas ausentes com baixo custo; outros temem redescobrir peculiaridades, falta de revisão de segurança e o custo em tokens de reescritas “do zero”.

Afirmações de “melhor linguagem” e ceticismo sobre o artigo

  • Muitos rejeitam a noção de uma única linguagem “melhor”, invocando ordens parciais e trade-offs multidimensionais; a escolha da linguagem é vista como dependente do domínio e da organização.
  • Vários comentaristas dizem que o artigo exagera a singularidade do CL e minimiza recursos semelhantes em outros ecossistemas; alguns o chamam de conteúdo movido por fãs ou até mesmo de “slop” gerado por LLM.
  • Há uma meta-discussão de que agora toda comunidade argumenta que seu favorito pré-LLM (Python, Rust, Go, F#, Elixir, etc.) é “a linguagem agente perfeita”, com justificativas amplamente simétricas.

Diversos

  • Discussão sobre ERP/DSL: pessoas observam que domínios de ERP diferem muito entre indústrias; a semântica é a parte difícil, então DSLs e até LLMs não produzem magicamente linguagens ERP reutilizáveis e universais.
  • O site vinculado é apontado por alguns como suspeito devido a um div invisível contendo links pornográficos, fazendo com que filtros corporativos o classifiquem como “material adulto”.