“A big part of what makes Ruby so special to work with is just how much expression you can pack into a few lines of code,” says Hansson.

Question: What makes Ruby a special language?

David Heinemeier Hansson: To me good programming is just like good writing.  It's succinct.  You're expressing what you want to say in as few words as possible.  You're picking just the right words for the sentence, and it's sort of a grand thing.  A program is just like an article or a book; it's composed of tiny things like words that form into sentences, and paragraphs, and chapters, and so forth.  A programming language—a good programming language—allows you to build a program in just the same way.

So you'll have methods that are really short.  A big part of what makes Ruby so special to work with is just how much expression you can pack into few lines of code.  When I compare it to something like Java where it takes perhaps ten lines to express a very simple operation, that same operation can be expressed in a single line of Ruby.  And that just makes understanding the entire program that much easier when the density of expression is so much higher, and it's not just because it's short.  There's plenty of programming languages where you can write exceptionally short code, and it's completely unreadable afterward.  Ruby has this uncanny ability to just be shortened the same way your thought would be short, but no shorter than that.

The other part of it is also having a grand or free mode of expression that there are many different ways that you can say something.  So for example:  Lots of programming languages have—or all program languages have—conditionals.  If something is true, do this.  Now, sometimes you want the positive version of that.  Like, “If employee works here, then print this screen.”  Sometimes you want the opposite.  In most program languages, you would go about that by saying, “If not programmer works here, then do this.”  That's not a very natural way of expressing that.  You would never say that in real life.

In Ruby, you can say, “Unless the programmer works here, do this.”  So it's just all those little things where the creator of Ruby thought about the whole picture.  It's not just that you can get something done.  All programming languages can do the same things.  There's nothing you can do in Ruby that you couldn't do in some other programming language.  What makes Ruby special is how you say it.

Compared to natural languages, I think there's also just something to the tone and they rhythm of it.  I'm Danish.  I speak Danish, and I admit that Danish is not a very pretty language.  Thankfully, it's not as ugly as German, which I think is probably one of the ugliest languages of all time.  But if you compare something like German to something like French, you don't have to speak either language to hear that French is obviously the prettier language.

I think if somebody who doesn't even know code, they can look at a piece of Ruby code, and they can appreciate that Ruby is French and Java is German.  That's sort of really the appeal to it. Because you have to work with this stuff all the time.  Programmers often work for many, many, many hours a day, and this is your main mode of expression.  It has to be good.  If it's not good, if you're speaking in an ugly language every day for eight or ten hours a day... well, I won't say that it turns you into an ugly person, but I like to just surround myself with beautiful things.  Ruby is beautiful; lots of other programming languages are much less so.

Question: Do programmers need to like the languages in which they code?
 
David Heinemeier Hansson:  I think in the past, programming languages and environments have been determined by everything but the beauty of expression.  It's been determined by “We have to make this really fast.  We have to make this really efficient.  We have to make this really logical.  There has to be only one way of doing things.”  All of these other concerns that you would think about when you would think about somebody approaching it in a very sort of binary approach.  That's sort of the best way I can express it.

Ruby comes from a much different angle.  In fact, the creator of Ruby said that his main goal of creating Ruby was to make programmers happy.  Now, you're introducing something that in many ways seems like a foreign concept.  You're talking about code.  What does happiness have to do with anything?  How does happiness play into this stuff?  It absolutely does because programmers—surprisingly enough, I'm sure to a lot of people—are humans, too.  And humans just respond to emotional things.  They respond to beauty, they respond to a general sense of well being and liking your tools.  It's not enough that your tools can get the job done.  It's how they get them done.  It's whether you like wielding those tools day out and day in.

And I've talked to a lot of Ruby programmers who came to sort of the edge of their career thinking they've been working in Java, or C-Sharp, or some other language that was just driving them miserable.  And they were thinking, “You know what?  I know how to do this stuff, but it's probably not for me.  I'm not happy working with these languages or environments every day.  I'm going to quit.”  And then some of them found Ruby.  And it almost sounds cheesy as sort of a religious experience that they find this program language that all of a sudden makes it interesting for them again to be programmers.  But it's absolutely true.  I felt exactly the same way.  I was absolutely not convinced that I was going to be a programmer when I was working with PHP and Java.

To me, at that point programming was just something I had to do to get programs.  It was sort of just a functional thing I unfortunately had to go through in order to realize the ideas that I had for programs.  For me, Ruby just changed that such that the act itself was pleasurable. And I think that's just a magic moment.  When you change over from not just being able to do the job to actually enjoying the job. That's just a huge difference.   And I think that the product in the end also reflects that.  The programs I write now are much better than the programs I wrote when I didn't like my tools.

Recorded on July 22, 2010

Interviewed by Peter Hopkins