Ruby on Rails: An Interview with David Heinemeier Hansson
Pages: 1, 2, 3, 4

ED: Did you ever think at any point that Rails would have been better if written in Java or Python?

DHH: Better is such an inadequate and ambiguous term to apply to a comparison like that. If we suspend our disbelief for a second, I could imagine that Rails in Java would have an easier time gaining corporate traction. But that's just not an all-important criteria of success for me. I created Rails to help me do my work better and faster, not to drum up an attempt to move into that space. That it's happening anyway is great, but it probably wouldn't have if I had tried to consciously engineer it that way.

As for Python, I don't know. From the outside, the languages look incredibly similar. But from the inside, it's the small differences that make it feel like very separate worlds still. Python surely has a lot of cool stuff going for it. And if it wasn't for Ruby, I could certainly see myself in that camp.

I think Rails feels, smells, and tastes like it does exactly because its very Ruby-like. It plays heavily on the best in Ruby. The blocks, the ease of creating domain-specific languages, and so on.

ED: Would you ever consider recommending PHP or Perl to write a web app now?

DHH: Sure! Rails is not everything for everyone at any time. I use PHP myself fairly frequently when I just need a dash of dynamic content on pages. We use it for all the marketing pages at 37signals that just need a few includes and such.

Rails does, however, command a very large portion of web applications as its sweet spot. So if you're asking me whether I would recommend PHP or Perl or whatever to do applications like Basecamp,, ODEO, Strongspace, and so on, the answer is surely no.

Your circumstances may well dictate that you do anyway, though. I think, however, those circumstances are often grossly overrated. For example, that just because you don't have any Ruby programmers on staff, you can't use Rails. Or because you've used another environment in the past, you can't switch. Hogwash. Good programmers are good programmers. And Rails is likely a lot closer to what you've been doing before than you think—minus a lot of the pain, naturally.

On Web Application Frameworks

ED: One of the things I like about Rails is the differentiation between production and development environments. Those kind of features don't normally come built in with scripting language web tools. Did you consciously set out to provide some "enterprise" features in Rails?

DHH: I set out to serve me. Rails is a very selfish project in that respect. It gained a lot of its focus and appeal because I didn't try to please people who didn't share my problems. Differentiating between production and development was a very real problem for me, so I solved it the best way I knew how.

It's hard enough to solve your own problems with eloquence. Trying to solve other people's problems is damn near impossible—at least to do so to the level of satisfaction that would make me interested in the solution.

That's why we hold the notion that "frameworks are extractions" so very dear in the Rails community. Frameworks are not designed before the fact. They're extracted when you've proved to yourself that an approach works. Whenever we get ahead of ourselves and try to leap over the extraction process, we come back sorely disappointed.

I believe that's why Rails just feels right for so many people—because it's been used by real people for real work before we dished it out for others to reuse.

Pages: 1, 2, 3, 4

Next Pagearrow