The basic idea is that you create data structures (objects) for all of the nouns and functions for all of the verbs that get used in conversations about the problem domain. Then you can map the user’s actual conversations directly back to the code. If you get the users to talk enough, you’ll get a complete system (plus a few lovely inconsistencies, previously unknown to the user).

The closer you come to matching their terminology with your primitives, the better it works.

In this way, you can create a DSL at the conceptual level while living within the capabilities and syntax of your favorite language infrastructure (syntax and compiling are just technical problems, not domain ones).

To me, the word “Language” is too specific. The distinction seems irrelevant to me, and others. In fact, many DSLs seem to be drawing/design abstractions (UML, GraphViz, etc).

I would redefine a DSL as being a re-usable abstraction of a problem domain that is technology and vendor agnostic. In addition, I expect that in order to be useful it should offer (at least) an order of magnitude benefit.

The general belief is that by creating a DSL to remove the technical problems you’ve also restricted the technology down to such a degree that it can only solve a very limited subset of problems.

Exactly, but my feeling is that there are several such subsets of problems that would benefit a lot of people. So creating DSL:s for them would make sense. I’m not talking about one, silver bullet language that would solve all our problems, but several, domain-specific languages that are abstract in terms of technology.
Of course, creating a new language is lot of work, and I guess that is the main reason we don’t see many of them around.

The thing that I’m pretty sure stops us from maximizing productivity at every level is that we keep churning through our technology. The story that comes to mind is how at first, every computer system had its operating system rewritten from scratch in assembly code. Eventually, C became the standard systems language and the operating system problem was, for the most part, solved.

That in turn helped prompt an era of increasing complexity in many different application realms. To name some prominent ones, we’ve gone through GUI platforms, Internet and Web standardization, relational database systems…

And at each turn we get new languages that aim to ease each domain of problems.

The problem with new languages is that you encounter problems reusing code. Everything has a hook to C nowadays, but C makes for a poor operational baseline; if you want to access it, you have to port the bindings to your chosen higher-level language. C doesn’t have enough features to map itself easily, and C++ suffers even more since its own higher-level constructs only cause even more of a headache in the binding process.

So right now what I see is a competition going on for a higher-level-language standardization of virtual machines. Java and .Net/CLR are the obvious commercial ones, but there’s also a lot of action from other areas - ECMAScript has been hailed a few times as a platform that other languages can build on top of, but that one remains to be seen. And there are all sorts of promising open-source VMs floating around like LLVM, Parrot, and Neko to speak of a few.

Regardless of which platform comes out on top, the result will allow a new era of computing in which we can use appropriate languages for each situation and they’ll all work in an easily compatible way.

I buy into this to some degree, after all 4gls and product/languages like Power Builder have consistently failed to hold market share, but I tend to think that the problem is coming from our abstractions. In most of the cases I’ve seen, the abstractions have really come from trying to compress functionality into smaller syntax. The paradigm is essentially the same.

I suspect that that is at least one perspective shift out there, that as an abstraction could lead to a significant simplification of our technological foundations. In general Brooks is right, but our current abstractions for building software are so crude that we should be able to do better.

But then again, I could just be crazy