At a TSS' Barcelona event Martin Fowler and Neal Ford did a keynote presentation on language-oriented programming, summarized here. In his earlier article, Fowler defined this concept as “the general style of development which operates about the idea of building software around a set of domain specific languages”. Fowler and Ford further develop some of the ideas presented by Fowler at Jaoo 2006 and question the eventuality of an “evolutionary step beyond object-oriented programming”.
Object oriented programming provides a useful modelling paradigm based on hierarchies and tree shaped abstractions. Reality however is not always hierarchical, highlights Neal Ford. Its “tangled branches and interconnections” are rather difficult to model with idealized tree pictures. And this results in a widespread use of aspects and XML and eventually adds complexity undermining the very purpose of abstraction. To remedy to this issue the abstraction level should be upgraded and to this end Ford suggests using languages rather than hierarchies as a modelling mechanism.
According to Martin Fowler object-oriented domain modelling allows to “build up a vocabulary” but the grammar – ways to combine these vocabularies – is not defined; DSLs add this grammar side. Therefore language-oriented programming inducts “this shift of moving from thinking about vocabulary, which is objects, to the notion of a language that combines vocabulary and grammar.”
For Neal Ford, what makes the use of DSLs as a new abstraction mechanism particularly interesting is its ability to supply context. In a context free environment one should “start at the lowest level possible of understanding and have to explain every single detail”. This is the way one talks to APIs and frameworks because they do not have "any sort of context built into" them. Hence the code is full of repeated context often perceived as noise. DSLs on the contrary “always have an implicit context that shows up either not at all or shows up in a very, very light way and usually at the most one time”. Thus this context doesn’t have to be supplied over and over again, which makes the code more readable and more expressive.
Both Fowler and Ford stress how critical the readability issue is. They insist that the purpose of DSLs is often misunderstood. It is not to make it possible for business analysts to write code but to make it possible for them to read and to review it, in order to bridge the gap separating professional developers and business people.
Some are reluctant to use the language oriented programming style because of possible maintainability issues and increasing learning burden, especially given the lack of rich IDEs for the plain text DSLs. Fowler, who argued in his recent article that “larger frameworks […] present as much of a challenge to learn as a language”, emphasizes again the complexity of projects written in a single language. Moreover, Neal Ford stresses that if a DSL is hard to read then it was very poorly designed because “one of the goals [of using DSLs is] to create more readable code”.
As for IDE support there are today at least three major vendors offering this kind of tooling to support language oriented programming: Intentional Software developed by Charles Simonyi, Microsoft’s Software Factories, Meta Programming System developed by JetBrains. These tools, referred to as Language Workbenches by Martin Fowler, make it easier to design and then to use DSLs. This increases the competitive advantage of the language oriented programming style even though Fowler believes that it “is going to be a few years before most people can think about using [Language Workbenches] for real projects.”
What is your opinion? Does language oriented programming have a chance to become “the next big thing”? And to which extent the availability of language workbenches tools could affect your decision to use DSLs on your projects?