Article: Metamodel Oriented Programming
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.
Re: Article broken?
Re: Article broken?
apologies, I forgot to put a link to the article in the news. We usually publish a news item for each article. So the "short" version is just the news item.
Operational semantics; Article comments
I think you'll find specifications for execution if you look in functional programming literature. It may not be in the context of a DSL, but you'll see specifications for various "machines" and how they compute. For example, Simon Peyton-Jones' book "Implementing Functional Languages" describes how to reduce a "graph" of expressions through various machines. A free version is online at research.microsoft.com/en-us/um/people/simonpj/....
Intersting stuff, I look forward to seeing more!
Re: Operational semantics; Article comments
Surprisingly I am left wondering how this is different from UML Action Semantics (MDA), which promised much and delivered little. I assume that there are at least some similarities. While there was, frankly, wide criticism for conventional approaches (that have been successful, though could stand improvement), there was no mention of previously unsuccessful novel approaches and why this one is better.
I am curious about further topics around this, but I am not sure they will get traction if the foundation is not squarely laid.
Beyond execution elements, which I do agree are severely lacking and currently only address by Foreign Code, there are still vast improvements to be made in M2-M3 static structure. For example, we have still not learned that there is far more to a property element than: scope type name. Architecturally (abstract and concrete) property nature is so fragmented through our systems that we are probably not sure what and where they actually are.
How Can We Use Our Creative Power and Technological Opportunity to Address the Challenges of the 21st Century?
Gyorgyi Galik Feb 26, 2015