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.
Community comments
Article broken?
by Hermann Schmidt,
Re: Article broken?
by Hermann Schmidt,
Re: Article broken?
by Jean-Jacques Dubray,
Operational semantics; Article comments
by Justin Bailey,
Re: Operational semantics; Article comments
by Vaughn Vernon,
Re: Operational semantics; Article comments
by Jean-Jacques Dubray,
Article broken?
by Hermann Schmidt,
Your message is awaiting moderation. Thank you for participating in the discussion.
Oops, when I looked at this article last night, it was much longer. It seems broken.
Re: Article broken?
by Hermann Schmidt,
Your message is awaiting moderation. Thank you for participating in the discussion.
Now this is really weird. When I click the article in the "News" area, it is short. In the "Educational Content" area it has full length. However, they share the comments.
Re: Article broken?
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hermann:
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
by Justin Bailey,
Your message is awaiting moderation. Thank you for participating in the discussion.
"I could not locate in the literature an attempt to formalize the semantics of an execution element within a DSL specification"
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/....
Overall I found your article interesting but a bit confusing. Do you intend execution elements to be somewhat vague or can you give a more precise definition? Why is Rails classified as "polyadic", but C# is not? Where do Ruby and JavaScript fall? What about C++? I recognise those are all GPLs but they do appear in your graph so I figure they are fair game ...
Intersting stuff, I look forward to seeing more!
Re: Operational semantics; Article comments
by Vaughn Vernon,
Your message is awaiting moderation. Thank you for participating in the discussion.
I found this an interesting topic, but I agree with Justin that it was not presented in a concise and understandable manner. In the end I didn't see clear technical proof that this approach is either doable or valuable. I have many questions about the viability of what is addressed around figure 10. Beyond that foundational argument, which came far too late IMO, at this point I have too many questions and not enough answers with the majority of the assertions made.
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.
Vaughn
Re: Operational semantics; Article comments
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
apologies, I am swamped at the moment, I plan to answer Justin's and your comments within a couple of weeks.