I just read my colleague and teammate’s excellent post on the subject (and Jeremy Voorhis’s thoughts on it too), and although I added a comment, I felt it was worthy of a little expansion.
The first time I considered Rails as a DSL was during the recent ThoughtWorks roadshow, where both our founder and president toured around the various ThoughtWorks locations to give an update on our progress as a business, and opportunities and visions for the future.
During the talk, Roy talked a bit about what he was personally excited about for the future. One of the things he mentioned was the rise in the buzz around DSLs, and Intentional Programming. He mentioned how another ThoughtWorker (sorry, I forget who it was he mentioned – perhaps someone else remembers?) had explained the concept to him and cited Rails as an example of both a DSL and framework. George raised his hand at this point and very confidently explained how he felt that it quite plainly wasn’t a DSL, and I think his post does well to further his reasoning for his position.
George’s post (and also Matt’s comment beneath – another brilliant ThoughtWorker and team-mate) raised the trouble with trying to tie down where good design ends, and a DSL would begin
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 think this is a fair point, and a valid one, but I’m not really sure it’s too important in the long run.
To me – at least from what I’ve read and seen examples of – a DSL is about making it easier to write code that can be expressed re-using existing domain language in a natural way, reducing the cost of translating between developers and domain experts.
And that’s the key (at least what strikes me as the key attractiveness in DSLs) – the ability to re-use existing domain language, and better (and more naturally) talk about domain concepts. Make it easier to take those discussions and turn it into code, make it easier to discuss that code with experts and ultimately evolve a system that can handle domain complexity for future development.
Whether it’s implemented through fluent interfaces, or other ‘good’ design to my mind isn’t so important (perhaps over-hyping is a concern), but, fundamentally it’s all about domain communication. Aiming to produce a DSL seems an irrelevant pursuit if it’s not to better enable the handling of the domain, and ultimately make it easier to be more effective as a developer.
For instance, my personal opinion is that Rails’ ActiveRecord goes quite a lot of the way to providing a language that is natural for modeling data and it’s relationships. Such as:
123 |
class Order < ActiveRecord::Base has_many :items, :dependent => trueend |
It’s still Ruby, and there’s no getting away from using classes and other constructs to code with. But, it does provide language that is natural to the domain that make it easier to work with.
Contrast that to trying to explain the model through foreign key relationships and the like. That’s not to say it’s not important to sometimes talk with that lower-level language, just that it’s easier to work in the higher level aspects with it abstracted away.
I think George hits it perfectly when he says the following
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.
To me, that’s where Rails does hit it in the internal DSL candidate stakes – in the use of small language-like niceties for some of it’s building-blocks, such as ActiveRecord.
From a development effectiveness point-of-view I can see DSLs (and similar things) being very useful. People way more intelligent than I am are very keen on them. For me, it’s about raising the importance of the domain language, and the increasing importance of communication in an iterative development world.
I had way, way too many flashbacks to bad use of language, ignorance of domain concepts, and complicated ways of avoiding domain complexity during previous projects pre-TW whilst I was reading Domain Driven Design’s war stories to not feel like that’s the key to DSLs – re-use of domain language, encouraging the exploration of domain language, and stressing the importance of communication. It’s about being more effective with domain complexity.