Cuál es el alcance real de los lenguajes de dominio (DSL)?

Vinculado al tema de Software Factories, tratado antes está el papel que se le asigne a los lenguajes de dominio (Domain Specific Languages). Entrar más en detalle en ellos es útil para valorar el alcance real de su importancia en la formula SF, así como su viabilidad de articulación con una herramienta de diseño conducido por modelos. Martin Fowler ha venido publicando varios artículos sobre DSLs relacionados a MDA y SF que abren interesantes vías de análisis:
Languages Workbenches: the killer-app for Domain Specific Languages?
Languages Workbenches and Model Driven Architecture
Entre ellos, una referencia a LABRI (Laboratoire Bordelais de Recherche en Informatique) ofrece una visión general del tema, e introduce en las características distintivas de los lenguajes, y da una lista de casos.
Un aspecto fundamental discutido es la factibilidad de construír un DSL, y quién está en condiciones de hacerlo. Cito:

(...) However, they also raise a key issue which, if not addressed, could obstruct the use of DSLs (...): how does one design and implement a DSL? Resolving this issue is critical to make the approach profitable since there is no point in reducing the complexity of program development by shifting all the complexity into the construction and maintenance of a DSL programming environment. Another related question is: who will develop DSLs? Even in the programming language community, only a few people have actually designed a language. A fortiori, we cannot expect software engineers to have the full expertise to build up new languages. Thus, it is crucial that a methodology and tools are provided to make the DSL approach widely accessible.

El laboratorio desarrolló una solución (un framework) llamada SPRINT. Ver el método que crearon para construír un Lenguaje de Dominio, da una idea de su real capacidad de ser una herramienta genérica para colaborar en el proceso de armado de un sistema (Específicamente, quiero saber cómo es de posible crear un DSL para un proyecto específico, con un problema específico, como dice la presentación de Microsoft (Think of a DSL as a small, highly focused language for solving some clearly identifiable problem that an analyst, architect, developer, tester, or system administrator must wrestle with. Developers are already familiar with examples of DSLs; SQL for data manipulation, XSD for XML document structure definition, and so on. Another example from Visual Studio Team Edition for Software Architects is a DSL for modeling the logical structure of datacenter hardware and host software configurations. This DSL and its related graphical designer can be used to validate during design time that applications are configured to match their intended deployment targets, alerting the developer to problems when they can be fixed more cheaply.Good ways to find candidate DSLs are to identify the patterns used by developers, and then to encapsulate them into a modeling language, or to surface the concepts in a software framework as abstractions in a modeling language that can then generate small amounts of code that extend the framework. These techniques allow us to control the amount and complexity of generated code, offering real value to the developers, without the hassles that characterized CASE products.)

Sigue la descripción del marco metodológico a seguir para especificar un DSL según Sprint:

Our methodology is based on a framework outlined in an earlier paper by Thibault and Consel and put into practice in several DSL prototypes (GAL, PLAN-P) and publications . It can be summarized as follows. (For the sake of clarity, the phases of our methodology are presented sequentially. In practice, the whole process needs to be iterated.)

Estos son los pasos a seguir:

Language analysis

Assuming a problem family has been identified, the first step is to analyze the commonalities and the variations in the corresponding program family. This analysis is fueled by domain knowledge. The result of this analysis includes a description of objects and operations that are needed to express solutions to the family of problems, as well as language requirements (e.g., analyzability) and elements of design (e.g., notations).

Interface definitions

The next phase is to refine the design elements of the DSL. To do so, the syntax of the DSL is defined and its informal semantics is developed. The informal semantics relates the syntactic constructs to the objects and operations (i.e., the building blocks) identified previously. Additionally, the domain of objects and the type of operations are formalized, thus forming the signature of semantic algebras.

Staged semantics

The semantics of a GPL is typically split between the compile-time and the run-time actions. These two parts are also referred to as the static and the dynamic semantics of a language. We propose to perform the same separation in the semantics of a DSL. With respect to software architecture concerns, this separation makes stages of configuration explicit.

Formal definition

Once the static and dynamic components of the language have been determined, the DSL is formally defined. Valuation functions define the semantics of the syntactic constructs. They specify how the operations of the semantic algebras (i.e., the building blocks) are combined.

Abstract machine

Then, the dynamic semantic algebras are grouped to form a dedicated abstract machine which models the dynamic semantics of the DSL. From the denotational semantics, the DSL is given an interpretation in terms of this abstract machine. The state of the semantics is globalized and mapped into abstract machine entities (e.g., registers) dedicated to the program family.

Implementation

The abstract machine is then given an implementation (typically, a library), or possibly many, to account for different operational contexts. The valuation function can be implemented as an interpreter based on an abstract machine implementation, or as a compiler to abstract machine instructions.

Partial evaluation

While interpreting is more flexible, compiling is more efficient. To get the best of both worlds, we use a program transformation technique, namely, partial evaluation, to automatically transform a DSL program into a compiled program, given only an interpreter. Writing the language definition as an interpreter allows fast prototyping, and easier maintenance and extension. However, it does not compromise efficiency as partial evaluation is able to remove the interpretation layer overhead, yielding efficient DSL implementations.

Como se ve, construír un DSL, aun con el auxilio de una herramienta que encauce metodológicamente y abrevie pasos, no es una tarea trivial. Sin hablar de que existe un paso previo metodológico no cubierto (Assuming a problem family has been identified...)
Ni cuestiono los DSLs, ni mucho menos el desarrollo de esta herramienta, para aumentar el campo cubierto por DSLs específicos. Sólo pongo en duda con fuerza la posibilidad de que una colección de DSLs sea la alternativa a un modelo de herramienta del tipo MDA.
En forma desnuda, las afirmaciones de Greenfield y Microsoft no son sino una promesa o una especulación comercial, y la cruda verdad es que estamos hablando del Visual Studio usando C# u otro lenguaje .NET, para hacer interfaz con aquellos DSL que existan, cuando el problema se presente,...y el resto es C#, es decir, lo mismo.