Ruby on Rails: Making Programmers Happy

 
 
By eweek  |  Posted 2005-11-01 Email Print this article Print
 
 
 
 
 
 
 

Q&A: Ruby on Rails creator David Heinemeier Hansson discusses the allure of the Web application framework.

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. Whats 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. Were optimizing for humans first, compilers and the frameworks second. Its been a constant search for how we could make the development process more in tune with what makes programmers happy.
Click here to read about the outpouring of support for Ruby on Rails.
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 thats the data source of your product object, weve 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. Were 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 its 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, were 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 wont 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, Im 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 [its available on every $2 host, you can have your entire application in one page] and then theres 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. Its not especially targeted at solving the Web problem. Rails makes it. So "Ruby on Rails" is simply a construct Ive been using to introduce people to this new environment. That theyre 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, theyre often quite silly. Just notice how anything that plays MP3s is billed as an "iPod killer." Thats kind of how I feel about announcements like that. Its great that others are willing to learn from what weve done [just as we have from others], but it does not make Java or anything else "like Rails." Inspired, sure, but lets keep the propositions right and stop at that. Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
 
 
 
 
 
 
 
 
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel