Rails: Not a DSL
Everywhere I turn these days, the most common three letters that I hear are DSL. Let me spell them out: D. S. L. as in Domain Specific Language, but you knew that already.
One great reason why you should go DSL is because you can write one and call it LSD.reverse. Yep, moment of genius.
OK, enough with the dry humor…
The reason I’m sitting here writing this, instead of staring at the Midlands’ cows outside the train’s window (they look delicious), stems from finding it a tad awkward every time I see Rails (as in Ruby on Rails) mentioned in many of those DSL themed conversations. I seriously do not think Rails is a DSL. Last I heard Rails was a web framework.
But what is it that makes a DSL a DSL?
Judging by the name, it must be something along the lines of a programming language that is specific to a domain. So, A, it probably has to be some sort of programming language, or something that resembles one, and, B, it should express a specific, confined and well defined area’s behavior and rules.
One might argue that Rails is specific to the Web Application Domain because it expresses a web application’s behavior in web application native terms. For starters, Rails is not a programming language. If we’re tired of using the term Framework and we’re looking for a new one, then alright, although there must be more than that here… Maybe Domain Specific Framework is closer to what the peeps who view Rails as a DSL might have in mind?
Nah, FSD.reverse doesn’t sound cool at all, and DSF is like DFS which is something that’s always on sale on UK TV, so better not…
Secondly, the web, or the web application, is too broad and generic an area to qualify as a Domain. If we award the DSL For The Web attribute to Rails, we might as well call C a System’s DSL and Assembler a Computer DSL.
A DSL cannot be too generic. The more we generify it, the less of a DSL it becomes. Along with the language being specific to the domain, I believe the domain itself needs to be specific.
I can see how, say, a shopping cart web application could be defined as existing under a domain. So, the shopping-cart-domain is a sub-domain of the web-domain, I hear you say. So, Rails as a DSL can have many sub-DSLs. This in turn, however, makes Rails a sub-DSL of Ruby, which is a sub-DSL of C, and next thing you know, we’re writing a DSL for the Universe.
I find it rather hard to draw the line between a DSL and a library with meaningfully named methods, functions, macros, call them what you will. I also get the feeling this whole idea started from the desire to write something as cool as Rails and, inevitably, buzzword compliance is one of the first things to follow a tech revolution and its followers.
I am tempted to argue that DSL is the Emperor’s new clothes - API or Library being the Emperor, but I’m still quite intrigued by the concept, so I’m not prepared to dismiss it without pursuing it a bit more. In addition, regardless of how much I might like the syntactic sugar that can be achieved with Ruby, it’s just aesthetics and that is not substantial enough to drive something destined to become fairly useful. I can see how the Rails’ principles and practices can be applied to specialized, domain confined software development tools, but I’d rather see the tools supersede the terminology.
At least I got the name right, you gotta give me that…
July 13th, 2006 at 11:48 pm
God I love reading this blog.
Yeah, the ubiquitousnessnessness of that little acronym grates with me too.
For me it’s the L that makes me puzzled when I look at some things claiming the DSL title. The thing about calling a DSL-ish thing that you write in Ruby a language is that it’s still using Ruby’s grammar. You’ve just written a humane interface in a grammar that happens to be particularly easy to grock. No one calls JMock a DSL because Java looks ruff.
If you can show me some BNF and a compiler we can talk.
I don’t wish to be negative- I do think DSLs are really very useful indeed- especially on account of my being obsessed by the idea of acceptance-tests-as-documentation. I can’t wait till we start seeing more true DSLs once Mr Simonyi, jetbrains et al finally make it easier for us.
July 14th, 2006 at 3:45 pm
But don’t forget the very traditional adage that “library design is language design” (from Stroustrup in his C++ book). Languages like C++ or more so Ruby or more so Scala (or more so Lisp?) make this a fairly meaningful statement. I prefer the ease of use and consistency from Ruby over the concepts shared by JetBrains.
July 14th, 2006 at 5:12 pm
“A DSL is somewhere between a tiny programming language and a scripting language, and is often used in a way analogous to a programming library.”
http://en.wikipedia.org/wiki/Domain_Specific_Language
July 14th, 2006 at 8:51 pm
“DSL” was on everyone’s lips at RailsConf and it really had me wondering — what, exactly, is a DSL? The examples shown had me wondering, what’s the difference between an API and a DSL?
It seems to me that a domain specific language should require some restricted grammar which could be described by BNF and you could use a parser-generator to generate a parser for that DSL. Or, if you love pain, you could use regexps.
But if it’s just method calls with nicely named parameters, that seems to be pushing it a little.
I think DSL term has aquired something like buzzword status in the Ruby community. Not that good work isn’t being done, but it seems too widely used.
July 16th, 2006 at 10:15 pm
Really, though, any code which is expressive enough can be considered a domain specific language.
To answer Luke’s question - not all APIs can be used in a DSL, but often crafting a DSL is really just API design. I just wrote a DSL for time calculations - it is just a series of wrappers around a pre-existing Ruby time library, but it reads like English.
On the question of, “Is Rails a DSL?”, I’d be inclined to answer, “Sometimes” because much of a Rails application’s code could be understood by domain experts, with only a little walk through help from the programmer. That is not something you can say about most frameworks.
July 18th, 2006 at 8:30 pm
Nice post George, only just spotted it tonight.
However, I do think that Rails could be considered to contain lots of little DSLs. Matt’s point about it still being Ruby grammar, just easy to read is valid. But then what’s language after all? If Ruby is generous enough to let you write in a very open-ended way, it’s just it provides you with more options.
For instance, would you not say Rails’ ActiveRecord provides a good DSL for the expression of a data model?
I.e.:
class Customer true
end
Although you’re still at the whim of Ruby syntax (i.e. the exploitation of hashes and symbols), it’s still an attempt to provide language natural domain to better let you express intent. Admittedly, that’s with other developers, but that doesn’t mean we’re less important right?
I agree that there’s a risk that too many things could be considered DSLs, but I think thats possibly because its a wide-term, what’s important is the value and usefulness. Does Rails provide language-like extensions that better let you express the problems of the domain?
My own feeling is that it does, but I do agree that the bluriness between fluent interface-esque designs and DSLs is blurry, but should we be worried about that? Why can’t they be talking about the same thing? Fundamentally to me they’re all focused on trying to make it easier to communicate and that’s something I’m in favour of, whatever form
July 18th, 2006 at 8:32 pm
D’oh, it missed my code snippet:
class Customer < Content
has_many :orders, :dependent => true
end
July 20th, 2006 at 10:30 am
Tom take a look at “A rationale for semantically enhanced library languages” by Bjarne Stroustrup
“A Semantically Enhanced Library Language (a SEL language or a SELL) is a dialect created by supersetting a language using a library and then subsetting the result using a tool that “understands” the syntax and semantics of both the underlying language and the library”
http://public.research.att.com/~bs/SELLrationale.pdf
July 21st, 2006 at 10:03 pm
I don’t think anyone is saying Rails IS a DSL. What they are saying is that Rails utilizes a DSL or DSLs in it to do certain things, such as the example from paul in a previous comment.
That leads into the question: what the hell is a DSL? Isn’t that too general to be a DSL? Isn’t everything then a DSL?
Well …. yes. Obviously, DSL has become a buzzword, and is widly overused. However, for me, I find it helpful to think of the “DSL Concept” not as a script definition of a thing, but as a general concept that is applicable (sometimes) to how I write code and/or anything textual and client facing.
To me, it has elements of LISP = Programmable Programming Language, (in that I try and write lower level code that eventually enables me to write code and think in a higher level domain), treating code as language (where appropriate) and other related concepts. If you stick to getting a Webster’s definition of DSL, you’ll never get anywhere and you won’t get any benefit.
July 21st, 2006 at 10:07 pm
Thanks for the link, Marco.