Programação Orientada a Objetos dão um paradigma de modelagem útil baseado em hierarquia e abstrações em forma de árvore. A realidade, no entanto, nem sempre é hierárquica, enfatiza Neal Ford. Seus “galhos enroscados e interconexões” são difíceis de modelar com figuras idealizadas de árvores. E o resultado é o uso generalizado de Aspectos e XML que eventualmente adicionam complexidade destruindo o propósito inicial da abstração. Para remediar esse problema o nível de abstração deve ser atualizado e para isso, sugere Ford, usar linguagens em vez de hierarquias como mecanismos de modelagem.
De acordo com Martin Fowler modelagem de domínios orientados a objetos permitem “construir um vocabulário” mas a gramática – maneiras de combinar esse vocabulário – não está definido; DSLs adicionam esse lado de gramática. Portanto programação orientada a linguagens induzem “esta mudança de mover do pensamento sobre vocabulário, que são objetos, para a noção de uma linguagem que combina vocabulário e gramática”.
Para Neal Ford, o que torna torna o uso de DSLs como um novo mecanismo de abstração interessante é sua habilidade de dar contexto. Em um ambiente livre de contexto alguém precisa “iniciar no nível mais baixo possível do entendimento e ter que explicar cada detalhe”. Essa é maneira que falamos com APIs e frameworks porque eles não tem “nenhum tipo de contexto embutido” neles. Logo o código é cheio de contextos repetidos normalmente percebidos como ‘barulho’. DSLs, ao contrário, “sempre tem um contexto implícito que mostram ou nada, ou de uma maneira muito, muito leve ou normalmente apenas uma vez no máximo.” Esse contexto não precisar se dado repetidamente, o que torna o código mais legível e mais expressivo.
Tanto Fowler quanto Ford estressam quão crítico a legibilidade é. Eles insistem que o propósito das DSLs é normalmente mal-entendido. Não é para tornar possível que analistas de negócios escrevam código, mas para tornar possível a eles ler e revisar, de forma a diminuir a distância separando desenvolvedores e pessoal de negócios.
Alguns são relutantes em usar o estilo de programação orientada a linguagens por causa de possíveis problemas de manutenção e aumento considerável da curva de aprendizagem, especialmente dada a falta de IDEs ricas para o DSL puro-texto. Fowler, que argumentou em seu artigo recenete que frameworks maiores […] apresentam tanto desafio para aprender quanto uma linguagem, enfatiza novamente a complexidade de projetos escritos em uma única linguagem. Mais do que isso, Neal Ford estressa que se uma DSL é difícil de ler então ela foi muito pobremente desenhada porque “um dos objetivos [de usar uma DSL é] criar código mais legível”.
Sobre suporte de IDEs de hoje pelo menos três grandes fornecedores oferecem suporte a esse tipo de programação orientada a linguagens: Intentional Software desenvolvido por Charles Simonyi, Software Factory da Microsoft, Meta Programming System desenvolvido pela JetBrains. Essas ferramentas, referidas como Workbenches de Linguagens por Martin Fowler, tornam mais fácil desenhar e então usar DSLs. Isso aumenta a vantagem competitiva do estilo de programação orientada a linguagem mesmo que Fowler acredite que isso “vai levar alguns anos para que a maioria das pessoas possam pensar em usar [Workbench de Linguagens] para projetos reais”.
Qual sua opinião? Programação Orientada a Linguagens tem alguma chance de se tornar a “próxima grande coisa”? E até que ponto a disponibilidade de ferramentas workbenches de linguagens poderiam afetar sua decisão em usar DSLs em seus projetos?