Pesquisar

sexta-feira, 3 de outubro de 2008

Dsl interna e externa: perguntas e respostas por Martin Fowler

Segue abaixo a traduadaptação [datada em 01/10/2008] (meio capenga) do artigo de Martin Fowler aqui você vê o original.


Fui convidado a criar uma discussão de DSL para não-técnicos. Talvez eu tenha lido muito Stephen O'Grady, mas senti um desejo irresistível de fazê-lo do jeito Q e A (Perguntas e Respostas). Então vamos lá.



O que é uma Domain Specific Language? (ou linguagem de domínio especifico, ou ainda DSL)

Uma Domain Specific Language (DSL) é uma linguagem de programação de expressividade limitada, focada num domínio particular. A maioria das linguagens que você conhece são linguagens de propósito geral (General Purpose Languages), que podem lhe dar com a maioria das coisas que você encontra durante um projeto de sistema. Cada DSL pode agir somente em um aspecto especifico do sistema.

Então você não poderia escrever todo projeto em uma DSL?

Não. A maioria dos projetos irão usar uma linguagem de propósito geral e muitas DSL's.

Essa idéia é nova?

Não totalmente. DSL's tem sido usadas extensamente nos círculos de usuários do Unix desde os primórdios desse sistema. A comunidade Lisp discute a criação de DSL's em Lisp e então usa a DSL para implementar a lógica. A maioria dos projetos de TI usam muitas DSL's – você já deve ter ouvido de coisas como CSS, SQL, expressão regular e etc.

Então porque este assunto está fazendo tanto barulho só agora?

Provavelmente é por causa do Ruby and Rails. Ruby é uma linguagem com muitas características que tornam fácil o desenvolvimento de DSL's e as pessoas que estão envolvidas na comunidade Ruby têm se sentido mais a vontades com essa abordagem, então eles levam vantagem dessas características. Em particular o Rails usa muitas DSL's que o deixam mais fácil de usar. Isto, por sua vez, tem incentivado mais pessoas a seguir essas idéias.

Outra razão é que muitos sistemas feitos em Java ou C# precisam ter muito de seu comportamento definido de forma mais dinâmica. Isto conduziu a arquivos XML complexos que são difíceis de compreender que, por sua vez, levou as pessoas a explorar DSL's novamente.

Então DSL's podem ser usadas com outras linguagens além do Ruby?

Sim, como eu já disse, as DSL's já estavam por ai há muito tempo, mais do que o Ruby. Ruby tem uma sintaxe não obstrutiva e também características de meta-programação que a torna mais fácil para criar elegantes DSL's internas, mais do que outras linguagens como C# e Java. Mas existe DSL's internas uteis feitas em Java e C#

Qual a diferença entre DSL interna e DSL externa?

Uma DSL interna é apenas um idioma particular de escrever código na linguagem hospedeira. Então uma DSL interna feita em Ruby é um código Ruby, escrito num estilo particular que deixa a linguagem mais próxima da linguagem hospede. Tais como elas podem ser chamadas de Interface Fluente ou DSL embutida. Uma DSL externa é uma linguagem completamente separada que é "traduzida" para que a linguagem hospedeira possa entender.

Por que as pessoas estão interessadas nas DSL's?

Eu vejo que as DSL's possuem dois principais benefícios. O benefício mais comum é fazer que certos tipos de códigos fiquem mais fáceis de compreender, que se tornem mais fáceis de modificar, assim melhorando a produtividade do programador. Isto é válido para todos interessados e relativamente fácil de atingir. O benefício mais interessante, todavia, é que uma DSL bem projetada pode ser entendível por pessoas do negocio, permitindo-lhes compreender diretamente o código que implementa suas regras de negócios.

Então este é o gancho – pessoas do negócio escrevendo suas próprias regras?

Em geral eu não penso assim. É muito trabalhoso criar um ambiente que permita as pessoas do negocio escrever suas próprias regras. Você tem que fazer boas ferramentas de edição, depuração, testes e etc. Você tem a maioria dos benefícios das DSL's apenas permitindo que pessoas do negocio sejam capazes de ler as regras. Então eles podem revê-las para aperfeiçoa-las, falar sobre elas com os desenvolvedores e propor mudanças corretas da implementação. Ter DSL's legíveis ao contexto negócios é de longe menos esforço do que ter DSL's escrevíveis pelas pessoas do negócios, mas os ganhos ainda são bons. Existem momentos onde vale a pena o esforço para fazer DSL's escrevíveis por pessoas do negocio, mas esse é um objetivo mais avançado.

Você precisa de ferramentas especiais (leia-se caras)?

Normalmente, não. DSL's internas são apenas facilidades da linguagem de programação que você está usando. DSL's externas requerem que você use algumas ferramentas especiais – mas essas são open source e muito maduras. O maior problema com essas ferramentas é que a maioria dos desenvolvedores não estão acostumados com elas e acreditam que elas são complicadas de usar mais do que elas realmente são (um problema exacerbado pela pobre documentação).

Todavia há exceções no horizonte. Existe uma classe de ferramentas que eu chamo LanguageWorkbench. Essas ferramentas permitem você definir DSL's mais facilmente e também provem sofisticados editores para elas. Ferramentas assim tornam mais viáveis a construção de DSL para os negócios.

Então isto é a repetição do sonho do desenvolvimento de software sem programação (ou programadores)?

Esta foi a intenção do COBOL e não penso que há alguma razão para que as DSL's tenham sucesso onde o COBOL (e tantas outras falharam). Eu penso que é importante que DSL's permitam pessoas do negocio e desenvolvedores colaborarem mais eficientemente porque eles podem falar sobre um conjunto de regras que também são códigos executáveis.

Quando eu deveria considerar a hipótese de criar uma DSL?

Quando você está trabalhando num aspecto do sistema com ricas regras de negócios ou work-flows. Uma DSL bem escrita deveria permitir que os clientes entendessem as regras pelas quais o sistema funciona.

Isto não vai levar a uma cacofonia de linguagens que as pessoas acharam mais difíceis de aprender?

Nós já temos uma cacofonia de frameworks que os programadores tem que aprender. Isto é uma inevitável conseqüência de sistemas reusáveis, é o único jeito que temos de lhe dar com todas essas coisas que os sistemas tem que fazer hoje em dia. Na essência uma DSL não é nada mais do que uma fachada chique sobre um framework. Como resultado elas contribuem um pouquinho com a complexidade que já havia. Na verdade uma boa DSL deveria fazer as coisas melhores tornando esses frameworks mais fáceis de usar.

Mas as pessoas não vão criar muitas DSL's de baixa qualidade?

Claro, assim como pessoas criam frameworks de baixa qualidade. Mas, novamente, eu gostaria de argumentar que DSL's de baixa qualidade não causam mais danos se comparados aos que os frameworks mal projetados causam

3 comentários:

Anônimo disse...

Obrigado pela tradução!

Valter Vasconcelos disse...

Valeu cara. Com meu inglês eu não consegueria entender nem 1/4 da palestra. Mas vou resolver isso em breve!

Obrigado

Valter Vasconcelos disse...

Valeu cara. Com meu inglês eu não consegueria entender nem 1/4 da palestra. Mas vou resolver isso em breve!

Obrigado