Ruby on Rails: Making Programmers Happy

David Heinemeier Hansson, the creator of the increasingly popular Ruby on Rails Web application framework, answered a few questions about his creation earlier this week for eWEEK Senior Editor Darryl K. Taft.

What's the allure of Ruby on Rails? Why do folks love it so?

The author of Ruby, Yukihiro Matsumoto, tells us that he set out to create a language that would "make programmers happy." Rails attempts to run with that noble and profound goal and bring it to the world of Web application development. We're optimizing for humans first, compilers and the frameworks second. It's been a constant search for how we could make the development process more in tune with what makes programmers happy.

How so?

Three quick specifics: Convention over configuration. Instead of telling various parts of the technology stack five, six, seven times that you have a products table that's the data source of your product object, we've institutionalized that convention in a generalized notion: Classes are singular, tables are plural. This may sound like a trivial notion, but it has a radical impact on the amount of work that the programmer needs to do in his daily work.

We're basically taking the whole world of pain that is known as configuration and making it optional. As long as you do what most people want to do most of the time, you get a free ride. No configuration necessary. So get the 80 percent by convention, tailor the last 20 percent by hand.

Change is instant. The feedback loop between change and effect is incredibly important in programming. If the distance is too far, you tend to grow uninterested in testing your changes. You want to take bigger steps, so the penalty of compilation, deployment and restarts is paid less often. That kills productivity and motivation.

This is something we learned from PHP. The biggest lure of PHP is how quickly you can get something up there and make changes until it's right. We took that focus on "change is instant" and brought it into a world of modern software development—bridging the Java and PHP worlds.

Full-stack framework. Programmers spend an enormous amount of time making a thousand different pieces work together. They cherry-pick a little over here, a little over there. Often times, the pieces are not exactly a good fit. So you need to add a bunch of glue, write a bunch of configuration, and basically end up wishing the left hand knew what the right hand was doing.

Rails is an ambitious attempt to provide a "full-stack framework," which means that we attack all of the problems across the model-view-control pattern. We deal with creating the templates that generate the HTML code, the controllers that direct incoming requests, and the model that makes the database come alive in objects.

In a sense, we're trying to be the Apple of Web application development. Provide and care for the complete experience. The buck stops here. Every problem is our problem. So we tend to get a lot of those small things right that fall outside of any of the major divisions.

We get all those simple, unglamorous problems solved—the ones that won't make a good article in an academic computer science journal, but that most programmers are struggling with every day.

What kind of impact has it had on Web development?

Naturally, I'm biased, but I truly believe that Rails have had and will have a monumental effect on the Web development world. Everyone and their mother is busy saying about how their new stuff is more "Rails-like." Convention over configuration alone represents a mental switch that will be visible in all new work in this space.

Yes, that does sound rather grandiose.

Is Ruby on Rails better suited to any particular types of applications?

Rails is better suited for the applications that most people do most of the time. It has its eye on the big 80 percent. There are 15 percent of the applications that are so tiny that they might make a better fit in PHP [it's available on every $2 host, you can have your entire application in one page] and then there's the most complex 5 percent that needs advanced integration with legacy systems or have other specialized needs. Java is definitely a great fit for that.

The problem is mostly one of overuse. Solutions stretched outside their sweet spots. Java is a behemoth of complexity. Using it to do your average Web application is like cracking a nut with a sledgehammer, as Dave Thomas put it.

How does RoR differ from Ruby?

Rails is a framework that specializes Ruby for Web application development. Ruby itself is a general-purpose programming language—like C, Java, Python, you name it. It's not especially targeted at solving the Web problem. Rails makes it.

So "Ruby on Rails" is simply a construct I've been using to introduce people to this new environment. That they're going to get both a new programming language and a new Web application framework at the same time.

What do you think of all the framework and language efforts coming out and declaring themselves like Ruby on Rails?

Everyone is saying how their new stuff is "like Rails for ..." Once products or projects that need a certain tipping point attract those comparisons, they're often quite silly. Just notice how anything that plays MP3s is billed as an "iPod killer." That's kind of how I feel about announcements like that. It's great that others are willing to learn from what we've done [just as we have from others], but it does not make Java or anything else "like Rails." Inspired, sure, but let's keep the propositions right and stop at that.