DSLs Rehashed Again

by Mike Loukides

About a month ago, there was a flurry of blogs and articles on what is, and what isn't, a domain-specific language. I'm not sure who started it, but articles include Martin Fowler's, Nutrun's, and Jeremy Voorhis'. At the same time, I was having some interesting conversations about DSLs with Terence Parr, the author of ANTLR. So much for link-dropping.

I think there's a question that's more interesting than "what's the lower bound for a DSL" (essentially the question that Martin is asking), or "is Rails a DSL?" (the question that Jeremy and Nutrun are asking). What makes a working language? Well, there are lots of components, but basically, you have a vocabulary and a grammar. Ruby DSLs are structurally very similar: they define a lot of methods (often via metaprogramming); they typically don't define any new grammar, but use Ruby's relatively loose and flexible grammar. So what looks like a nice domain-specific language that requires minimal knowledge of a formal programming language is, in fact, just a bunch of method calls in a formal programming language. The method names are the vocabulary, and the grammar is Ruby. Jeremy calls this a "fluent interface" (and notes that it's often just good design).

Creating a really good fluent interface is a neat trick: it looks like you're getting a new language "for free" (almost). You could argue that these fluent interfaces aren't really DSLs--they're really just Ruby. But that's not a very useful or interesting argument. Here's a more interesting question, which I haven't seen discussed: what's the point at which it becomes necessary for a DSL to have a distinct grammar? (I don't think it was discussed at the DSL session at our FOO conference, which I missed). What's the point at which the control structures, etc., in Ruby (or whatever the parent language) are no longer sufficient or adequate for the domain? What's the point where you have to go beyond creating classes and metaprogramming, and generate your own parser with the venerable YACC, or a successor like ANTLR?

After all, it doesn't matter whether you call it Ruby or Java or Python; most programming languages have fairly similar control structures (if/else, for, while, unless), and in most OO languages, the class system is fairly similar. That works well for computing--but what about other domains? When does the grammar of a traditional programming language, even one as flexible as Ruby, become inadequate?

Whether or not Rails is a DSL, it's not terribly surprising that it doesn't require any new grammar. There's certainly an impedance mismatch between OO languages and relational databases, but it's not a huge one: Web interfaces, OO languages, and RDBMSs are all things designed by us computer folk, and they're more similar than different. Could you use a language like Ruby to model business strategies, musical compositions, and other domains where the impedance mismatch is greater? Or would you need a different grammar entirely?

3 Comments

Daniel Berger
2006-08-30 12:47:29
"What's the point where you have to go beyond creating classes and metaprogramming, and generate your own parser..."


My simple reaction consists of two possible responses. First, when regular expressions become impractical. Case in point: rdoc. It's a mess. It's hard to maintain and test, let alone read. A parser would be easier to read, write, and maintain I suspect. In addition, a grammar gives you an official spec from which you can then base your documentation.


Second, when the limitations of the language get in your way, such as defining a '++' method, or overloading 'if'.


There's my off the cuff reaction. I'm not sure if you were looking for something deeper, but there you have it.


- Dan


2006-08-31 16:47:30
Could you use a language like Ruby to model business strategies, musical compositions, and other domains where the impedance mismatch is greater? Or would you need a different grammar entirely?


I find that grammar generally isn't the issue in modelling a different domain - Ruby's basic support for looping constructs, conditionals, etc. is more than sufficient. I was able to create a hardware description language (and simulator for said language) using Ruby (see: http://rhdl.rubyforge.org ). It's basically a data-flow programming language so the paradigm is very different than a normal Ruby program ( statements in specific parts of the program all execute in parallel, for example).


Also see Christian Neukirchen's recent blog entry on 'sublanguages' created in Ruby. http://chneukirchen.org/blog/
He's aiming at different paradigms that Ruby doesn't natively support like prototype-based and declarative logic programming. He's implemented a simple prototype-based OO sublanguage in Ruby.

Krishna
2006-09-20 02:21:17
We are working on a Meta modeling language for Business Rules Modeling. Can we consider this as a DSL. This specification can be implemented in any languages. But the business user will see only Business Rules semantics with which he can create the business rules.


Semantic Business Vocabulary and Rules


Unisys Business Rules Modeling