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


12

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?


Com certeza tem um enorme potencial alucinante.

2
Não está claro para mim que problema esse paradigma resolve. A propósito, o LISP não é um exemplo de linguagem de sucesso.
Mouviciel

7
@mouviciel depende muito do que exatamente você quer dizer com "sucesso". É usado pela maioria dos programadores? Não. Já existe há muito tempo? Sim - 50 anos e contando. A maioria das linguagens modernas roubou toda uma pilha de recursos úteis? Sim. (Línguas pode roubar ainda mais das línguas Lisp Sim?!)
Frank Shearar

2
Há uma diferença entre uma linguagem amplamente usada e uma útil. Uma linguagem que explora novas áreas geralmente não é usada, mas pode contribuir para todos a longo prazo. Por outro lado, o Java é inútil, pois não traz nada de novo para a tabela (mesmo que seja definitivamente uma linguagem de sucesso para todas as contas).
Matthieu M.

1
Eu consideraria mais útil dominar o Lisp do que dominar o Cobol.
glenatron

Respostas:


8

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.


Definitivamente, concordo com você na parte do movimento - "o chefe de cabelos pontudos sabe em que idioma deve ser escrito. [...] Java". Outra questão é o que Joel chama de "astronauta da arquitetura". Também pude ver DSLs empilhando um sobre o outro infitium (sp?). Eu acho que tudo se resume ao programador -> engenheiro de software -> cientista da computação.
Michael K

E se ele não exige esforço para entender, as chances são de que não é realmente vale a pena :)
Michael K

4

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.


7
RoR não é um dialeto de Ruby.
back2dos

4
@ back2dos: Eu estava pensando em metaprogramação. Claro que o RoR não é uma linguagem de programação diferente. O que quero dizer com dialeto é que, mesmo que tudo abaixo do Rails seja Ruby, do ponto de vista do desenvolvedor, ele está usando Ruby em um nível mais alto de abstração. Um domínio Um dialeto. Ele usa visões, modelos, controladores e os programa usando uma sintaxe que se assemelha a um idioma diferente, um dialeto, por assim dizer. Essa é a beleza de uma linguagem de script tão poderosa quanto Ruby.
Nerian

Eu acho que é importante realmente ver a diferença. O AspectJ é um dialeto do Java, enquanto o AspectR é apenas uma biblioteca Ruby. A diferença é realmente o idioma. Ruby foi projetado para fornecer essa flexibilidade e expressividade e Java não. Ambas podem ser consideradas linguagens de uso geral, a diferença é que o Ruby geralmente é expressivo o suficiente para eliminar a necessidade de uma DSL real para qualquer finalidade geral, enquanto o Java não é, mesmo que, por exemplo, você use normalmente visualizações, modelos e controladores.
back2dos

1

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.


Perdoe minha ignorância - um eDSL poderia ser um pré-processador para outra linguagem, certo?
Michael K

@ Michael, sim, é possível implementar o eDSL dessa maneira, veja o CamlP4, por exemplo. Porém, mais frequentemente, o eDSL é construído com base nos próprios recursos da linguagem (por exemplo, macros Lisp, modelos C ++, etc.).
SK-logic

1

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.


Você pode adicionar FoF com está sendo usado para desenvolver drivers para o multi-kernel Barrelfish. Uma linguagem para desenvolver DSLs em :)
Matthieu M.

0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.