Model Driven Engineering (MDE) seems to be regaining some interest lately with concepts such as textual-DSLs and internal-DSLs.
In this article I argue that this taxonomy is arbitrary and does not necessarily reflect the nature of DSLs. I suggest that DSLs be classified from anemic DSLs to cogent DSLs and from monadic to polyadic.
Anemic DSLs are DSLs that do not have any “execution elements”. An example of an execution element is the method of a class. In other words, a method is a DSL element with an execution attribute that contains the implementation of the method. I propose to call a DSL that has one or more execution elements, a cogent-DSL.
DSLs need also to be classified based on their number of elements. This is important because as solution models are built from a DSL, the degree of reification of the solution's building blocks will strongly depend on this number. I argue that General Purpose Languages such as Java and C# are in effect cogent-DSLs, but these cogent-DSLs yield a "monadic" programming model that requires a high degree of reification, while the cogent-DSLs that truly reflect the building blocks of a solution yield a polyadic programming model that can drastically improve the productivity of the construction process.
Execution elements in DSLs are not new, they are actually one of the reason for the increase popularity of textual and internal DSLs. However textual DSLs treat execution elements as just another set of metadata that ends up in the Abstract Syntax Tree (AST) and internal DSLs are constrained to the semantics of the host language. In the article, I propose a relatively simple modification to traditional MDA approaches that provides a formalism that defines the structure of these execution elements. Without such formalism, it is likely that textual DSL designers will be defining proprietary, inconsistent and often incomplete execution semantics while internal DSL designers will always remain constrained by the semantics of the host language.
The proposed approach automates the production of architecture independent context-free languages while focusing the elaboration of models on the building blocks that are the most relevant to the solution model.
In the last section of the article I show how cogent DSLs and polyadic programming models can lead to architecture refactoring and possibly to architecture defactoring. This paper is somewhat an answer to Alan Kay's keynote presentation at OOPSLA in 1997 that saw the potential for architecture to influence programming models. I argue that up until today programming models and software architectures have evolved orthogonally. Metamodel Oriented Programming is opening the door to architecture friendly programming models while building on the existing Model Driven Engineering legacy.