In his weblog entry, Keywords, Magic and (E)DSLs, Keith Braithwaite writes, "There is no mechanism available to the Smalltalk programmer to create programs other than the creation of EDSLs (Embedded Domain Specific Languages)."

He gives an example of how you might make an embedded DSL on Smalltalk, and suggests that the reason Smalltalk (and Lisp) makes the creation of DSLs so easy is that the language provides a very small core that everything else is built on, and contrasts this with Java.

Building DSLs is the bread and butter of Smalltalk (and Lisp) programming, but is a bit of a struggle in the Java (and similar) worlds. The big vendors are attempting to fix this through the use of mighty tools in the interests of supporting a new-but-old-but-new model of development, a rather fishy proposition at best.

This is symptomatic of one way in which the industry has decayed. The message of Smalltalk (and Lisp) is that the route to productivity is to use simple tools with few features and allow everyone interested to build upon them. The favoured route at the moment is to encode every good idea into an all-singing all-dancing "solution", take it or leave it.

I believe that DSLs allow you to raise the level of abstraction to match your particular domain, enabling you to program with clarity and a minimum of keystrokes. Having spent most of my career in C, C++, then Java, the way I've always created DSLs is by defining grammars and code generators with the help of a parser generator such as Yacc/Lex, JavaCC, or ANTLR. The ability to twist the general programming language itself into a DSL was something I've also heard claimed as a strength of Ruby, and this approach to DSLs was described in the article, Creating DSLs with Ruby. This article attempts to describe the tradeoffs of these two approaches to DSLs:

A DSL, or domain specific language, is a (usually small) programming or description language designed for a fairly narrow purpose. In contrast to general-purpose languages designed to handle arbitrary computational tasks, DSLs are specific to particular domains. You can create a DSL in two basic ways:

1. Invent a DSL syntax from scratch, and build an interpreter or compiler.
2. Tailor an existing general-purpose language by adding or changing methods, operators, and default actions.

An advantage to the second approach is that you save time because you don't have to write and debug a new language, leaving you more time to focus on the problem confronting the end-user. Among the disadvantages is that the DSL will be constrained by the syntax and the capabilities of the underlying general-purpose language. Furthermore, building on another language often means that the full power of the base language is available to the end-user, which may be a plus or minus depending on the circumstances.

I think an important path to productivity is to raise the level of abstraction of your program to match the specific problem domain you are working on. For example, we had a requirement for versioned data, and devised a way to version data that we wanted to use consistently everywhere in our application where versioned data was called for. We created a DSL in which we describe our entities, and can make an entity versioned by the addition of one keyword: versioned. I have not had the experience of creating an embedded DSL, but I'm curious to what extent the ability to raise the level of abstraction while still working in the general purpose programming language is the source of productivity in languages such as Ruby and Smalltalk, as Keith Braithwaite suggests in his weblog. If you've had such an experience, please describe it in the forum discussion for this post (link below).

aDoor isAlarmed ifTrue: [self disarm: aDoor] ifFalse: [self openNormally: aDoor].

if(condition, {doOneThing();}, {doAnotherThing();});

// Let's imagine ObjectJava has anonymous functions
   ifTrueIfFalse(
      door.isAlarmed(),
      ()=>{ janitor.disarm(door); },
      ()=>{ janitor.openNormally(door); }
   );

// Let's imagine ObjectJava is OO
   door.isAlarmed().ifTrueIfFalse(      
      ()=>{ janitor.disarm(door); },
      ()=>{ janitor.openNormally(door); }
   );

// Let's imagine ObjectJava has optional named parameters
   door.isAlarmed().test(      
      ifTrue: ()=>{ janitor.disarm(door); },
      ifFalse: ()=>{ janitor.openNormally(door); }
   );

// Let's imagine ObjectJava has sugar for void->void parameters
   door.isAlarmed().test(      
      ifTrue: { janitor.disarm(door); },
      ifFalse: { janitor.openNormally(door); }
   );


void test(boolean condition, void->void ifTrue, void->void ifFalse)
   { if (condition){ ifTrue(); } else { ifFalse(); } }

interface Reflection
{
   Set properties();
   Class getType(String propertyName);
   Object getValue(String propertyName);
   void setValue(String proprertyName, Object value);
}