A DSL (domain-specific language) is a language designed for a business or industry domain such as health care, finance, or insurance. It defines processing in terms of the nouns and verbs of your business rather than in terms of a pure computer language.
In most cases, domain-specific languages look like stripped-down versions of English that incorporate business jargon. DSLs are especially powerful when used with a rules engine -- and most rules engines support some kind of DSL system.
[ Also on InfoWorld: Andrew Oliver embraces the programming language explosion. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
The following is an example of a DSL used with Drools, a popular Java-based rules engine:
rule "CheeseType"
when
Cheese is of type "stilton"
then
DoSomething
End
Compare this to the equivalent Java syntax:
if (cheese.getType().equals(Cheese.TYPE_STILTON)) {
doSomething()
}
A key advantage to this type of DSL is that business analysts who speak the jargon of the business, but who are not necessarily programmers, can write business rules on their own. On the other hand, programmers who need to know a lot about the business (but who are not necessarily qualified to determine business rules) can focus on the overall system.
Laying the groundwork for DSLs
DSLs disrupt the conventional software development workflow: A subject matter expert (SME) describes a business concept to a developer, who may not fully understand it, but who then implements it in a language the SME can't read. With DSLs, the developer works with SMEs to define a language specification; the SME then describes the business rules in the new language.
When you compare the two methods of development, the DSL-oriented one looks pretty good. Plus, having your business rules described in a DSL decouples them from the code, so new team members don't have to search thousands of lines of code to find the rules.
Why aren't DSLs in wider use? One reason: To achieve successful results, you need competent business analysts. This may sound harsh, but I've met maybe five of those in my entire career. Most of the business analysts I've met have been PowerPoint artists who couldn't quite make it as marketing people.
More to the point, defining a DSL requires lot of up-front work and planning. It brings to mind a rarely heeded Spanish proverb that Marc Fleury once admonished me with: "Slow down, I'm in a hurry." Yes, DSLs can result in more maintainable, robust, and cleaner software, but only if you're willing to spend the time thinking them through.
Putting DSLs to work
Several options are available for those who want to create DSLs. Drools is my personal favorite. It's a rules engine, it supports DSLs, and it features Guvnor, which allows you to organize the rules into manageable packages. But beware -- Drools is hardly a lightweight tool; it isn't even a single tool. It's a collection of tools that offers many features that have nothing to do with either rules engines or DSLs.
But there are many other approaches. For Microsoft's .Net platform, Irony offers a means of creating DSLs using a specialized expression grammar.
For Groovy fans, there's easyb. I like the lightweight simplicity, although it lacks the performance optimizations and tooling of Drools. It also leaves you with a bunch of Javaisms, like brackets ({}). I prefer using a language a bit more structured than plain English but that looks like plain English to the greatest degree possible. There are other resources and even an entire book on how to create DSLs for Groovy.
Ruby has a number of plug-ins, including Machinist and Cucumber, plus several great tutorials on the Web. The process of using a dynamic language like Ruby to create a DSL is somewhat different than using a rules engine like Drools or a pseudo-compiler kit like Irony. Ultimately, it's just as powerful.
Typically, SMEs are far removed from business logic. DSLs close that gap by allowing your business logic to be expressed in the language of the business by SMEs themselves. Yes, the scarcity of skilled business analysts is a problem, but if you're lucky enough to snag a few of them and you invest enough time and effort into developing DSLs, you may discover that using a domain-specific language to express your business logic makes a whole lot more sense than encoding it in a general-purpose language.
This article, "Programming languages even a business analyst can use," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.