Edwin has this post on How to write a Program in 2 Steps . He suggests the following 2 simple steps to write a business program.

1. Design and implement the programming language which would be best for solving the problem.
2. Write the program in the language you’ve just implemented.

Now, that is a suggestion that will certainly fit for very specialized and unique class of problems like this one and this one.

But, as I have said before, I believe using Business Rules Engines is a better way to attack the problem for general business problems.

In a related vein, I have recently seen arguments posed by other developers for using a Dependency Injection driven framework for managing rules, as against using a Rules Engine, and I had posted my response to the argument here. Some other bloggers including Charles Young and Johann Lindberg have also written their responses on that subject.

Now, coming back to the DSL problem, here are the advantages of a DSL

1. Simple declarative rules
2. Domain specific terminology in rules
3. Uncomplicated rule engine

Now, if you see these same advantages are available with a rule engine set up also. Now, who says rules cannot be written without an underlying object model? I am saying you can. If you are on the java or the .NET platform, rule engines provide a compelling choice.

My final recommendation

1. Use a DSL to solve a very specific unique problem
2. Use a DSL to solve problems with no or little inferencing required
3. Use a Rule Engine to solve general class of business problems (Terminology , thanks to Jay Fields)
4. Build a custom rule authoring interface for writing rules using the rule model API’s of the Rule Engine.
5. Use a Rule Engine when Rule Management is essential (Business Rules Management)