A programação orientada a idiomas é prática?

Eu li este artigo sobre programação orientada a idioma. Ele aponta algumas fraquezas nas modernas abordagens processuais / POO da programação e sugere um novo paradigma de programação que as resolverá

Sou a favor de partes de programas pequenas e pouco acopladas: é muito melhor aprender muitas coisas pequenas, todas as quais você usará, do que algumas coisas grandes, das quais você usa apenas pedaços de partes.

Ao ler o artigo, tive a impressão de que o autor estava promovendo uma das duas coisas:

• Uma infinidade de linguagens de script fáceis de criar
• Uma linguagem única e facilmente extensível que pode se reescrever para atender às necessidades do programador

Se ele está sugerindo o segundo, eu responderia com "Já foi feito!" e dê o Lisp como um exemplo. Como Paul Graham sugere, as línguas parecem estar continuamente se movendo nessa direção .

No que diz respeito ao primeiro, acho que é uma boa ideia, se houver uma linguagem subjacente que os una. Esse me parece ser o ponto fraco: a comunicação entre as línguas. Você usaria chamadas, que são um conceito processual ou de transmissão de mensagens, que me lembram a comunicação entre processos? Gostaria de receber a oportunidade de trabalhar com pequenos idiomas específicos de domínio, se for fácil usá-los todos ao mesmo tempo. Essa abordagem (LOP) seria prática?

Venho defendendo DSLs há muito tempo, mas me preocupo com o que acontece com as Boas Ideias quando elas se tornam vagões. Os produtos são construídos para anunciar a The Good Idea, prometendo que tudo o que você precisa fazer é obter um , e você estará no grupo, sem precisar pensar com muito cuidado sobre o que isso significa.

O que é um idioma? É um vocabulário e sintaxe em que os significados podem ser comunicados, certo? Toda vez que você declara uma variável, escreve uma função, define uma classe, está construindo um novo idioma, adicionando substantivos e verbos a um idioma existente. Agora você pode dizer coisas que não podia antes.

Acho que o que torna um domínio específico da linguagem é a extensão em que naturalmente expressa os conceitos mentais que estão sendo comunicados, e acho que há uma medida simples disso. Basicamente, se houver um requisito independente independente simples X, que possa ser incluído no programa ou não, sua implementação correta exigirá algum conjunto de inserções, exclusões e substituições de código Y. Um diff simples antes e depois pode ser exibido Y. O número N de tais alterações é uma medida de quão específico do domínio é o idioma. Quanto menor o N, para requisitos típicos, melhor.

Não depende necessariamente de sintaxe sofisticada, estruturas de controle, passagem de mensagens ou o que você tem. O que depende é de quão concisa é a implementação do requisito. Muitas ferramentas pretendem fazer isso, mas as reivindicações não são reais. Tem que ser real .

Às vezes, uma tecnologia incomum é necessária. Aqui está o meu exemplo favorito. Quando é, ilustra o ponto que pode exigir esforço por parte dos programadores para entendê-lo. Portanto, especificidade de domínio (e capacidade de manutenção) não é a mesma coisa que legibilidade .

Então, eu concordo com a segunda abordagem, que uma boa linguagem é aquela que permite facilmente criar as linguagens necessárias sobre ela. (Era disso que eu gostava no Lisp.) Mas o mais importante é que os programadores precisam saber como criar linguagens para corresponder aos domínios em que estão trabalhando e estar dispostos a escalar as curvas de aprendizado dessas linguagens.

Eu realmente não vejo isso acontecendo. Em vez disso, eles ficam presos nos "programas = algoritmos + estrutura de dados" ou "substantivos tornam-se classes e verbos tornam-se métodos" modos de pensar ininterruptos. Eles não estão trabalhando em termos de como obter domínios de pensamento e linguizá-los para concisão máxima.

Essa é a abordagem Ruby.

• Mantenha o idioma principal simples e estenda via gems
• Crie dialetos do Ruby para domínios específicos via patch de macaco. ig Ruby on Rails.

Não sei se isso é melhor, mas acho que é muito pragmático.

A abordagem LOP é extremamente prática. Lembre-se de que você não precisa necessariamente implementar "linguagens de script" - a metodologia também é aplicável aos eDSLs, e eles geralmente são compilados com eficiência. Estou usando essa abordagem em literalmente todo o meu trabalho de desenvolvimento.

Veremos muito mais sobre idiomas específicos do domínio no futuro, a julgar pelas pessoas que estão falando sobre eles agora. Notei Martin Fowler falando muito sobre eles também e alguns artigos interessantes sobre o Lambda The Ultimate sobre o assunto, entre outros.

Isso me sugere que essa é definitivamente uma direção na qual o vento sopra em relação ao design da linguagem de programação e às plataformas de programação. De certa forma, já faz um tempo - uma das vantagens do Ruby (como já foi observado) é que facilita a criação de DSLs, mas na verdade existem muitas delas em aplicativos e bibliotecas de programação que já usamos.

Estou usando o LOP sempre que programar sozinho. Descobri que em alguns projetos não há outra maneira de cumprir o cronograma. Numa alegoria simples, pode-se equiparar o uso de LOP a ferramentas elétricas. Se você estiver trabalhando sozinho no workshop, não poderá fazer as coisas manualmente e cumprir o prazo. Se houver outras pessoas com você, coordenar o uso dessas ferramentas elétricas é essencial para a eficiência e segurança.
No modo de equipe, o LOP requer preparação organizacional para evitar um desastre na Torre de Babel.