Toda vez que alguém fala em DSLs no GUJ vem um troll e fala ‘bah, mas isso existe há anos e ninguém nunca se importou, por que essa comoção agora?’. Apesar do comentário refletir a presença de espírito do clássico Troll de internet, uma coisa é certa: linguagens de domínio existem há muito tempo. O que está errado é que o hype sobre elas não é de agora.
Linguagens de domínio, mini-linguagens, etc. sempre foram utilizadas para tarefas onde uma linguagem de programação atrapalha a entender conceitos complexos. Há alguns anos, estes conceitos eram bem diferentes do que enfrentamos hoje.
Quem programa há algum tempo deve lembrar de quando, por exemplo, não existiam servidores de aplicação amplamente disponíveis. Para usar transações distribuídas, cache, gerenciamento de conexões, etc. ou você implementava na unha ou comprava produtos de fornecedores e tentava arduamente fazer com que conversassem.
A USENIX organizou duas edições de sua Conference on Domain-Specific Languages. A primeira edição, em 1997, traz nos seus papers o uso de DSLs para ajudar ans dificuldades da época. Uma das publicações fala sobre a implementação de uma linguagem específica para geração de formulários HTML.
Hoje em dia você pode usar uma DSL para isso dentre as várias existentes: Struts tags, JSF, Microsoft WebForms ou algo do tipo, além de outras DSL como ASP, JSP e PHP facilitarem o desenvolvimento de formulários mesmo antes destas DSLs surgirem.
Apesar do foco acadêmico dos papers (mesmo contando que a maioria dos interessantes, bem como a própria organização da cofnerência, não vem da academia), os problemas enfrentados pelas DSLs descritas era o problema do dia-a-dia dos programadores.
A grande maioria destes problemas foi resolvido nestes últimos 7 anos, pelo menos para o programador de aplicativos. Hoje você adquire um servidor de aplicações padronizado e não precisa se preocupar tanto com a ifnra-estrutura, com qual protocolo seu cache distribuído trabalha, etc. O problema do programador de aplicações hoje é diferente, cada vez mais ele precisa se relacionar com o domínio do problema de negócios sendo resolvido, e daí vêm uma nova safra de DSLs.
Hoje as DSL estão surgindo para resolver os problemas de negócios. mesmo utilizando linguagens Orientadas a Objetos de alto nível, no fim das contas o artefato produzido (o código) é formado por um agrupamento de convenções. para um exemplo simples, o que é mais legível? Isso:
BigDecimal um = new BigDecimal("1");
BigDecimal dois = new BigDecimal("2");
BigDecimal soma = um.add(dois);
Ou isso:
int soma = 1 + 2;
Se Java não possuísse literais numéricos e operadores aritméticos seria simplesmente terrivalmente chato e tendencioso a erros o ato de implementar qualquer soma básica. Esse problema já acontece, por exemplo, com números de ponto flutuante. Fazer aritmética com ponto flutuante utilizando double e literais numéricos ao invés de BigDecimals é o erro básico de qualquer iniciante (e muitos e muitos veteranos) em Java.
Assim como uma linguagem específica facilita cálculos, pode facilitar a modelagem de diversos processos de negócio.
Talvez o maior impeditivo para que se propaguem hoje está na ausência de uma infra-estrutura, frameworks e utilitários para sua geração, mas JBoss, Microsoft, JetBrains e outras empresas já trabalham nisso há algum tempo.
