Is Language-Oriented Programming practical?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.