I know JavaOne’s over now but there’s one talk that I attended that I haven’t yet got around to commenting on. It was entitled ‘Exploiting JRuby: Building Domain-Specific Languages for the Java Virtual Machine’ by Rob Harrop of Interface21. If you need some background on DSLs, I refer you to my coverage of another DSL presentation.
As well as being able to classify DSLs as ‘external’ or ‘internal’, Harrop introduced another distinction: ‘general-purpose’ or ‘business-specific’. ‘General-purpose’ DSLs are intended to address infrastructural concerns and are thus for use in a variety of business domains. These are the sorts of DSLs that I was talking about in my original blog – for example, Ruby’s Rake and XMLBuilder, or Groovy’s SwingBuilder.
‘Business-specific’ DSLs, on the other hand, are tailored to streamline and simplify the expression of business rules and concepts in a particular business domain. Harrop gave the example of a ‘corporate action’ that calculates entitlements to be issued to stockholders. To give us a feel of what a DSL might look like in this business domain, he gave the following example:
corporate_action :bonus_issue do |position, payout|
entitlement :stock => position.quantity * payout.rate
I’d be lying if I said I fully understood what he was talking about: as a relative newcomer to Ruby, it’s difficult enough for me to understand the mechanics of how this code works, let alone the business domain as well.
Almost by definition, business-specific DSLs such as this are only useful for describing complex business rules. If the rules weren’t complex, there wouldn’t be a need for a DSL. If you had a good grasp of the business domain, the code might read quite naturally. But it was a struggle for me.
When I came away from the talk I couldn’t help feeling that this usage of DSLs was perhaps a little more specialized than was being acknowledged, and that it might be a long time before the need would ever arise for me to use them in this manner.
Indeed, I see some potential parallels between the take-up of DSLs and the hype around aspect-oriented programming (AOP) a few years ago.
Let me explain: soon after the notion of AOP first became common, there was much talk about its application to business rules. Well, that was a while ago now. I personally haven’t written any business rules that use AOP and I don’t think I will be anytime soon. The only real-world application of AOP business rules that springs to mind is complex financial systems and I just don’t work in that area.
Don’t get me wrong: I think AOP is a useful idea; if anything for re-raising in our collective consciousness the concept of interceptors. However, I haven’t used it for anything more complex than basic method interception for infrastructural purposes – logging, transactions, security.
So just as I’ve used AOP for infrastructural concerns instead of business ones, I think it’s much more likely that I’ll be using general-purpose DSLs instead of business-specific ones. Furthermore, the only application of business-specific DSLs that immediately springs to mind is complex financial processing – just as it was for AOP.
I expect that there’s going to be a flurry of activity over the next year or so as every man and his dog sets out to write a general-purpose DSL. Consequently, I consider it unlikely that I’ll be writing one myself – although I do look forward to them making my life easier. And as for business-specific DSLs…whilst interesting, I consider it unlikely that I’ll have to use them very often…if ever.