Lambda the Ultimate

Agreed, but IMHO the real issue is *how fast you grow* your DSL. It's unrealistic to think that a DSL ideally adapted to a specific domain can be designed on a first pass. It might be better to stick with a General Purpose Language + Domain Specific Library for awhile until some experience in dealing with the particular domain has been accumulated.

Hypothesis: DSL's are best grown by internalizing commonly found design patterns into the language.

Concise semantics and syntax are substituted for the verbose steps necessary to achieve some domain specific task in a General Purpose Language like C++ or Java with a library.

The trick is to discover the algorithmic patterns unique to a specific domain and build these into the language and this takes time particularly when the domain is highly proprietary and hidden. Open source trails of other programmers' attempts to master the algorithimic patterns of specific domains helps.

Take for instance *graph editors*, a class of gui programs that allows one to specify sets of nodes and vertices and their connectivity.

This is a set of gui idioms shared by programs as diverse as the Rational Rose UML editor, free graph editors for graph theory in mathematics, Microsoft's Visio or Autocad's Actrix diagramming tools, and libraries for building diagrams in TeX.

An early DSL for graph editors was Graphscript for the Graphlet editor. If suffers from using a very non-standard Tcl/Tk.

The java interfaces for the VGJ graph editor would be a good place to begin a graph editor DSL.

The algorithmic patterns found in graph editors provide an good source of examples for advanced GUI progamming of the sort found in Petzold's Programming Microsoft Windows with C#.

That's what I did recently when I used GDI+ to do the "Graph node as expandable text box" pattern found in the Graphlet editor above.

The trick is to discover the algorithmic patterns unique to a specific domain and build these into the language

Right. And this is hard even when the domain is well known, and there's nothing proprietary involved.

A student of mine is thinking about a DSL for searching the web (I think of it as a super-google API ). What are the algorithmic patterns?

> Agreed, but IMHO the real issue is *how fast you grow* your DSL. > It's unrealistic to think that a DSL ideally adapted to a specific > domain can be designed on a first pass. It might be better to stick > with a General Purpose Language + Domain Specific Library for awhile > until some experience in dealing with the particular domain has been > accumulated.

> Hypothesis: DSL's are best grown by internalizing commonly found > design patterns into the language.

Jon, since you 'fessed up to trolling in another thread, I suppose this remark was intended to drag a Lisp bigot, such as myself, out of hiding. Well you're in luck!

I'm in broad agreement with the above statements and would like to rant a bit about patterns, macros and Lisp. Patterns indicate a flaw in languages. Specifically the inability to turn patterns into idioms. Guy Steele presented a very nice pattern on ll1-discuss:

------------

Hm. There's a very interesting pattern, the "if-then-else" pattern, that has been used for a long time but got raised in people's consciousnesses as an important pattern only with the advent of Structured Programming and its thesis that all control structure in a procedure could (should?) be expressed in terms of sequencing, if-then-else, and while-do iteration.

The gist of the pattern is:

You want to do one of two things S and T depending on the value of some boolean predicate P.

Code pattern: evaluate P branch if not(P) to L execute S branch unconditionally to E L: execute T E:

Now, should we say that this pattern is more useful precisely because it is not wedded to particular language hacks such as Scheme's "(IF P S T)" or C's "if (P) S else T" or "P?S:T" ? On the contrary. It is good to know the pattern in case you need to use a low-level language (every compiler writer knows this pattern and several related ones), but it is also good to have this extremely commonly used pattern packaged up as an idiom in most programming languages. The fact that different languages express it in syntactically different ways makes it no less useful.

http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01629.html

------------

So languages have grown by turning patterns into idioms. They just don't do it fast enough. If they did we wouldn't need patterns!

Ideally we'd want a language that allows itself to be extended into a DSL. This saves the cost of reimplementing the runtime and so reduces the barrier to entry for a DSL. It also allows more organic growth - you don't need to design the DSL, just grow it naturally out of the domain-specific libraries and patterns of interaction with those libraries. This all comes around to extensible syntax, i.e. macros, which in turn comes around to Lisp (though there are decent macro languages available for other languages such as Java).