Ruby and Rails: In your face... but out of your way

Posted by David A. Black on May 11, 2006

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Web Frameworks ,

Delivering Value ,

Ruby

Tags

commentary ,

Languages

April 2006

People talk a lot -- but separately -- about Ruby and Rails having low barriers to entry. "Ruby gets out of your way," I've been hearing over the years, "so you can concentrate on your goals." And Rails gets described frequently in similar terms.

I happen to agree, in both cases.

Of course this doesn't mean that someone chosen at random off the street can write working Ruby code or get a Rails application up and running. Low is relative; you have to be pretty comfortable already with the programming process to reap the rewards of transparent programming technologies. You have to have a way, before Ruby or Rails can get out of it.

Ease of use is also relative to the user. As we know from a couple of decades of Usenet and other on-line discourse, there is no such thing as consensus on programming tools. It's nauseating to think of all the rhetoric wasted - yes, wasted, every syllable of it - on the non-existent process of people convincing each other to switch tool sets. (I've been reading Usenet and other forums since 1990. I have never seen anyone convince anyone to switch to anything.) So there's no point bothering to claim that a given language or framework is actually more transparent or better organized or easier to use than another.

But when you hear the same technologies acclaimed in the same terms over and over again, you have at least got something to remark on and talk about.

In theory, at least, programming languages and systems like Ruby and Rails are instrumental; that is, like a musical instrument, they are a means to an end, a tool for accomplishing a goal, not a goal in themselves. However, just as musicians identify with the history, culture, and technical peculiarities of their instruments, so too do programmers identify with their languages and systems. Yes, you can describe a programming task algorithmically, and then implement it in any of hundreds of languages - just as you can play a given tune on any of hundreds of instruments. But that's not how it ends up happening.

There are lots of interesting analogies between being a musician and being a programmer. Some of them, moreover, have to do with the question at hand, the question of ease of access.

Violinist Itzhak Perlman has described the difference between the violin and the piano in these terms - not that one is easy and the other difficult, over the long haul, but specifically that the piano, unlike the violin, gets out of your way. Says Perlman:

Violinists have a harder time to make pure music than pianists, because pianists ... are immediately forced to turn the phrase. They don't have to deal with vibrato, they don't have to deal with shifting, they don't have to deal with sliding, they don't have to deal with bow-speed .... [On the piano,] basically you put down the key and you get a sound.... You have to deal with music immediately.

In this light, the piano emerges as the Ruby, or the Rails, of the musical instrument kingdom

Perlman characterizes the low entry barrier as a responsibility: pianists can't postpone their responsibility to produce beautiful music, because they don't have the excuse of mechanical difficulty with the instrument. (That's not to say it's easy to play the piano well, but only that you can literally drop a book on a piano and get something. You can't do that with a violin.)

Bragging rights - not the Perlman brags, but he leaves the question playfully hanging - belong to the musicians who play the high-barrier instruments. They produce beautiful phrases against much higher odds. In the computer world, however, the bragging rights go to those whose tools do get out of their way. And Ruby and Rails both come in for their share of getting bragged about.

But the separate discourses about Ruby and Rails, and their approachability is not as remarkable as a third term in the equation - a counterpoint to the main themes, so to speak. And that's the often-expressed doubt or concern about whether or not Rails developers should take the time to master Ruby.

The question is understandable, from one perspective. The fact that both Rails and Ruby have the "easy access" reputation doesn't mean that they're both easy for the same people, or in exactly the same ways. System S doesn't have to have the same difficulty level as Language L, just because it's written in Language L. Ruby, for example, is written in C, and whatever people say about C, it's usually not that it's easy to get started with.

I've seen the case made against mastering Ruby on two separate grounds:

• Rails is easy, but Ruby is much more advanced (too high level, in the sense of difficult).
• Rails is the system; Ruby is the raw material (too low level, not in the sense of easy).

The thing about both of these positions is that either of them could have been right - and may indeed be right-, with respect to some future Ruby framework or library yet unborn. But neither of them correctly describes the relationship between Ruby and Rails.

The key here is the way Rails is engineered. Rails invites to the use of the resources of the Ruby language by developers. Yes, Rails is in many ways a system in itself. But in many, many other ways, Rails exposes, explores, and exploits its connections to Ruby, rather than hiding or disguising them.

Take one example: helper files. A helper file gets created for you every time you generate a controller. The helper file is empty: it's a place where you can put Ruby methods that you write and that you want to call from your view templates.

There's no abstracting away from Ruby here, no encapsulation of Ruby into a separate domain-specific language, no Wizards Only sign on the door. There's just space - space provided by Rails for your custom Ruby code, space provided so that you can add Ruby code to your application.

Rails encourages you to use Ruby, and to know Ruby. Ruby is neither too hard to use nor too low-level to be of direct, immediate help in your Rails work.

Are Ruby and Rails equal partners, in a simple side-by-side relationship? No; it's more complex than that. Ruby is the antecedent and foundational technology; and Rails does, in some respects, present you with an altered, purpose-driven Ruby environment.

And yet - when you're writing a Rails application, Ruby really does feel like a kind of partner technology. Think of the relationship between XML and XHTML (or any other XML application). One is a system; the other is a system written using the first system. Yet they're both called "markup languages". The naming scheme collapses a level of indirection.

With Ruby and Rails, it's sort of the opposite. The names are distinct, but the technical relationship is very egalitarian.

Or maybe egalitarian isn't exactly the right word. Maybe there is no single right word to describe the Ruby/Rails ratio. Perhaps it's a case for duck typing, the principle that it doesn't really matter what an object is, in terms of class and module, but only what it does. When you're developing a Rails application and you decide you need to write a Ruby method to help you do it, it really doesn't matter whether or not you have a word for the relationship between language and framework. You just reach for what works: Rails facilities, Ruby core classes, plugins, Ruby libraries, methods you write yourself....

It all flows into the same stream.

About the author

David A. Black (dblack@wobblini.net) is the author of Ruby for Rails, from Manning Publications, and a co-director of Ruby Central, Inc., the parent organization of "RubyConf" and "RailsConf", the annual International Ruby and Rails conferences. David provides Ruby and Rails consultancy and training through Ruby Power and Light, LLC (http://www.rubypowerandlight.com).

Filmography

Interview with Itzhak Perlman, in The Art of Violin, dir. Bruno Monsaingeon, 2000.

• Older >