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.

“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

class Customer < Content
has_many :orders, :dependent => true
end

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 :)

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.

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.

http://en.wikipedia.org/wiki/Domain_Specific_Language