I read this article on Language-Oriented Programming. He points out some weaknesses in the modern procedural/OOP approaches to programming, and suggests a new programming paradigm that will solve them

I am all for small, loosely coupled program parts: It is much better to learn a lot of small things, all of which you will use, than a couple of big things, that you only use bits and pieces of.

Reading the article, I got the impression that the author was promoting one of two things:

  • A multitude of easily creatable scripting languages
  • A single, easily extensible language that can rewrite itself to meet the programmer's needs

If he is suggesting the second, I would reply with "Already been done!" and give Lisp as an example. As Paul Graham suggests, languages seem to be continually moving toward this anyway.

As far as the first is concerned, I think this is a good idea, if there is an underlying language that ties them all together. That seems to me to be the weak spot: communication between the languages. Would you use calls, which is a procedural concept or message-passing, which reminds me of interprocess communication? I would welcome the opportunity to work with small domain specific languages, if it's easy to use them all at the same time. Would this approach (LOP) be practical?

  • It sure has a huge mind blowing potential.
    – user7043
    Feb 7, 2011 at 15:57
  • 2
    It is not clear to me what problem this paradigm solves. By the way, LISP is not an example of a successful language.
    – mouviciel
    Feb 7, 2011 at 16:01
  • 7
    @mouviciel it depends a whole lot on what exactly you mean by "successful". Is it used by the majority of programmers? No. Has it been around, in use, a long time? Yes - 50 years and counting. Have most modern languages stolen a whole pile of useful features from it? Yes. (Can languages steal even more from the Lisp languages? Yes!) Feb 7, 2011 at 16:33
  • 2
    There is a difference between a widely used language and a useful one. A language that explores new areas is generally not used, but may contribute to all in the long term. On the other hand, Java is useless, since it doesn't bring anything new to the table (even though it's definitely a successful language by all accounts). Feb 7, 2011 at 20:27
  • 1
    I would find it more useful to master Lisp than to master Cobol.
    – glenatron
    Feb 7, 2011 at 22:35

5 Answers 5


I've been advocating DSLs for a long time, but I worry about what happens to Good Ideas when they become bandwagons. Products get built that advertise The Good Idea, promising all you have to do is get one, and you'll be in the in-group, without having to think very carefully about what it means.

What is a language? It's a vocabulary and syntax in which meanings can be communicated, right? Every time you declare a variable, write a function, define a class, you are building a new language, by adding nouns and verbs to an existing language. Now you can say things in it that you couldn't before.

I think what makes a language Domain Specific is the extent to which it naturally expresses the mental concepts that are being communicated, and I think there's a simple measure of that. Basically, if there is a simple independent stand-alone requirement X, that could be included in the program or not, its correct implementation requires some set of code insertions, deletions, and replacements Y. A simple before-and-after diff can display Y. The number N of such changes is a measure of how domain-specific the language is. The smaller N is, for typical requirements, the better.

It doesn't necessarily depend on fancy syntax, control structures, message-passing, or what have you. What it depends on is how concisely it implements the requirement. Many tools will claim to do this, but claims are not actuality. It has to be real.

Sometimes an unusual technology is necessary. Here's my favorite example. When it is, it illustrates the point that it may require effort on the part of programmers to understand it. So domain-specificity (and maintainability) is not at all the same thing as readability.

So I agree with the second approach, that a good language is one that easily lets one build the necessary languages on top of it. (That's what I liked about Lisp.) But even more important is programmers need to know how to build languages to match the domains they are working in, and be willing to climb the learning curves of such languages.

I don't really see that happening. Instead they are stuck in the "programs = algorithms + data structure", or "nouns become classes and verbs become methods" turn-the-crank modes of thinking. They are not working in terms of how to take thought domains and linguify them for maximum concision.

  • Definately agree with you on the bandwagon part - "the pointy-haired boss know what language it should be written in. [...] Java." Another issue is what Joel terms the "architecture astronaut". I could also see DSLs stacking on each other ad infitium (sp?). I guess it comes down to programmer -> software engineer -> computer scientist.
    – Michael K
    Feb 24, 2011 at 15:48
  • And if it doesn't require effort to understand, chances are it's not really worth it :)
    – Michael K
    Feb 24, 2011 at 15:54

That's quite the Ruby approach.

  • Keep the core language simple and extend via gems
  • Create dialects of Ruby for specific domains via monkey patching. i.g Ruby on Rails.

I don't know if this is better, but I guess is very pragmatic.

  • 7
    RoR is not a dialect of Ruby.
    – back2dos
    Feb 7, 2011 at 16:59
  • 4
    @back2dos: I was thinking in metaprogramming. Of course RoR is not a different programming language. What I mean by dialect is that even if everything underneath Rails is Ruby, from the developer point of view he is using Ruby at a higher level of abstraction. A domain. A dialect. He using views, models, controllers and he is programming them using a syntax that resembles a different language, a dialect so to speak. That's the beauty of an scripted language so powerful as Ruby.
    – Nerian
    Feb 7, 2011 at 18:34
  • I think it is important to really see the difference. AspectJ is a dialect of Java, whereas AspectR is just a Ruby library. The difference is really the language. Ruby was designed to provide that flexibility and expressiveness and Java wasn't. Both can be considered general purpose languages, the difference is, that Ruby is generally expressive enough to eliminate the need of an actual DSL for any general purpose, while Java isn't, even though for example you commonly use views, models and controllers.
    – back2dos
    Feb 7, 2011 at 21:45

LOP approach is extremely practical. Keep in mind that you don't necessarily have to implement "scripting languages" - the methodology is applicable to eDSLs as well, and they're typically efficiently compiled. I am using this approach in literally all of my development work.

  • Pardon my ignorance - an eDSL could be a preprocessor for anther language, right?
    – Michael K
    Feb 7, 2011 at 16:50
  • @Michael, yes, it is possible to implement eDSL this way, see CamlP4 for example. But more often eDSL is built upon language's own features (e.g., Lisp macros, C++ templates, etc.).
    – SK-logic
    Feb 7, 2011 at 17:09

We will be seeing a lot more about Domain Specific Languages in future, judging by the people who are talking about them now- I've noticed Martin Fowler talking about them a lot too and a few interesting articles through Lambda The Ultimate on the topic, among others.

That suggests to me that this is definitely a direction in which the wind is blowing with regard to programming language design and programming platforms. In some ways it has been for a while already - one of the advantages of Ruby ( as some one already observed ) is that it makes it easy to create DSLs but actually there are loads of them around in applications and programming libraries we already use.

  • You can add in FoF with is being used to develop Drivers for the Barrelfish multi-kernel. A language to develop DSLs in :) Feb 7, 2011 at 20:23

I am using LOP whenever programming solo. I found that in some projects, there is no other way to meet the schedule. In a simple allegory, one can equate use of LOP to power tools. If you are working alone in the workshop, you can't do things manually and meet the deadline. If there are other people with you, coordinating use of those power tools is essential for efficiency and safety.
In team mode, LOP requires organizational preparation to avoid a Tower of Babel disaster.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.