Rodrigo Kumpera Weblog

Me dei conta hoje que DSLs sofrem do mesmo mal que AOP. Todas palestras e artigos cometem o pecado de sempre surrar um único exemplo. No caso de Aspect Oriented Programming, abusam dos exemplos envolvendo logging. Sem mencionar que de fato sempre estão a falar de tracing! Com DSLs vejo a mesma tendencia acontecer em torno de configuração e fico preocupado. Diferente da outra tecnologia, acredito que Domain Specific Languages são uma ferramenta muito importante em um futuro não muito distante

Antes de tudo, tenho que concordar com este post do Phillip que DSLs são a bola da vez, e todos tem seus olhos virados para ver se rende alguma coisa. Mas o problema hoje não é a falta de ferramentas e sim a um bom playground para experimentarmos com o assunto. Construir, customizar e transformar linguagens não é nada facil e essa é a grande barreira para começarmos a ver avanços.

Mas voltando ao embrólio de como se apresenta o assunto ao grande público. Todos estão falando o tempo todo sobre como configuração é um problema a ser resolvido por linguagens de domínio. Até o Martin Fowler comete essa gafe em sua palestra na JAOO 2006! O problema é o mesmo que logging, eu diria, representa nenhum risco a complexidade de um projeto. Quantos realmente já tiveram problemas relacionados a dificuldade de colocar logging em uma aplicação? Configuração idem.

Além disso, acho que corremos na mesma direção do fiasco que foram as linguagens de quarta geração, as malditas 4GLs que tanto odiamos. Não vamos criar mini linguagens para o cliente poder sair customizando seu sistema, principalmente porque ele não saberia fazer isso de qualquer maneira. Criaremos atalhos para os desenvolvedores na forma de linguagens simples, limitadas e focadas em tarefas muito específicas; ou via customização da linguagem carro chefe do projeto.

DSLs como customizações é uma coisa que já vemos acontecer, via linguagens com suporte à macros (scheme, lisp, erlang*), ou com abuso do mecanismo de metaclasses – um exemplo, um pouco pobre, é RoR e ActiveRecord, que customiza Ruby para facilitar manipulação de banco, pobre pois poderia melhorar em muito a sintaxe em favor da manipulação de dados.

Enfim, acredito que veremos muito ainda sobre esse assunto, principalmente confusão e palestras que falam de configuração. Logo deveremos ter acesso a linguagens faceis de serem customizadas e que permitam muita experimentação no assunto. Foi essa experimentação que permitiu AOP ganhar momento com Java e ser assunto de piada entre C++.

*erlang não ter macros propriamente ditas, mas suporte parser transformers que são capazes de fazer o mesmo trabalho.