Pare de projetar linguagens e, em vez disso, escreva bibliotecas

• O núcleo da produtividade em programação está em um ecossistema rico de bibliotecas, mais do que na própria linguagem
• Frameworks como Ruby on Rails, que aproveitam recursos avançados da linguagem, oferecem alta produtividade até para não especialistas
• Porém, por causa das limitações estruturais da linguagem, é difícil implementar em Java ou C um framework no nível do Rails
• O projeto da linguagem determina diretamente a forma e a complexidade das bibliotecas que podem ser escritas, e esse é o propósito essencial da evolução das linguagens
• A linguagem Stanza, sob essa perspectiva, mostra a importância do projeto de linguagem para possibilitar a criação de bibliotecas poderosas e fáceis de usar

---

Relação entre linguagens de programação e bibliotecas

• A maioria das linguagens de programação tem elementos básicos semelhantes, como variáveis, arrays, loops e funções
  • Algumas linguagens oferecem recursos avançados como funções de primeira classe ou corrotinas, mas não especialistas raramente os utilizam bem
• Para muitos desenvolvedores, o fator que aumenta a produtividade são as bibliotecas, mais do que a linguagem
  • Por exemplo, Ruby on Rails permite criar com facilidade aplicações web baseadas em banco de dados
  • Graças ao Rails, a preferência costuma ser maior pelo framework do que pela própria linguagem Ruby

Interação entre Ruby on Rails e recursos da linguagem

• Rails usa vários recursos do Ruby, como metaprogramação, avaliação em tempo de execução, funções de primeira classe e coleta de lixo
  • Ex.: ActiveRecords usa metaprogramação, e o sistema de templates usa avaliação em tempo de execução
  • O tratamento de eventos é implementado passando funções de primeira classe como callbacks
• Em Java ou C, a falta desses recursos torna impossível implementar um framework no nível do Rails
  • A metaprogramação em Java não é poderosa o suficiente para implementar ActiveRecords
• Portanto, o Rails só é possível graças à estrutura da linguagem Ruby, e o projeto da linguagem determina as possibilidades das bibliotecas

O projeto da linguagem determina a forma das bibliotecas

• A linguagem C oferece reutilização apenas por meio de declaração e chamada de funções, então a maioria das bibliotecas em C assume a forma de conjuntos de funções
• Ruby oferece suporte a funções de primeira classe, permitindo expressar de forma concisa “a ação a executar quando o botão for clicado”
  • Em Java, por outro lado, é preciso definir uma classe de handler, o que torna o código mais complexo
• O poder de expressão da linguagem define diretamente a estrutura e a usabilidade das bibliotecas

Software interativo e o surgimento de frameworks extensíveis

• Na computação em lote dos anos 1970, bibliotecas centradas em funções eram suficientes
• No software interativo moderno, são necessárias bibliotecas extensíveis
  • Em GUIs e sistemas orientados a eventos, exige-se uma estrutura do tipo “executar meu código quando o usuário clicar”
• Java e C++ oferecem extensibilidade por meio de herança e sobrescrita de métodos, e essa estrutura evoluiu para frameworks

Contexto do projeto do Stanza e limites das linguagens

• A motivação para o projeto do Stanza começou com a dificuldade de escrever em Java uma biblioteca de programação de jogos fácil de usar
  • Em Java, era preciso expressar concorrência como uma máquina de estados (state machine)
  • Scheme oferece suporte a continuation, permitindo uma implementação mais intuitiva
• Porém, Scheme não oferece verificação estática de tipos, o que reduz a eficiência da depuração
  • Hoje, a maioria das linguagens ainda não permite estender o sistema de tipos por meio de bibliotecas
• Stanza oferece sistema de tipos opcional, coleta de lixo e sistema de objetos baseado em multimétodos
  • No entanto, não é possível escrever do zero um novo sistema de objetos definido pelo usuário

O propósito das linguagens e direções de pesquisa

• O objetivo de uma linguagem de programação de propósito geral é dar suporte à criação de bibliotecas poderosas e fáceis de usar
  • Quanto mais poderosa a linguagem, mais conciso se torna o uso das bibliotecas
• Quando o código usa uma biblioteca bem projetada, ele tem uma naturalidade que lembra frases dirigidas a um colega
• Racket, Shen e pesquisas sobre protocolos de metaobjetos exploram sistemas extensíveis de tipos e objetos
• Em última instância, as linguagens se distinguem por “quais bibliotecas é possível usar e quais não é”
• Por trás de bibliotecas elegantes existem décadas de pesquisa e esforço de projeto de linguagens

[GN⁺]

Comentários no Hacker News

• O melhor exemplo é Prolog. Costuma ser chamado de linguagem representativa da programação lógica, mas na prática não passa de uma coleção de algoritmos, e poderia ser implementado como biblioteca em várias linguagens. Acho que bastaria oferecer a forma sintática do Prolog adaptada à sintaxe de cada linguagem

  • O núcleo do Prolog não é o algoritmo, mas a forma de expressar regras lógicas de modo declarativo. Por exemplo, se você define a regra “avô é o pai do pai”, dá para encontrar avôs com isso ou, ao contrário, inferir relações de parentalidade. Essa inferência bidirecional é o charme do Prolog. Claro, para imitar isso em uma linguagem comum, seriam necessários código sem efeitos colaterais e uma DSL restrita. Como também é possível fazer chamadas entre linguagens, como PyTorch ou TensorFlow rodando CUDA a partir do Python, acho totalmente viável uma estrutura não dependente de linguagem
  • A sintaxe do Prolog é um subconjunto da lógica de primeira ordem (First Order Logic), e as variáveis não recebem valores diretamente: a busca percorre um conjunto de valores possíveis até satisfazer as condições. O motor do Prolog faz mais do que uma simples chamada de biblioteca — por exemplo, representação compactada do espaço de soluções, execução paralela e poda automática. Por isso, em geral o Prolog é integrado como serviço de backend ou por geração de código. O Prolog é especialmente poderoso em planejamento, resolução de restrições, demonstração de teoremas, testes combinatórios e modelagem de preços. Por isso, acho difícil tratá-lo apenas como “uma linguagem que poderia ser só uma biblioteca”
  • Seguindo a mesma lógica, também daria para dizer que recursos de orientação a objetos não precisam existir na linguagem, já que podem ser imitados com closures. Mas há vantagens na expressividade que uma sintaxe clara oferece
  • Para implementar programação relacional como a do Prolog em forma de biblioteca, a linguagem precisa dar suporte de primeira classe à manipulação de símbolos e variáveis. Linguagens da família Lisp até conseguem, mas em linguagens comuns a usabilidade cai bastante. Quando conversei com Bob Harper, ele disse: “simplesmente crie uma nova linguagem”, e isso me pareceu bem convincente
  • Quero aprender Prolog, mas é difícil encontrar material de nível intermediário entre tutoriais introdutórios e exemplos avançados. Estou tentando resolver variantes de Sudoku em Prolog, mas os exemplos existentes são otimizados demais, então fica difícil aprender a definir relações generalizadas. Em especial, tenho curiosidade sobre como modelar situações em que algumas regras podem estar erradas. Como referência, estou vendo o exemplo de Sudoku do SWI-Prolog

• Há 10 anos eu era fã de Scala. O conceito de “Scalable Language”, de poder criar DSLs dentro do sistema de tipos, era atraente. Mas perdi o interesse quando a comunidade começou a usá-la como se fosse um Haskell sobre a JVM. Hoje tenho expectativa de que tecnologias como WASM ou Graal tragam mais flexibilidade na escolha de linguagens. Muitas vezes JS já basta, mas é bom ter a opção de usar uma linguagem de baixo nível como Rust quando necessário

  • Eu também acho que o maior problema do Scala é o abuso de DSLs. Não é só a linguagem em si: parece que até em frameworks de teste você precisa aprender outra linguagem. Claro, é impressionante conseguir expressar um Hadoop MapReduce em uma linha, mas para a maioria dos trabalhos isso é exagero. Além disso, desenvolvedores Scala tendem a não gostar de escrever “código chato”. Já vi muita gente sair deixando um inferno de manutenção porque quis ser estilosa demais
  • Nem toda a comunidade Scala é orientada ao Haskell. Só alguns magos dos tipos seguem por esse caminho. Scala já é excelente mesmo se for usada apenas como “um Java melhor”. Dá para aproveitar as vantagens do funcional sem grande peso
  • Haskell é frequentemente usado justamente como linguagem para criar DSLs. Haxl, da Meta, e TidalCycles, uma DSL musical, são bons exemplos. Mas bibliotecas baseadas em tipos de ordem superior costumam ter perda severa de desempenho e complexidade desnecessária
  • Você já usou Clojure(Script)? Como é da família Lisp, ele permite programação bottom-up, expandindo a linguagem de acordo com o problema. O On Lisp, do Paul Graham, também enfatiza essa abordagem. Recomendo ainda a palestra Bottom Up vs Top Down Design in Clojure
  • Comecei a aprender Scala recentemente, e estou gostando muito também pelo lado da programação funcional. Acho que é uma linguagem geral o bastante para ser usada de várias formas, além de criação de DSLs. Fiquei curioso se você sente que falta alguma coisa no Scala

• Seria ótimo poder substituir o bash por uma linguagem de script com tipos. Fiz um script simples de parser de JSON em Elixir e ficou bem legal

  • Já experimentou Nushell? Dá para fazer em uma linha tarefas que antes exigiriam uma “linguagem de verdade”. Por exemplo, montar facilmente um pipeline que ordena uma lista de arquivos e gera JSON
  • Na verdade, com shebang já dá para escrever scripts em várias linguagens. Por exemplo, isso funciona com C#, Java e Go. Com o Scriptisto dá para criar scripts com shebang em praticamente qualquer linguagem
  • OCaml também pode ser usado como script. Ele roda direto com #!/usr/bin/env ocaml. Só não tem um recurso para instalar automaticamente dependências externas a partir de um único arquivo
  • Em Go também existe um truque para imitar shebang. A discussão relacionada está aqui
  • Para scripts do dia a dia, Python ou PowerShell também são boas opções

• Linguagem e biblioteca não são mutuamente exclusivas. Algumas bibliotecas na prática funcionam como linguagens, e por outro lado há linguagens projetadas para certas bibliotecas. Julia, por exemplo, é um bom caso de equilíbrio entre desempenho e usabilidade. Dá para escrever diretamente código de alto desempenho em Julia e obter execução otimizada por meio de compilação com especialização de tipos em nível de JIT. O modelo de chamada de função é simples, mas por dentro o funcionamento é muito sofisticado

  • Exato, no fim a ideia central era que precisamos tanto de linguagens quanto de bibliotecas

• Raku foi projetada como uma estrutura que conecta várias sublinguagens (slangs). Por exemplo, regex, PEG e quoting são tratados como minilinguagens separadas, e com Slangify você pode adicionar sua própria DSL com facilidade

  • Mas, pessoalmente, não gosto do tipo vindo depois do nome da variável na sintaxe, então não prefiro Raku

• Um desenvolvedor sênior disse certa vez: “se vejo Rails no currículo, jogo fora na hora”. Isso me fez perceber de novo como é tolo julgar pessoas pela linguagem

  • A ascensão do Rails e o declínio do J2EE não aconteceram ao mesmo tempo por acaso. O Rails mostrou como código de backend simples e opinativo podia ser, e por influência dele surgiram frameworks Java como DropWizard, Javalin e Spring Boot
  • Fiquei curioso sobre qual era a stack desse sênior
  • Dá vontade de eu mesmo recolher a lixeira desse colega. É difícil encontrar bons desenvolvedores Rails. Eu também tenho experiência com RoR e ainda gosto bastante
  • Claro, se você está procurando desenvolvedores Java, talvez filtrar currículos com Rails seja eficiente
  • No fim, os critérios para avaliar pessoas dependem da adequação cultural da organização e do estilo de colaboração. Não existe método perfeito de filtragem

• No fim, linguagens e bibliotecas são meios de comunicação com máquinas e com pessoas. As máquinas se comunicam com bits e voltagens; as pessoas, com intenções e conceitos. Portanto, se uma linguagem ou biblioteca oferece às pessoas uma forma clara e rápida de expressar algo, pouco importa se isso é linguagem ou biblioteca. Rails ou Stanza, se serve ao propósito e a equipe entende com facilidade, então essa é a escolha certa

• Eu penso que “a biblioteca é a linguagem final”. Por exemplo, Ruby on Rails é uma ótima linguagem para serviços web baseada em Ruby. Ruby e Rails evoluíram um em função do outro. No fim, vejo a programação como um processo contínuo de tradução entre linguagens

  • C# e ASP.NET Core também evoluíram juntos de forma parecida. Houve ao mesmo tempo sintaxe amigável para o usuário e otimizações em nível de sistema

• É verdade que “quanto mais poderosa a linguagem, mais fácil fica usar bibliotecas”. Antigamente, em Java era difícil criar um framework como Express

  • Não sei exatamente o que é Express, mas acho que Java se consolidou como linguagem corporativa graças à facilidade de aproveitar bibliotecas
  • A minimal API do ASP.NET Core é um caso de implementação quase direta do Express. Isso só é possível quando linguagem e framework evoluem juntos
  • Em Java também existe um framework parecido com Express, o Javalin. O problema é que a comunidade não quer simplicidade

• Se for para falar de framework web para a linguagem C, então não seria PHP? ;)

  • Isso parece mais uma piada que estica demais o conceito de biblioteca