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?
Best Answer
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.