There was an interesting question posed by one of the participants about the opposing forces the speaker had to deal with while zeroing on the need to create a custom language instead of using an off-the-shelf rule language. From the discussion it became evident that the decision was driven primarily due to the unavailability of off-the-shelf rule engines in the implementation language domain. A justifiable reason, but I hoped for the speaker to shine some light on the forces surrounding the need to incorporate DSLs, in general.

I have been experimenting with DSLs for some time now. From my sphere of experience, DSLs have proven quite useful from an end user's perspective for complicated configuration needs. For higher order logic externalization, rule engines are almost always a better fit, evaluating the implementation complexity, knowledge curve and proprietariness of the solution.

One of my engagements dealt with service orchestration at a micro level. Services were quantum of activities written as pluggable classes, which could be declaratively wired into an orchestration structure as shown on the image on the left. Initially we started off with the idea of specifying the branching configuration via XML files, but soon realized that from a end user's perspective it became way too convoluted to manage the configurations. A much more intuitive mechanism was required to specify the configuration. The expression on the bottom of the image was found to be most suited for expressing such a branching structure. This form of configuration was much more comprehensible from it's XML equivalent.

The following BNF grammar was developed to implement the custom configuration language:

1.  expression = expr "," expr | expr
2.  expr       = term "|" term  | term
3.  term       = "(" expression ")" ["*"] | IDENTIFIER ["*"]

These are some brilliant articles by Martin Fowler on DSL.
Language Workbench - killer apps for DSL?
Domain Specific Languages