Is Ruby on Rails a Silver Bullet?

Is it Ruby?

Is it really Rails that we should be looking at, or maybe we should be concentrating on Ruby to find the source of Rails’ productivity?

Certainly there are people who will argue that the differences between one language and another are large enough to have this kind of effect. Paul Graham makes this argument in Revenge of the Nerds. He’s talking about Lisp, not Ruby, but the languages are similar enough that most of this arguments apply equally well to both.

This is a seductive line of reasoning. One very simple example — recently I found myself having to randomly shuffle an array. A quick web search turned up this little snippet:

array.sort_by{rand}

I can’t think of any other language in which you could create a solution so concise and yet clear. It’s a wonderful example of what you can do with a well thought-out language with a powerful and composable set of library routines.

But is Ruby the true source of Rails’ productivity? I don’t think so. It’s a lovely language which introduces a number of very useful features into the mainstream. And certainly Rails would be rather different if it was written in a different language (see Bill Katz’s article Could Rails have been built without Ruby?), but overall Ruby is just another incremental improvement.

What is special about Rails?

David Heinemeier Hansson famously describes Rails as opinionated software. By embedding several good design choices, through convention over configuration the framework enables developers who choose to stick with these choices to save themselves a lot of the “drudge work” required by other frameworks.

In Code Generation: The Real Lesson of Rails, Bill Venners argues that Rails gains its productivity benefits through code generation (or metaprogramming). And certainly, metaprogramming is a powerful technique which Rails makes good use of.

One aspect of Rails which doesn’t seem to get as much publicity as the above is its tight integration with the script.aculo.us library. For anyone developing a sophisticated user-interface, it’s one of Rails biggest wins.

And finally a number of recent enhancements to Rails make their own significant contributions, RJS and the upcoming ActiveResource spring to mind.

But is that it? Certainly all this explains to some extent at least how Rails achieves what it does. But is there a deeper truth to be found?

The question we should be asking is not how Rails achieves its productivity gains but why is there the scope for Rails to make these savings in the first place? If we believe the No Silver Bullet argument, then this kind of productivity improvement can only come from addressing accidental complexity. So where is it?

New accidents

You can probably see where I’m heading. Ruby on Rails really does deliver dramatic productivity benefits, and it does it by addressing the accidental complexity involved with writing web applications. All of which is new complexity introduced since Brooks wrote his paper.

Web applications are a wonderful thing. Here at 82ASK, we wouldn’t be able to run our business without them. They enable our texperts (researchers) to work from anywhere; all they need is an internet connection and a web browser. But, for developers at least, they come with daunting challenges.

Web applications need to maintain session information. They need to cope with the fact that browsers don’t maintain a connection, that the user can hit the “back” button at any time, save a bookmark to anywhere within the application and visit it at any time or close their browser without logging out. Developers have to handle an odd mixture of (at least!) HTML, XML, CSS and Javascript, in addition to whatever technology is being used on the server. They need to take into account multiple versions of different browser families, running on a range of operating systems, networks, displays and configuration options.

More recently, AJAX applications need to deal with many immature technologies, consider how to partition functionality between the client and the server and how to degrade gracefully in the absence of the necessary support.

Successful applications have the additional concerns of ensuring scalability and reliability in the face of multiple simultaneous users, rolling out new versions without interrupting service or breaking existing functionality. Applications typically run on multiple servers and decisions need to be taken about how to balance the load and synchronize concurrent operations.

And finally there is the Object-Relational Impedance Mismatch; the fact that almost all modern programming languages use objects to represent data in memory, whereas almost all popular databases use the relational model. Somehow we have to translate from one approach when the data is on disc to the other when it’s in memory and vice-versa.

All these are new accidental difficulties which need to be addressed by anyone creating a web application. They have nothing whatsoever to do with the particular problem being solved, but everyone has to solve them nevertheless. And this is what creates the opportunity for Rails to deliver the huge improvements that it does.

Other technologies and frameworks have addressed some or all of these issues. Rails just does a much better job than almost everything that has gone before.

Pages: 1 2 3

6 Responses to “Is Ruby on Rails a Silver Bullet?”


  1. 1 ilan berci April 5, 2007 at 3:43 pm

    Simply fantastic artile, (I especially appreciate all the links to the referenced articles!) I agree with you a 100% in the fact that rails provides benefit by simply addressing accidental difficulties but that is what they stated from the very start (as long as you stay on the path and follow their sensical conventions).

    Likewise, it obviously won’t improve efficiency in addressing your bussiness model (which framework does) and never make such claims. You need Ruby for that! 🙂

    Thank you for taking the time to write this, I will forward it to my development group.

    ilan

  2. 2 jerzy prekurat April 5, 2007 at 9:02 pm

    My initial lack of enthusiasm towards RoR was based exactly on “No Silver Bullet” way of thinking: tools do not address essential difficulties of the problem, most tools address accidental difficulties well enough, so what is the big deal ? YAT, YAT, YAT… (yet another tool)

    Well, there is something: it works….

    I think this article comes long way towards answering – why it works and where it works. Thanks !

    jerzy

  3. 3 Bruce Tate April 6, 2007 at 2:20 pm

    Fantastic article. You have said it better than I. I’ve since taken a CTO role at a company called WellGood, LLC, the makers of ChangingThePresent.org. We’ve come to understand that Rails can make a dramatic difference in our overall productivity. It can’t improve our business processes.

    Said another way, if technology is your bottleneck, Rails will rock your world. In this spirit, Rails has been very good to us. It’s very close to a silver bullet in that sense. We’re simply applying a more appropriate technology to the task at hand.

    But technology usually isn’t the bottleneck. So in some cases, we make bad decisions, and actually dig a hole faster than before. All in all, we’re good enough from a process perspective, and we have a close enough problem to the ideal Rails niche, that we’re able to be very productive.

  4. 4 John May 27, 2007 at 3:38 pm

    Nice article. One word: WebObjects. If you know this Rails is “meh”, if you don’t Rails is GOD!

  5. 5 Sam Halliday August 14, 2007 at 8:07 am

    It’s interesting to note that Bruce Tate and Justin Gehtland wrote an app in 4 months in Java, then ported to Ruby in four days. Note that I said “ported” not “wrote”. After 4 months of discovering the architectural bugs and learning the traps and pitfalls of a program… rewriting it should be a breeze! Still, 4 nights is bloody fast.


  1. 1 There might just be a Silver Bullet « 3Spoken Trackback on April 10, 2007 at 7:02 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s





%d bloggers like this: