I would like some practical guidance on when I should use a Domain Specific Language. I have found resources about advantages and disadvantages, but what kind of project would warrant its use?

It seems like there is a big investment in time to create and maintain a DSL, so in what application space would I get a productivity return on my time investment?

Edit: It seems the most common use of DSL is for file formats for persisting data state, what about using a DSL for program logic and structure(perhaps code generation)? When is this feasible?

Edit #2 I am mainly asking about when is creating a specific DSL worthwhile. Of course we should use existing DSLs as much as possible to save time.

• project-management
• dsl

There are very few good reasons for creating yet another DSL. The world is fat with special-purpose languages.

Think along with these lines.

1. Solve the problem with a general-purpose language such as Python, Java, C++.. whatever.

2. Optimize that solution to factor out the common features and build a really nice, really elegant, really extensible class library.

3. Optimize that class library to emphasize "orthogonality". Make sure all features work well together, without any problems.

4. If you need simplification of the syntax only, create a scripting wrapper around your nice class library. This is your DSL. For Python, this is easy -- it's already a dynamic language. For Java, there are things you can leverage. For C++ it can be a bit of work to build this flexible scripting environment.

5. If you still need further optimization, consider writing a compiler for your DSL.

The ACM Computing Surveys article When and How to Develop Domain-Specific Languages provides advice on just this topic, as does Martin Fowler's 2010 book Domain-Specific Languages.

Firstly, I would use a DSL when the problem domain your developing against is a widely well known domain, and some business experts of that domain have already went through great lengths to build such a DSL so that you wouldn't have to go through the lengths yourself to solve all the problems they have already figured out.

If you're thinking of creating a DSL, I would consider doing so if your business is done in a very particular area, and you spend the majority of your time focusing in a specific problem domain. If you bounce around doing applications for multiple problem domains, then I wouldn't advise taking that approach.

For example, if your business is soley in building tax applications, it might be a good idea to build a tax system DSL. This would allow your language not only to be useable by you in your various tax applications, but it would also be marketeable (useable) by other businesses in your industry that want to do similar things that you're accomplishing.

Of course, you have to weight the costs/benefits of building a DSL vs a framework on top of an already existing language.

One situation that comes to mind is when the requirements requires a very high or improbable level of customization/configuration. So you would provide a kind of scripting model against a DSL instead.

Takes a car assembly "arm" for example, providing a configuration model to support various factory configurations would be impossible. (detect this, don't detect that, when this happens do this ... etc.)

But compiling a new application with specialized logic for each customer is probably not a good way to go. So in this case, you create a little framework that would becomes a kind of DSL, and then for each robotic arm you sells, you write a little app in your DSL and save it along with the core software that would compiles and runs your DSL scripts instead. Or better yet, tools to program the DSL are included along with the robotic arm so your customer can "program" the arm themselves in the DSL you created.

One real world examples that comes to mind is Yahoo Pipes (you could think of it as a DSL) or the robots.txt directive for automated web crawler for example. They may not be a full-blown DSL but they demonstrate where DSL might be useful.

Well, someone has to say it, so here goes:

Lisp is regarded by some as the domain specific language for any domain. A well-supported and very extensible DSL at that.

In some cases, fashioning a DSL from Lisp (or a similar language such as Haskell) could actually provide a lot of power with minimal effort, and thus would be quite worthwhile. DSLs do not always need to be big maintenance burdens.

The most obvious is you should definitely use them when the language already exists and is well-supported. The prime examples of this are UIL for Motif-based GUI development and make for software builds.

If you have to make your own, I'd say to look for domains a large amount of effort is in just specifying things properly, and where your compiler can't really find most errors, but a domain-specific compiler could. GUIs are a great example, as most of the work is in setting up the layout, and there are generally lots of ways to make syntacticly valid C++ calls that make no sense whatsoever to your underlying GUI system (EG: trying to embed an entire dialog widget inside a button).

I find UIL particularly a huge gain for GUI development because a UIL compiler can find errors in a GUI specification that just look like nice normal compilable code to a C++ compilter. The fact that it is well-supported means that the code is easy to port between platforms, and even GUI builders.