I feel like I’ve been picking a bit on DataMapper in my recent posts, so I first want to say that I like most of what I see in DataMapper, and is generally just nitpicking. I’m also what I’ve noticed there to give examples instead of making up something. And actually, one of the reasons is that it was some time since I read much Ruby code, and DataMapper happens to be one of the things I’m looking a lot at right now.
Which brings me to something Sam Smoot said in the discussion about adding operator methods to Symbol. (In the blog post Simplified finders in DataMapper). What he said was this:
That might satisfy some, but it ranks pretty low on the “beauty” gauge. And that really does matter for adoption…
Now, the reason I’m bringing it up here is not to pick on Sam or DataMapper (Really!). Rather, it’s because an attitude that I’ve noticed all over the Ruby world lately. In most cases it’s not explicitly said like this, but I like Sam’s quote because it verbalizes exactly what it’s about. You really want your library to look nice. Beauty is really important in a Ruby framework. It really is important, and lots of focus is put on it. And one of the reasons for this is to drive adoption.
Since it’s been verbalized like this, I’ve realized that this is one of the things that really disturbs me with the Ruby communities fascination with making everything, absolutely everything into a DSL.
Now, I really do like thinking about DSLs and working with them. Being a language implementor brings that out in me. But a DSL really has it’s place. Why shouldn’t you make everything into a DSL? Why shouldn’t everything look nice? First of all, the initial development might just not be worth it. A DSL-like approach generally involves more effort, so maybe a regular API works fine? A DSL introduces cost, both in development and in maintenance. Everything you do needs to be balanced. My coworker Marcus Ahnve gave a very good example of this today. He wanted to use ctags with an RSpec file, but since ctags doesn’t understand “describe” and “it”, there was no way for it to extract any useful information from it. Now, this is a trade of the framework designer has to make, and in the case of RSpec I think that the DSL is totally justified, but in other cases it’s not.
So take the issue at hand. Adding a few methods to Symbol, so that finding information in a database will look a bit nicer. In real terms this involves polluting the Symbol namespace with methods that have a very narrow scope. The usage (that looks more or less like this: Exhibition.all(:run_time.lt => 3)) uses something that reads easily from an English/SQL perspective, but not necessarily from a Ruby perspective. The main question I have when seeing this is what the eventual cost down the line will be for having it. Is this approach expandable? Is there any possibility of clashes with other libraries? Will someone else easily maintain it?
Focusing on beauty to generate adoption seems like the wrong choice for me. You add things that might not be so good long term, to get a larger initial code base. I would prefer to make the right choices for the right reasons first, and then let adoption be driven by that.
In summary, be responsible when designing APIs. I know those are very boring words. But it’s a reality, and your users will thank you for it.
PS: Sam just wrote a new comment, saying that the Symbol operators will be optional in the next DataMapper release. Good choice.
2 Comments, Comment or Ping
Overall I agree. Generally speaking I favor Ruby syntax over a DSL any day. I usually phrase my dislike of a DSL for it’s own sake as API bloat. I have only so much room in my head for API. The more we can keep to pure Ruby syntax, the less API I need to learn, and that’s a good thing.
For example, there’s any number of Rails features that simply go unused because the API is so incredibly large (like component fields/EmbeddedValues).
I think one of the biggest gripes playing into this is the over-use of Hashes as a stand-in for named-parameters. DM does it as well with Properties of course. I’m not sure you can entirely get around it without a syntax compromise that’s sometimes just not worth it. But overall I much prefer explicit parameters in the method signature. Even if I don’t have the signature memorized then, at least I don’t have to dig through lots of code to figure out what they are (where Hash options are consumed); I can instead just look at the method signature.
September 9th, 2008
I was once a padawan ruby API developer, fascinated with creating beautiful DSLs. However, I believe a change occurred in me when I read “Design Patterns In Ruby” by Russ Olsen.
When I finished the book, I realized that a DSL was just another communication tool in long heritage of amazing conceptual work of our ‘ancestors’. I became more excited about learning about *all* design patterns, instead of simply focusing on one.
When the ruby community matures, I believe we will see less API’s built around DSLs and it will give rise to newer, more exciting patterns. :)
September 12th, 2008
Reply to “Short term adoption and Ruby DSLs”