Domain Specific Languages (DSLs) are little languages with specific notations and constructs for resolving problems in a particular application domain. By trading generality for a focused support, DSLs promise substantial gains in productivity and ease of use in a limited domain. Developers, scientists, end-users: we are all using DSLs. Outstanding examples of DSLs are plentiful: Makefiles for building software, Matlab for numeric computations, SQL (Structured Query Language) for databases, Bibtex for managing references, Graphviz for drawing graphs, etc.
DSLs are now spreading all over the place, in numerous domains, and through different shapes:
Plain-old to more fluent APIs;
Internal or embedded DSLs written inside an existing host language;
External DSLs with their own syntax and domain-specific tooling
Let’s see an example of each.
The basic tradeoffs between internal and external DSLs have been already identified and are subject to extensive discussions and research for several years. If we take the example of SQL, users can rely on the plain-old notation. Some Java API like JDBC or on some fluent API like JOOQ are also available and widely used. LINQ is yet another alternative, built on top of C# . In fact, all shapes of DSLs have strengths and weaknesses – whether you are a developer or a user of a DSL.
Who on earth would like to start learning SQL with a Java-like syntax and environment? The external notation is rather used in an introduction to databases. On the other hand SQL has somehow to be integrated with other general-purpose languages in which programs (e.g., Web applications) are written. It does explain the emergence of fluent APIs for SQL like JOOQ.
A new trend is observed. DSLs are now so widespread that very different users with separate roles and varied objectives use them. Depending on the kinds of users, roles or objectives, an external shape or an internal shape of a language might be a better solution. The case of SQL is quite representative of this trend. Our 4-years journey of providing the “right” support (in the domain of feature modeling: http://familiar-project.github.com) led us to develop an external DSL, different shapes of an internal API, and maintain all these languages. A key insight is that there is no one-size- fits-all solution or no clear superiority of a solution compared to another (https://hal.inria.fr/hal-01061576). We found that it does make sense to continue the maintenance of an external and internal DSL.
To the question: Which side are you on? Internal DSLs, External DSLs or both? We thus answer “both”!
What about metamorphic DSLs that change their shape according to your needs? Based on our experience and on an analysis of the DSL engineering field, the vision that we foresee for the future of software languages is their ability to be self-adaptable to the most appropriate shape (including the corresponding integrated development environment) according to a particular usage or task. We call metamorphic DSL such a language, able to change from one shape to another shape.
Being that said, the “metamorphic DSL” vision still needs to be technically realized and scientifically assessed, hopefully before an actual adoption by developers. At the realization level, many approaches are worth considering: projectional technologies (e.g., MPS: jetbrains.com/mps), meta-programming or parsing techniques (e.g., SugarJ: sugarj.org, Conerge: http://convergepl.org/) compilation strategies (e.g., LMS: http://julien.richard-foy.fr/blog/2015/01/06/lightweight-modular-staging-in-5-minutes/), model transformations, etc. For instance, following a model-based approach, we can consider that there exists an abstract syntax common to all DSL shapes; the challenge is then to address the syntactic and semantic gaps that may exist.
As part of our research, we plan to perform usability studies to deeply understand the importance of syntax and tooling support for the different shapes of DSLs. We also want to explore concrete engineering scenarios in which different shapes of a DSL (being internals or externals) are used for developing an application. We hope we and others will contribute around the metamorphic vision of DSLs!