Are they also appropriate for dealing with crosscutting concerns? Is AspectJ also a kind of DSL? InfoQ: I guess DSLs can address the problem domain but also the solution domain. Syntax elements such as “” in Java clutter DSLs implemented internally in Java, for example.
RJP: The cleaner the syntax of the language is the cleaner the resulting DSL is. MF: Closures (aka anonymous functions or lambdas) strike me as particularly important since they allow you to control the evaluation order of nested expressions, as well as naturally express a hierarchic structure. Lisp languages have a very flexible syntax and also utilize macro-processing facilities. RJP: Clearly there has to be some way to augment the syntax of the language with some form of new semantics. InfoQ: What should a programming language provide in terms of features and properties to allow easy integration of internal DSLs? However, certain applications, such as pension rules, are actually quite lengthy. Since DSL scripts are frequently short, this is less of an issue. An internal DSL allows the use of an IDE for the host language such editors don’t exist for an external DSL, necessitating potentially the need to create one. RJP: Another consideration is an editor for scripts written in the DSL.
MF: Many developers aren't very familiar with the parsing techniques you need for external DSLs, or they were exposed to them in college in the context of general-purpose languages, which are much more complicated to work with. Additionally, processing a DSL requires additional steps in the build to build the parser. External DSLs require the addition of tools to the development environment.
RJP: But this design flexibility comes at the cost of additional build and development complexity. MF: This flexibility can be particularly useful when working with non-programmers. From the language design perspective, an external DSL provides the greatest flexibility, since internal DSLs must respect the parsing and language semantics of the host language. Tailoring a language to the business problem also provides a mechanism for the business to understand what’s being developed.DSLs provide the option to tailor the language itself to the problem at hand, facilitating communication between the business and the development team.Īs for the internal versus external language decision, each has its advantages.
RJP: Using a language supporting the proper abstractions for the problem at hand is crucial to effective software development. The decision about whether to build a DSL is about whether the advantages of expressing the behavior in a DSL rather than the usual command-query API make it worthwhile. MF: Whenever we talk about the pros and cons of DSL usage, I always stress that a DSL is nothing more than a thin veneer over a library or framework (which we refer to as a Semantic Model). InfoQ: What are the benefits of using DSLs and when would you prefer internal or rather leverage external DSLs? Their embrace of DSLs seems to be a dying movement grasping at straws to retain some fragments of respectability. This is the CASE heritage which correlates with the OMG's MDA. For this group, there's a good synergy with DSLs because DSLs are a good way of expressing models that describe alternative computational models (which I refer to as Adaptive Models in the book).īut there's the other strain of MDSD, those who think diagrams should be worth a thousand lines of code. There are those who are focused on a well defined semantic model that's used to drive computation. I've not kept a close eye on the MDSD community, but it seems to have some quite distinct strains within it. MF: This is a difficult question to tackle. InfoQ: Where is the boundary between MDSD (Model-Driven Software Development) and DSLs? This way we'll have a better chance of seeing what their true potential is. My hope for this book is that it collects together these techniques and thus makes it easier for people to explore DSLs. MF: In my travels I saw quite a few DSLs built in projects, but I think they missed some good ideas because it was too hard to find information about the various techniques you can use to build a DSL. This book attempts to allay the fears people have around creating languages, with the hope that we’ll start to see some interesting and effective new uses of DSLs.
RJP: There is a lack of understanding of DSLs, their uses, and the tools and techniques needed to implement them. InfoQ: What is the main message you like your readers to grasp?