Language-oriented programming : an evolutionary step beyond object-oriented programming?

by Sadek Drobi on Sep 19, 2007 |

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?

Related Editorial

Continuous Delivery: A Maturity Assessment Model

10 Key Guide Points for Continuous Delivery

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

How do you Develop a Shared Understanding on an Agile project?

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

An "evolutionary step" certainly... by Sebastien Auvray Posted

Re: An by Sadek Drobi Posted

Re: An by Michael Neale Posted

Re: An by Geoffrey Wiseman Posted

Re: An by Ron Kersic Posted

LOPped by mikhail franco Posted

Re: LOPped by Peter Bell Posted

Re: ... at least three major vendors offering this kind of tooling ... by Richard Boyd Posted

DSLs are important by Arnon Rotem-Gal-Oz Posted

disappointing by Joost de Vries Posted

Re: disappointing by Ron Kersic Posted

Re: disappointing by Joost de Vries Posted

Re: disappointing by Ron Kersic Posted

Is this just for a new buzzword? by Ke Jin Posted

An "evolutionary step" certainly... by Sebastien Auvray

... A *new* way of thinking, certainly not! Martin fowler were already speaking about Language Oriented Programming 2 years back after JetBrains became one of the rare company to give a suite using LOP. Unfortunately 2 years ago it was a failure maybe today spirits are more ready for that... (see When visionaries are too much in advance)

Re: An by Sadek Drobi

... A *new* way of thinking, certainly not! Martin fowler were already speaking about Language Oriented Programming 2 years back after JetBrains became one of the rare company to give a suite using LOP. Unfortunately 2 years ago it was a failure maybe today spirits are more ready for that... (see When visionaries are too much in advance )

According to Wikipedia
"Object-oriented programming roots reach all the way back to the 1960s" "It was not commonly used in mainstream software application development until the early 1990s. Many modern programming languages now support OOP." Smaltalk's Development started in 1969,Publicly available in 1980... So all of that is just to say that mainstream's adoption of paradigms is slow in manyear unit. Just now, java and .net are adopting functional programming features like closures, that has been there for ages. I don't guess LOP adoption is the worst case.
The *new* was for the *new mainstream's* because as you mentioned, mainstream's behavior can't be anticipated.

Re: An by Michael Neale

No - go back further. to SICP from MIT. You can even find them on google video - there is a lecture where they talk about how lisp is a great environment to build a language that solves your problem (but they don't say DSL). This is in the 80's. Probably even 70's.

Martin Fowler writes about concepts that are coming to the fore in enterprise development, I don't think he is a researched uncovering new concepts (nor does he claim to be).

Re: ... at least three major vendors offering this kind of tooling ... by Richard Boyd

A fourth.
Maybe not "major" vendor, but more advanced than the other three.

REBOL was first released in 1997.
en.wikipedia.org/wiki/REBOL

www.rebol.com/what-rebol.html
-- It uses "relative expressions" (context dependent dialects) to create a powerful new dimension similar to that found in natural human languages.
-- REBOL introduces the concept of dialecting. Dialects are small, efficient, domain-specific languages for code, data, and metadata.

Re: An by Geoffrey Wiseman

I'm with you there. To be honest, I think LOP has jumped the shark for now; it's an interesting idea, but I don't think the tooling is going to be exciting anytime soon. It's interesting watching IDEs like Eclipse and Netbeans struggle with decent support for just a few languages.

Certainly, I think it's very interesting to see the development of DSLs in Ruby, simply because it's a language that's well-suited to DSLs. Unfortunately, so far it also seems to be a language that's relatively resistent to tooling. ;)

I'm sure there'll be progress on this front, but I don't think a breakthrough is just around the corner, either.

DSLs are important by Arnon Rotem-Gal-Oz

I think DSLs have a good chance to catch-on as long as the DSLs are kept compact and code oriented. In fact this is already happening and not just in Ruby or other dynamic languages but also in C# and Java by using ideas like fluent interfaces etc. I wrote about it a few weeks ago

LOPped by mikhail franco

Intentional hasn't shipped anything yet, it's founder should get a rocket under him. JetBrains MPS appears to have been frozen 2 years ago. A similar MDA-DSL workbench product from Xactium also seems to have died without trace.
A killer app indeed.

Mik

Re: An by Ron Kersic

I'm not sure if you would qualify it as exciting, but openArchtectureWare's xText certainly deserves to be mentioned in this context. It's basically a grammar definition system that generates (among other things) Eclipse editor support (syntax highlighting, code completion, error checking) for your textual DSL. As an example of how far this system can be pushed, take a look at Fornax Sculptor; a DSL based on DDD concepts and implemented with xText.

While the real language workbenches (and Eclipse's GMF belongs in this category as well) might be ultimate in LOP IDE, approaches like xText (Stratego/XT is another example) seem to scratch my DSL itch best today.

\Ron

disappointing by Joost de Vries

I agree that it's extremely disappointing that Jetbrains MPS stalled and Intentional Programming is only available to closed preview programs.
As a result I'm not interested in Fowlers 'visionary' tales until good Language Workbenches become widely available.

Re: disappointing by Ron Kersic

Depends on your definition of 'good' of course, but you can get them _today_ from Microsoft (Software Factories), Eclipse (GMF) and MetaCase (MetaEdit+). Take your pick...

\Ron

Re: disappointing by Joost de Vries

Good point Ron. I reacted too quickly.
Actually I was very jealous of my Microsoft oriented colleagues working with DSL-Tools.

I looked into finding a Java oriented equivalent.
I got the impression that GMF is the bare bones framework with which someone could build a Language Workbench. Such as Borland, IBM and Markus Voellter have done.
I looked into Openarchitectureware but frankly found the learning curve to steep for perusing the technology while not being able to use it in a project.
I've heard about MetaEdit. Apparently they have been around for a long time.
I had never heard of xText. So thanks for the link.

Is this just for a new buzzword? by Ke Jin

Domain specific language and/or modeling (DSL and DSM), as a very effective paradigm, have been around for more than a decade. Other than a newly coined buzzword "LOP", lengthy discussions on common sense facts (such as the advantage of abstracting by language/grammar, which has been well accepted among DSL advocates long before them), and obvious non-substantial issues (such as internal vs external grammars), I fail to see this talk presented useful and significant new concepts.

The talk does throw out a few non-orthodox but unjustified claims (or they don’t bother to justify them?), such as:

“For the past 20 years or so, we have been trying to model the world with trees. That is the way we model the world in object-oriented languages is build hierarchies, trees, trees of how we model things in code and it turns out that that works out pretty well because most of the world is tree shaped. Most of the world is hierarchical. You can fit things into trees pretty easily but that abstraction breaks down sometimes because a lot of times, we try to model the real world. We model it like this with a nice tree abstract picture of trees, and of course this is idealized. This is not the way the world really looks. The world really looks like this, tangled branches and interconnections and all sorts of other things that are really, really hard to model in these kind of idealized pictures. So what we have been trying to do is model the world with hierarchies but hierarchies fall down at some point and so we invent things like aspects.”

First, they didn’t rationalize why OO is merely about “model the world with trees and/or … build hierarchies.” A plain and obvious fact is that OO programming languages such as C++, Java do not enforce trees and hierarchies other than the inheritance based class extending. For general cases, nothing in these OO languages discourages models and structures of non-tree/non-hierarchy and vice versa. Widely observable from microscope level abstractions (such as linked list) to marcoscope level system designs on UML object diagrams, in the past 20 years, people have been modeling with non-trees/non-hierarchies no less than the opposite.

The argument of

“hierarchies fall down at some point and so we invent things like aspects”

sound like to say “the file directory tree structure model fall down, and so we invent things like directory/file access control, monitoring, event triggering and logging”.

Second, DSL folks never claimed that increasing expressiveness of a language for a specific problem domain was contrary to abstracting by hierarchies and modeling with trees. This argument should be the only important new idea in their talk they could safely claim to be their credit, if it could be justified. However, as giving no evidence on their claims of OO discourages modeling with non-trees and non-hierarchies, they did neither bother to justify why designing and using domain specific language grammars are contradictory to modeling with trees and building hierarchies.

It is pretty common that DSL grammars, especially declarative DSL grammars (schemas) are defined by their schema trees. An example is defining DSLs using LISP defmacro. An important concept in LISP is “data is code, and code is data”. Therefore, the new DSL schema defined in by a defmacro is effectively expressed in a s-express (data) tree. Therefore, contrary to their claims, tree expressions is not only applicable in defining DSL grammars but also helpful in DSL abstractions. Here, modeling (data) trees is exactly modeling (code) grammars. This makes LISP one of the most effective DSL environments.

Besides an individual DSL grammar tree, the inheritance and hierarchies are also applicable and significant in DSL grammar abstraction and reuse. A desirable DSL environment should not force all DSLs to be defined from scratch (including copy-paste) but support extending grammars/schemas by inheritance (and therefore grammar hierarchies) and semantic overriding (change the semantics of a syntax in the child grammar). Pocomatic is going to release an open source DSL/DSM framework that supports this inheritance as well as containment based schema extending and reuse. The product is going to be shipped with dozen or so DSL/DSM examples (also in open sources). These DSLs/DSMs are extended (using inheritance or containment) either from the core (root) schema or from other extended schemas and therefore present a DSL grammar hierarchy tree.

Re: disappointing by Ron Kersic

Joost,

Version 4.2 of openArchitectureWare has just been released and its documentation set includes a great bunch of videos that should help you get up to speed as possible. Personally, I found oAW much, much easier in getting some actual stuff done than with Software Factories or GMF (or with AndroMDA for that matter).

\Ron

Re: LOPped by Peter Bell

Intentional are shipping a community technology preview in the fall I believe.

JetBrains MPS is DOA.

Microsofts Software Factories are fundamentally flawed (they don't even support iteration in their gen to "create one DAO per business object" or similar which is a baseline requirement - there is a work around, but it is messy. I'm looking forward to 2.0.

Anyone serious about LOP should also check out MetaEdit+ by MetaCase - they have a very smart team and an interesting system.

For anyone into all this, also check out the Code Generation conference in the UK (www.codegeneration.net/conference/index.php) as well as SPLA and Models.