Abraçando Common Lisp no mundo moderno

Artigo original ↗ Discussão no Hacker News ↗

A relevância moderna do Common Lisp é comparada com Clojure e linguagens baseadas na JVM, com muitos elogiando os novos coletores de lixo do SBCL, opções de implantação de bibliotecas e projetos como o Coalton, ao mesmo tempo em que lamentam a integração fraca com editores, a documentação desigual e ferramentas de GUI datadas. Comentadores debatem se o modelo centrado em Java, com tipagem dinâmica e hospedada do Clojure, e o acesso ao ecossistema compensam seu overhead da JVM, stack traces complicados e a dependência de conhecimento da plataforma subjacente. O fio também aborda alegações ambientais sobre linguagens “mais verdes”, os trade-offs entre IDEs comerciais poderosas de Lisp e ferramentas open-source como Emacs+SLIME/SLY, e questões mais amplas sobre desempenho, depuração e a viabilidade de longo prazo de runtimes hospedados versus autocontidos.

Desenvolvimentos no ecossistema Common Lisp

  • O SBCL está evoluindo ativamente: novos coletores de lixo paralelos e concorrentes estão em beta, com o objetivo de reduzir pausas e aproveitar CPUs multicore.
  • O SBCL-LIBRARIAN melhora a implantação como bibliotecas compartilhadas compatíveis com C para interoperabilidade com C/Python sem RPC.
  • O Coalton adiciona uma camada estática com tipagem, no estilo Haskell, Lisp‑1, com classes de tipo e inferência; sequências persistentes (RRB-trees) fornecem seqs no estilo Clojure.
  • São os usuários, e não comitês, que estão impulsionando muitas dessas inovações.

Common Lisp vs Clojure e Lisps hospedados na JVM

  • Muitos veem Clojure como o Lisp “moderno” mais mainstream, mas outros argumentam que o Emacs Lisp pode ter mais usuários.
  • Objeções ao Clojure: inchaço e uso de memória da JVM, tipagem dinâmica, bibliotecas e stack traces centrados em Java, dependência de conhecimento do host e fragilidade de linguagem hospedada.
  • Alguns apreciam as estruturas de dados imutáveis do Clojure, STM, spec e a interoperabilidade com Java/.NET/JS, mas veem o ecossistema Java como um pacto faustiano.
  • Alternativas mencionadas: Clojure CLR/Script/ERL, Basilisp (Clojure no Python), Armed Bear CL na JVM e Lisps no BEAM.

Ferramentas, editores e depuradores

  • Há suporte a editores para Common Lisp além do Emacs (VS Code, JetBrains, Atom/Pulsar, Lem, Geany etc.), mas ele costuma ser visto como incompleto ou instável.
  • Emacs + SLIME/SLY é visto por alguns como extremamente poderoso; outros o consideram irregular em comparação com IDEs comerciais polidas (Allegro, LispWorks) ou depuradores mainstream (Visual Studio, Smalltalk).
  • Há discordância sobre se o estilo orientado por REPL do CL reduz a necessidade de depuradores GUI “modernos”.

Documentação e curva de aprendizado

  • Vários argumentam que o maior obstáculo à adoção é a documentação ruim e inconsistente das bibliotecas, não os editores.
  • A introspecção do CL (DESCRIBE, ir para a fonte) compensa parcialmente, mas cria uma cultura de ler código em vez de escrever documentação.

Desempenho, eficiência e argumentos “verdes”

  • Alguns afirmam que o Common Lisp (especialmente o SBCL) pode ser mais leve e tão rápido quanto ou mais rápido que linguagens da JVM, especialmente para inicialização e código intensivo em CPU, e portanto mais “verde”.
  • Outros contestam a moldura ambiental, argumentando que os ganhos de energia em datacenters ao trocar Clojure→CL provavelmente são minúsculos, e que os custos de tempo humano também importam.
  • Benchmarks e o desempenho de JVM vs CL vs C/C++ são debatidos, sem consenso claro.

GUIs e aplicativos desktop

  • Os Common Lisps livres não têm uma história de GUI mainstream e multiplataforma.
  • Ideias e projetos mencionados: wrappers no estilo Electron/Tauri em torno de apps web em CL, McCLIM (poderoso, mas imaturo e focado em X11), CLOG, Ceramic (em grande parte sem manutenção) e Nyxt como um ambiente CL-em-um-browser.