Quando o tópico DomainSpecificLanguage aparece, um dos quebra-cabeças comum é definir o que exatamente é ou não é um DSL. O problema é que não existe uma definição precisa para DSL além de uma grande área cinzenta entre DSLs e outras coisas.
Para mim, um elemento-chave é que DSLs são limitados tanto em escopo (eles se referem a um domínio em particular) e capacidade (eles não têm funcionalidades básicas para linguagens de propósito genérico). Como resultado, bons DSLs são normalmente pequenos e simples: daí termos como “pequenas linguagens” e “mini linguagens”.
Para DSLs internas, a fronteira estranha é o que é uma API e o que é uma DSL. Fundamentalmente não existe diferença: uma DSL interna é apenas uma API com um nome interessante (como diria a velha Bell labs: “design de biblioteca é design de linguagem”). Apesar disso, entretanto, acho que existe uma sensação diferente quando se está trabalhando com uma API que é escrita como uma DSL. Coisas como uma InterfaceFluente podem tornar o trabalho com uma API uma experiência qualitativamente diferente. Pensar em termos de DSL faz pensar sobre facilidade de leitura de uma maneira diferente, explorando a sintaxe da linguagem hospedeira para criar alguma coisa que parece ser independente – rake é um grande exemplo disso.
Quando falamos de DSLs externas a questão, às vezes, vem na forma de qual a diferença entre uma DSL e uma linguagem de propósito geral (General Purpose Language ou GPL – não confundir com a licença GNU). Normalmente um sinal claro é quando a DSL não é Turing-complete ou não tem facilidades de abstração. Regexps (Expressões Regulares) são um bom exemplo dessa limitação de capacidade. SQL é um candidato mais interessante. É uma linguagem complexa e capaz, mas falta ser Turing complete e a habilidade de construir novas abstrações.
Pode uma linguagem ser Turing complete e ainda ser uma DSL? A linguagem de script Ploticus é Turing complete, mas seu foco claro de produzir grafos faz dela uma DSL. Mas então e XSLT? Ele também tem um foco limitado de transformar documentos XML, mas ganhou tantas capacidades que gradualmente as pessoas pensam nela como uma GPL.
O exemplo de Ploticus levanta questões se linguagens embarcadas são DSLs. A linguagem de macro Excel é uma DSL quando é virtualmente o mesmo que Visual Basic? O que acontece quando embarcamos uma linguagem de propósito geral em um aplicativo?
Como na questão de DSL interna VS API, acho que a intenção é a chave aqui, tanto do criador da linguagem quanto do usuário. Se eu usar XSLT apenas para transformar um documento XML então a estou tratando como uma DSL – mesmo que eu faça alguma chamada para fora para embutir algum valor no documento de saída. Entretanto, se eu a usar para resolver o problema do quebra-cabeça das oito rainhas, a estou usando como uma GPL. Se os designers do XSLT a vêem como transformações de XML então estão pensando nela como uma DSL, mesmo que pessoas espertas façam coisas não-naturais com ela.
Essa é uma daquelas discussões de barzinho mas que não deve desviar a atenção das boas idéias em usar DSLs. Elas devem ser desenhadas como sempre, como linguagens limitadas altamente focadas em um problema singular. Se você entrar no design e usar essa idéia como base, elas serão úteis. Afinal, é a usabilidade que realmente conta.