Tirando a poeira do blog com um conteúdo bem bacana. Segue o primeiro post (de muitos, eu espero) que visam discutir temas interessantes, em português, com profissionais que se destacam sobre o assunto.
O tema de hoje é: Domain-Specific Language. E quem vai responder as perguntas é ninguém mais que Phillip Calçado. Baseado em Melbourne, Austrália, Phillip é um experiente arquiteto e desenvolvedor de softwares atuando em grandes projetos na ThoughtWorks.
Laércio Queiroz: Vamos começar pelas definições. Como você define uma Domain-Specific Language?
Phillip Calçado: Uma DSL é uma linguagem estritamente relacionada com um domínio de aplicação. Por ser tão ligada a um domínio em específico ela é muito poderosa dentro dele e, provavelmente, muito ineficiente quando se trata de coisas que fogem a este domínio. Um bom exemplo é HTML. É uma linguagem específica para o domínio de definição de documentos em hipertexto. Se você for descrever um documento em hipertexto para a web utilizar HTML te dá poder e possibilidades; mas se você quiser,digamos, construir uma interface desktop ela não te ajuda muito.
Da mesma forma Java e C# são linguagens genéricas (GPLs – General Purpose Languages). Com estas linguagens você consegue descrever vários tipos de domínios com relativa eficiência mas elas não são particularmente excepcionais em nenhum deles.
lqueiroz: O conceito de DSLs não é novo. Na sua opinião o que fez o mercado dar maior atenção a este técnica agora?
pcalcado: Sim, DSLs são utilizadas há décadas em diversas plataformas de desenvolvimento. O interesse ressurgiu basicamente por dois motivos, creio. O primeiro deles foi à popularização de linguagens que tornam a criação de DSLs algo mais fácil, como Ruby. Hoje usamos dezenas de frameworks e bibliotecas que são -ou dizem ser -DSLs para esta plataforma e cada vez mais as pessoas estão ficando habituadas com e recebendo os benefícios desta abordagem. Engraçado que algumas pessoas estão usando termos como “Ruby-style” para estas técnicas, algo que não faz justiça ao fato que Ruby é apenas um usuário destas técnicas, que foram criadas, definidas, nomeadas e estão presentes de maneira mais profunda em outras plataformas.
Outro motivo é a necessidade de modelar o domínio com ferramentas mais poderosas. Nós usamos técnicas como Domain-Driven Design para tornar o nosso modelo de objetos mais próximo aos conceitos que estamos modelando –o negócio– mas ainda existe muito ruído causado por limitações técnicas. Um passo a frente é nos livramos dos objetos –ou qualquer outro conceito de engenharia de software- como unidade utilizada para modelagem. Objetos são um conceito artificial, não existem no domínio modelado são apenas uma ferramenta. Ao invés de usar a linguagem para modelar objetos que por sua vez modelam o domínio nós modelamos o domínio diretamente na linguagem utilizada.
lqueiroz: As DSLs podem ser classificadas em dois grandes grupos: Textual DSLs e Graphical DSLs. Considerando-se que as duas abordagens têm a mesma intenção, quais as motivações que definem qual o tipo mais adequado de DSL numa determinada situação?
pcalcado: Linguagens de programação, sejam DSLs ou GPLs, podem ser de diversos tipos. Nada impede que você programe utilizando musica ou braile ao invés de texto ou gráficos.
A escolha entre usar (ou criar) uma DSL gráfica ou textual depende do que se quer fazer. Durante décadas nós construímos mecanismos fantásticos para lidar com programas escritos em texto, então uma DSL textual se aproveita disso. Da mesma forma uma DSL gráfica pode ser amigável e/ou representar melhor um dado domínio.
Não existem muitas regras aqui, geralmente a decisão é focada em quem vai usar a linguagem. Se sua DSL vai ser utilizada por programadores profissionais geralmente eles são mais eficientes e lidam melhor com ferramentas textuais, se for usada por clientes e pessoas não tão qualificadas tecnicamente o ideal pode ser uma estrutura de assistentes e editores gráficos.
lqueiroz: Outra interpretação que vem causando confusão é a diferença entre os dois tipos de Textual DSLs: Internal x External. Qual a diferença entre as duas? Em qual momento deve-se escolher por um tipo?
pcalcado: DSLs Internas são aquelas que são criadas dentro de uma linguagem, uma DSL interna está limitada pela sintaxe da linguagem hospedeira. Uma DSL externa e uma linguagem gerada para ser processada por um parser e interpretada ou compilada para um formato executável.
Existem vantagens e desvantagens nas duas estratégias. Se você utiliza uma DSL Interna não precisa criar um parser, compilador ou interpretador: usa os da linguagem hospedeira, o que facilita muito as coisas. Por outro lado, com esta estratégia você perde a liberdade de sintaxe: sua DSL tem que ter uma sintaxe compatível com a linguagem hospedeira. Considere por exemplo o JMock, um framework de mock objects em Java. Apesar do JMock lidar com conceitos bem diferentes de Java o código que você escreve utilizando sua DSL ainda deve ser compilável pelo compilador Java.
Da mesma forma, se você utiliza uma DSL externa vai precisar escrever algum programa que leia e interprete essa linguagem. Ainda que ferramentas como o ANTLR tornem este processo bem simples o trabalho ainda existe e é considerável. A vantagem é que sua linguagem pode ser definida na sintaxe que você quiser já que quem escreve o parser é você.
lqueiroz: Um esforço considerável é exigido quando se pretende criar uma Textual DSL decente. Talvez por isso é mais freqüente a adaptação de uma linguagem (como: Ruby, Java ou C#) usando-a como base para emular as características de uma DSL. Os casos de uso dessas adaptações, em geral, limitam-se a facilitar a configuração de um framework ou subsistema (o que é conhecido também por configuration code). Este é a único contexto onde uma language adaptation se encaixa?
pcalcado: Você adapta uma linguagem para diversas coisas. Uma delas é criar uma DSL interna, neste caso você apenas usa a linguagem como base para criar outra, você não está preocupado em obedecer a convenções ou manter conceitos. Por exemplo você pode criar uma DSL procedural utilizando como base uma linguagem orientada a objetos.
Outra maneira é quando você não está interessado em criar uma outra linguagem, apenas em torna-la mais eficiente e/ou legível em um certo contexto. Um bom exemplo é Criteria API no Hibernate. Essa API usa um estilo chamado method chaining, algo que é comum em outras linguagens mas não faz parte do estilo que usamos em Java. Seria possível utilizar o estilo de Java mas com a adaptação os usuários da linguagem –nós- podem descrever em uma linha o que necessitaria de uma dezena se seguíssemos o estilo normal. Ainda assim ao utilizar Criteria API estamos preocupados em usar corretamente os conceitos da linguagem Java como objetos, classes e métodos.
lqueiroz: Tem sido comum ver exemplos de Fluent Interfaces que servem apenas para tornar o código mais legível. Esta legibilidade é uma conseqüência ou é o principal intento desta técnica?
pcalcado: Eu considero o termo Fluent Interface algo bem confuso. Segundo um de seus autores e principal evangelista, Martin Fowler, Fluent Interfaces são basicamente sinônimos de DSLs internas. Eu não consigo aceitar muito bem essa definição e usava o termo para algo diferente. Como lutar contra o autor não é algo muito inteligente devo passar a chamar minha visão sobre Fluent Interfaces –adaptações feitas na linguagem apenas para torna-la mais legível/eficiente- de outra coisa. Na verdade estou em busca de um nome.
Falando sobre legibilidade e DSLs, não existe uma reação real direta. Uma DSL não precisa ser parecida com linguagem natural ou mesmo sem algo facilmente legível. Mesmo quando a DSL é entendida pelos especialistas no domínio isso não quer dizer que será legível para todos.
Claro que o ideal é termos o máximo de legibilidade sempre mas isso não é necessariamente uma obrigação nas DSLs.
lqueiroz: Uma DSL pode ser utilizada para abstrair as regras de negócio de uma linguagem específica através de metadados, interpretadores e geração de algum tipo de artefato. Qual o seu sentimento sobre essa abordagem?
pcalcado: Esta abordagem é difundida pela Microsoft sob o nome de Software Factories, alem de alguns outros fornecedores com produtos mais antigos nessa linha. Eu considero a idéia que motiva tudo muito boa, mas não creio que esteja pronta para ser vendida como um produto de prateleira. As técnicas de transformação automatizada de modelo, como DSL Tools e MDA, ainda precisam passar por alguns passos importantes para que entendamos quando e como utiliza-las.
lqueiroz: As ferramentas de MDA que usam diagramas UML (ou de outro tipo que contenha notações que descrevam os comportamentos dos objetos) podem ser consideradas Graphical DSLs Tools?
pcalcado: Sim e não. Ferramentas de MDA em si trabalham com metamodelos em UML, uma GPL, por isso não são usuárias da técnica de DSLs. Entretanto -sem cair na polêmica sobre se UML serve para fazer este tipo de coisa- alguns fornecedores de MDA juram que você pode colocar uma DSL no topo da UML ou até como seu substituto. Eu nunca vi isso acontecer, nem em pratica nem em teoria, então não posso falar muito sobre este assunto.
lqueiroz: Existem diversas ferramentas que implementam DSLs gráficas como alternativa (às vezes a única forma) a uma declaração textual. A diferença básica entre as duas formas, textual e gráfica, é a forma como os conceitos do domínio são mapeados – utilizando wrappers/idiomas ou elementos visuais. Você concorda que o escopo dessas DSLs gráficas está sendo limitado ao uso em IDEs?
pcalcado: Uma DSL não tem obrigação de ser abrangente ou de não estar vinculada a uma ferramenta. O fato da IDE XYZ definir sua própria linguagem gráfica não é um problema do ponto de vista de engenharia de DSLs. Pode ser um problema para quem for comprar a ferramenta e ficar preso a ela mas de engenharia não é.
O problema que estas ferramentas geralmente trazem é que elas, como descreve Joel Spolsky, possuem abstrações com muitos vazamentos. Você não consegue se livrar completamente do código em função de um assistente gráfico, sempre vai precisar editar texto. Quando se está ciente disso e a ferramenta é utilizada apenas para produtividade os benefícios podem ser maiores que os problemas, mas geralmente essas coisas são vendidas como “a ferramenta que vai substituir todo o seu time de programadores e vai acabar com a escrita de linhas de código” e aí muitas empresas perdem dinheiro e muitos projetos falham.
lqueiroz: Além do Fragmental.tw quais as outras fontes de informação sobre o tema você recomendaria?
pcalcado: Existem algumas fontes excelentes mas são poucas. Martin Fowler está publicando um livro sobre o assunto e disponibiliza seu rascunho gratuitamente. Eu tenho pontos de discordância com o Fowler mas ainda considero a referência mais atual. Existem dezenas de papers na internet publicados desde os anos 70 sobre o assunto, a maioria trabalha questões muito relevantes ainda hoje. Para encontrar outras fontes eu criei alguns filtros no Google para me avisar todas as vezes que algo com o termo DSL é indexado, tem sido bastante útil. Algumas leituras sobre Lisp e Scheme são fundamentais porque muitos textos descrevem os conceitos usando essas linguagens.
No geral para um conceito que ainda está sendo estudado o melhor é escrever bastante, brincar com DSLs que não fazem nada ou até mesmo que são úteis, e ler como as DSLs atuais são implementadas.
Phillip, muito obrigado pela participação e pelos esclarecimentos. Até o próximo post.
Referências:
Laércio Queiroz 