This post originated from an RSS feed registered with Ruby Buzz
by Jeremy Voorhis.
Original Post: Rails: Not a DSL
Feed Title: JVoorhis
Feed URL: http://feeds.feedburner.com/jvoorhis
Feed Description: JVoorhis is a Rubyist in northeast Ohio. He rambles about Ruby on Rails, development practices, other frameworks such as Django, and on other days he is just full of snark.
This morning, I refreshed NetNewsWire1 to see the headline Rails: Not a DSL. After clicking on the feedreader’s link, which linked to Artima, which linked to DZone, which linked to Digg, which linked to the blog with said article.
The message of the article boiled down to something like this: you can’t call everything a DSL. Sure. If you repeat any word to yourself enough times, it loses its meaning2. Well, it’s true. Rails’s expresiveness is a matter of Ruby being used the way it was meant to be used. It’s how your application and your platform interface – if you are taking advantage of a dynamic language, the two may then intertwingle and appear as an arch.
For an exampe of this style of application design, I can make Ruby’s SHA1 implementation – a method that I use frequently for password encryption and for generating unique tokens – available directly from a String object as follows.
class String
# Returns the SHA1 digest of a +String+.
def to_sha1
Digest::SHA1.hexdigest self
end
end
This may be called throughout the application and it is easy to read. I have not, however, created an internal DSL for string encryption. If you need a label for this style of application design, call it a fluent interface, or the arch. Or just call it good design.
Finally, what separates a DSL from just good design? While I cannot provide exact criteria, I think the answer lies in the motivation for which the language-oriented tool in question was created. More specifically, was it created to solve a specific problem with a narrow scope? Was it also designed to share meaning with an expert?
An excellent example of a DSL is the Spirit parser library, which allows C++ developers to transcribe a grammar, likely created by a language or protocol expert, into executable code. While its feats are much simpler, I believe the asset compiler library I have written also qualifies as a domain-specific language because it was created to be a language-based tool that eased communication between my client – a domain expert in image processing – and my application, transcribing their requirements almost directly into Ruby. It is worth noting that my work rarely involves creating or even using DSLs; they are just another tool at my disposal, especially when solving a specific problem that requires communication with experts.
1 Yes, it is still my mainstay feedreader.
2 In my experience, the word “each” is very susceptible.
Previous Topic
