Dave Thomas says, "I prefer to code declaratively, because at the business level we're not executing a series of instructions. We're dealing with data. The longer I can keep my code at the data level, the closer I'm coding to the application domain."

Read this Artima.com interview with Pragmatic Programmers Dave Thomas and Andy Hunt:

http://www.artima.com/intv/domain.html

Here's another excerpt:

Andy Hunt: One reason programming hard in general is that you have to zoom in and out to different levels of detail. You might be groveling around in low-level bits and pointer arithmetic, then zoom out to an abstraction that's close to the business domain. You're always bopping back and forth. That's hard. It's much easier if the user gives you business rules in their domain language. It's easier if you don't have to map the business rules down to very low levels, like a compiler would do. Dave and I are big on using automation. That's why the computer is there. I am very against any technology that requires me to act like a compiler. If I can do a task with a couple of macros that match what the user is saying, as Dave suggested, hey that's a win. Let the compiler take it to the next step. Don't make me do that. Allowing me to stay at a high level is to me the real big advantage of domain languages.

Dave Thomas: But there is a danger of going too far. With some technologies, in particular C++ templates, people sometimes go too far the other way. They try and think of clever ways of using templates to generate compile-time behaviors. Yes, you can do it. Yes, you get real good geek points for doing it. But you end up with totally unmaintainable applications. You've got to be very careful to keep that balance in mind.

What do you think of the Pragmatic Programmers' advice on domain languages?

Yes. Both scripting languages like Ruby or Python and system programming languages like Java or C++ have plenty of features that can be used just fine to cook up domain-specific mini-languages without any need to build a translator - the standard compiler or interpreter can readily be used. I think this idea deserves to be much more widely known and teached.

These days there is much praise for XML-based configuration mechanisms. Standard XML tools and libraries make parsing simple, but IMHO re-using an established programming language's syntax and implementation instead is often the superior approach: First (at least with languages like Python or Ruby having concise syntax with little "clutter", and with creative use of the base language's features), the notation can be made more human-readable/writable. Second, the reuse effect extends far beyound the parser stage - somebody wants if/then/else in the mini-language? Fine, the construct is readily supported both on the syntactic and semantic level by the compiler or interpreter already used. Loops? Procedures? No problem. Depending on the base language, goodies like high-level collection datatypes or lambda abstraction can be offered at no cost as well. I wouldn't want to implement these things in a "homebrew" language/compiler, and if I did, let's rather not compare the quality of the result with the established implementations of Python, Ruby, C++ or Java.

This is not to say XML config files are a flawed concept altogether. If the context is such that XML's strength on interoperability is really needed and used, this is the way to go. But whenever there is a remote chance that what is conceived as a mini-language now will undergo substantial evolution later on and will approach Turing completeness one day, my suggestion is to consider using an established programming language from day one.

100% agree with the idea of domain languages.

For people interesting in looking at the concept of domain languages without develop an outside language I would suggest to check Prolog, for 2 reasons:

1. Typical approach of programs are data and data are programs that you find on eg lisp
2. The ability to change the parser of the Prolog interpreter and define new operators.

Let me give you an example base on a production system:
Case:
Data: Database of persons.
Todo: CGI returning names of all the female persons put on an html table.


title 'Female persons'.
(name=X)/person{sex='F'} ==> html_table(['Name'], [X]).


Or with an url to see more info


title 'Female persons'.
(name=X,code=Y)/person{sex='F'} ==> html_table(['Name', 'More info'], [X, a href Y : X]).


All the operators are defined by the programmer, so you can replace eg ==> for something more meaningful.

The point is: its difficult to make it small and easy. How much lines would this take on <insert your favourite general purpose language here>? No think on the productivity boost.

The feeling that staying close to the domain is better is one of the main ideas of model driven development.

If you don't want to go that far, you might want
to check out www.nakedobjects.org for a radically different
view on how OO-development stays simple and intuitive.

Cheers,
Jochen