Domain Specific Languages - the real ones

People talk (and write) about Domain Specific Languages as if it is the way of the future. It is. But they do not understand why, and nor can they until they discard the term.

The idea is what is important. And this is the idea:

A componentized (re-usable) abstraction of some problem domain.

Nothing to do with languages, or scripting, or any such programmer-oriented way of thinking. The term "Domain Specific Language" (DSL for short) is soo 90's CASE tool thinking. Still, I'm gonna continue to use it in this blog entry, because I do not have a better term.

As with all advances in software development techniques, it is about increasing the level of abstraction. To my way of thinking, this blog is published using a DSL. I have never looked at any HTML or even CSS on this site. Someone else discovered a neat way to abstract the problem domain of Blog writing. They encapsulated their idea in a piece of software (Blogger.com if you're interested), and now I am 100-times more productive than I would have been if I used HTML.

(I made up that number of course. Its probably closer to infinity, because I would not write a blog at all if I had to use low-level tools).

So to my way of thinking, a true DSL increases the level of abstraction of a problem to the point where it is orders of magnitude easier to solve the instances of that problem.

While the buzz on DSLs is relatively high, the buzz on "frameworks" is low, to the point of being a dirty word for some people. I disagree. A framework is just a premature DSL. Someone's attempt to abstract some aspects of a problem domain.

This is what I am doing with my new website, PerfectAPI.com. I am building abstractions that I think will increase developer productivity by orders of magnitude. I'm betting that the abstractions I am creating are sufficiently mature that they will stand the test of time. Wish me luck.