Domain Specific Languages Parade

DSLs are all the rage recently with Martin Fowler and a whole bunch of folks blogging about them. It seems the Lispers are a little annoyed about the noise and rightfully so. They have proclaimed the virtues of DSLs for many years. In fact, Paul Graham's essays are littered with references to how DSLs solved his business problems. Smalltalkers have also long talked about the virtue of DSLs. So, why all of the rage? I think a lot of dynamic language ideas are finally seeing the light of day via the scripting crowd.

It's a good thing since I believe DSLs are a by-product of good design. You have a DSL when you speak in the terms of the domain in your code. This might seem obvious, but I see procedural-like code that stays at the level of the general-purpose language too much. I know I have magic in my designs when a business user can read my code and understand it. It's the goal that Eric Evans talks about in his excellent, "Domain Driven Design" book. He speaks of a ubitiquous language that is shared by business and technical folks on the project.

The good thing about the current parade is the number of good ideas that adds to my arsenal to attack a problem. Rainer Joswig had an excellent blog entry discussing how Lispers go about doing a DSL for RFC specifications. Where I would break down the problem in objects and messages, the Lispers take a different strategy with macros to achieve the same result. I would love to work on a Lisp project just to get into their minds.

Everytime an old idea comes back, there are some new twists. I find the current reprise of metadata usage in DSLs interesting. Again, metadata is nothing new, but the approach seems to be new to developers in the static camp. The model driven approach takes this route as well. But, MDA seems too much like CASE tools part two. Martin Fowler's article does an excellent job of showing the pros and cons of the DSL approach and its different paths.

I've been thinking about language issues since I had my talk with Colin and Eric. Both of them, gave me a plethora of thoughts to chew on. Making DSLs easier for developers seemed to be the meat of the discussion. How do we make it better? Can we make general purpose languages that are more tuned to DSLs? Much like we make the separation between virtual machine and our code. The boundary is distinct. I think a mixture of metadata and DSL facilities built-in to a language would be a win. It would be nice to express the domain in terms of a DSL and then use metadata to wire persistence, GUIs, and rules. In other words, the low-level programmer details would be handled at a metadata level (think Glorp and rule engines), but the domain expressed in terms of the business and only the business. Any dynamic language can provide this functionality easily, but is there anything we can do to make it even more transparent? I want to play more with prototypes ala Self because I think there is a richness to explore. DSLs feel like they would be easier in Self especially with dynamic delegation and traits. I believe that we should treat languages like organisms. We are all comprised of cells which are comprised of other parts and so forth. I think programs can be built the same way. You have a simple core in which higher level blocks are comprised of and then, bigger blocks are built out of those. When you get to the top, you see a complete being. It's a recursive russian doll basically. Each level would be higher DSL. Thus, the top level would be the business domain language. Think of it in terms of the virtual machine code. Do you ever see it or care when you are at the top level? No. You build your system out of the language on top. Same concept, but we need to take it to higher levels. This is a huge subject. I plan on blogging more in the future about this subject. I want to take Smalltalk to the next level. I'm tired of solving the same problems.