commentary on The Problem Is Choice

The Problem Is Choice considers how choice, or change, makes a DSL inappropriate for many situations. Each section starts with an apt quote from the Architect's scene in Matrix Reloaded (underrated movie, in my opinion, but then I'm probably the kind of pseudo-intellectual weenie the movie was meant for).

It's always seemed to me that, most of the time, modeling a specific problem with a DSL, then using the DSL to solve it, was looking at the whole thing backwards. The problem may be easy inside the DSL, but if you had to implement the DSL first, have you actually saved any labor? This is much less of an issue if you implement the DSL in a programming language that makes it easy (Lisp being the usual example). I think DSLs are more for reusing code to solve a group of very similar problems. For instance, a DSL seems to work well as part of a "framework" that regular, general programs can call into for particular purposes. Consider HTML templating languages, or Ant, which is the exact example that defmacro uses to illustrate to Java programmers the utility of a DSL.

Any program has to model its problem domain in order to solve it, because the problem domain has information which must map onto computer data. This is the ultimate "impedance mismatch", you might say--the necessity of translating an algorithm which is both theroretically and practically computable into an equivalent algorithm, for a Turing Machine, but expressed in your language of choice. In some problem domains a DSL may work well as a model, but according to this blog entry, apparently many problem domains evolve in too messy a fashion to fit into a formal grammar without repeatedly breaking it, requiring new constructs, etc. As the AI guys have discovered, not even human languages are a good fit for DSL modeling.

All this talk about modeling is not the real point, because no matter how a program models the problem domain, it should not mimic the domain too much. Remeber the Flyweight pattern. Code entities should match the problem domain just enough to enable effective, realistic processing with true separation of concerns. As The Problem of Choice says, the effectiveness of a programming language is not how well it can model a problem. I would say that the important criterion is how well it can flexibly but simply reuse/modularize code when achieving that model, whether with a DSL, a set of objects, or the higher-order manipulation of functions. Other languages, or even mini-languages like SQL, may not have as much of this Power, but that may be on purpose. (And no business logic in your stored procedures, buster!).