Ruby on Rails: An Interview with David Heinemeier Hansson

More on Ruby and Rails in this interview.

Rails is becoming the main reason people decide to pick up Ruby, which is something worth pondering. The interaction between a programming language and a very dominant framework, which isn't part of the standard library of language, is quite interesting.

Some quotes from the interview:

Rails is opinionated software. It eschews placing the old ideals of software in a primary position.

One characteristic of opinionated software is the notion of "conventions over configuration." If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you're rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that, which all add up to make a huge difference in daily use.

I really like our domain-specific languages. The beauty of specifying relationships with belongs_to, has_one, has_many and has_and_belongs_to_many. The ease of using validations like validates_presence_of :name.

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.

What has happened, though, is that Active Record has reduced the pain of dealing with the object-relational mismatch to a point where its a lot less appealing to seek alternatives—especially with databases like SQLite that give you the feel of flat text files, but within the context of SQL.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table)

Now, is Rails that smart, or would that need to be a Persons table?


It knows "People" -> "Person" =) You don't have to work TOO hard to fool it (dont use English, for example), but it doesn't do too bad a job. I've not tricked it yet, not that I have tried to.

Rails is that smart.

Rails is that smart.


I've heard it does have a problem with some words like sheep.


The beauty of specifying relationships with belongs_to, has_one, has_many and has_and_belongs_to_many.
It's small but my code automatically picks up on relationships (excepting many-to-many, which I'm not entirely sure would be possible to infer properly). That rails doesn't do this is probably due to MySQL which has very shaky (and only recent) support for referential integrity. Granted, it can use PostgreSQL but it was designed on MySQL (I assume) so this kind of stuck around.

MySQL and foreign keys

Yeah that is something I'd like to see added. MySQL does support foreign keys though, provided you use the InnoDB storage engine. The introspection method leaves something to be desired, but is possible (I had to parse the 'show create table' output for key definitions).

Anyway I'm working on an alternative to use with Rails which does this and more... see below

ActiveRecord and the relational model

I love Rails. Hopefully in a few years time we'll look at it as the first stage of a breakthrough in web development, leaving all that irritating J2EE crap behind and allowing people to use powerful languages and functional programming techniques to do everyday web-based database work.

I do have a few beefs with ActiveRecord though. While it is very useful, I find myself frustrated by some of its limitations. It can't deal with multi-column primary keys, infact (as I recall) it requires that the primary key is a single integer auto_increment column. It won't auto-detect foreign keys, and when you want to do complex queries with lots of joins you end up having to pass it bits of join SQL as text.

If anyone's interested, I am actually working on an alternative to ActiveRecord called ActiveRelation, which aims to provide full(er) support for the relational model within the confines of a Ruby-based ORM tool. It's geared very much towards providing a clean Ruby-style syntax for querying and working with a relational database, rather than being a database-backed persistance mechanism for existing Objects. (ActiveRecord can't seem to make up its mind which of these two it wants to be, although it does swing more towards the former).

My ActiveRelation will inspect the database to find all tables with their primary keys and foreign keys, and places no restrictions on your DB schema. It also has a powerful syntax-building system for the relational algebra, allowing you to build up syntax trees for arbitrary queries, which can then be used as iterators to fetch the results in friendly ORM-style object wrappers. The ORM features are built over the top of the relational algebra stuff, rather than joins and so on being added as an afterthought to the ORM code.

It can often 'guess' how to join tables given what it knows about foreign keys, so you can do things like this: == 'London').join(Artist).join(Label).project(Label).each {|label| puts }
To show all labels who've signed london artists.

It also provides friendly get and set methods for foreign keys automatically, like so:

a = Artist.get_by_primary_key(1234)
puts =! :url => 'http://foo/', :name => 'Foo'
And what's more these associated row objects are cached automatically when the object is the result of a query with joins.

It also comes with some helper methods which let you tell it about many-to-many relationships and tree structures.

Neat huh? Only disadvantage is that it currently only works with MySQL. But that could easily be changed if I had the time. It could also benefit from a bit of optimisation and clean-up. Let me know if you're interested in trying it out though, I intend to GPL it at some stage.


It would be cooler if it was released under the same license as Rails, or LGPL perhaps...

Of course, I can't (and won't) tell you what to do with your code. :-)

Oh right

I had presumed Rails was GPL too... any open source license is fine though, I'm not too bothered. Provided people release any useful modifications back to me :)

Will probably be in a releaseable state in another month or two.


How can I contact you? I'm at therandthem at yahoo dot com.


I'm matt at drownedinsound dot kom
Will drop you an email.


Scanning from the relations would work great, until you're required to ditch referential integrity in the DBMS and use indices (or unique indices) instead, for performance reasons.

Being able to make inferences via indices would be helpful for the folks stuck in the "enterprise ghetto".


Well I expect you could cook

Well I expect you could cook up some code to infer from indices too if you wanted - or just tell it the foreign keys explicitly...

J2EE crap

"leaving all that irritating J2EE crap behind and allowing people to use powerful languages and functional programming techniques to do everyday web-based database work"

Amen brother!

And I say that as a professional Java developer.

I find most Java developers want nothing to do with new languages. For some reason they think Java is the best programming language in the universe and they don't want some new language coming along and stealing the show.

The way I deal with Java Projects

Step 1. Install JRE
Step 2. Install Jython, Rhino or SISC
Step 3. Code
Step 4. Yep, 100% pure Java. Write once, run anywhere.

I could only wish

I loathe J2EE, but I don't see it going away any time soon. The mass of beurocracy it imposes makes it possible for large teams of folks to work on projects together. Maybe there's a conservation theorem at work: the cooler the language, the more hacker-friendly, the worse the language, the more big-company friendly? But that's pro'lly for another article.

I'm working on my own language to run in the JVM (mostly Haskell inspired), but I'm planning on stealing whatever I can from Rails, and shamelessly so.

True, Ruby is perhaps more ha

True, Ruby is perhaps more hacker-friendly than big-company friendly. But Rails does provide a lot of structure and there is a right way of doing everything. Most of the hackerish stuff is hidden away in the guts of the framework.

One thing I'd really like to see in Rails is proper continuation support. Ruby has continuations so hopefully this wouldn't be too hard to integrate into Rails' Controllers.


Rails has inspired some the most rewarding web development I've done to date, but I also don't agree with its default use of MySQL. While the table associations are substantially easier to configure in Rails over J2EE, it really should be taken a step further and be done automatically. For that and plenty of other reasons, I would much rather have Rails built around Postgres.

While I agree with the genera

While I agree with the general idea of something like Rails, I find this particular implementation of it to be pretty poor.

The first thing that bit me was the pluralization thing, because I and my co-workers use the naming convention that you name a table after what a row in it represents. I don't mind if rails makes "person/people" easy for those that use that convenetion, but why make it harder for those who want a table called "person"? In the end, I find myself having to guess, "what will Rails do with this word?" (Ruby in general often has this problem that you can't predict with confidence what it will do in a given situation, because it tries to do someone's definition of the "right" thing rather than the obvious and simple thing.)

But stuff like subclassing an ActiveRecord class invoking the Single Table Inheritance design pattern really takes the cake. I made a simple refactoring (Pull Up Method) in a couple of AR classes and suddenly everything goes all to hell. And I spent a long time trying to figure out how to turn off the behavior, time that convinced me that the AR parent classes know far more about their children than they ought to. That Single Table Inheritance is non-relational silliness was just icing on the cake, as it were.