Find file
Fetching contributors…
Cannot retrieve contributors at this time
46 lines (25 sloc) 6.16 KB

And I for one welcome our new insect overlords

Rails v2.3/3.0 includes Chris Wanstrath's #try baked into ActiveSupport. What this means is that for people writing Ruby on Rails applications, the debate over nil handling is over.

That's right, the debate is over. No andand, no turtles, no ergo, no rescue nil.

Ladies and gentlemen, uh, we've just lost the picture, but what we've seen speaks for itself. The Corvair spacecraft has apparently been taken over -- 'conquered' if you will -- by a master race of giant space ants. It's difficult to tell from this vantage point whether they will consume the captive earth men or merely enslave them. One thing is for certain: there is no stopping them; the ants will soon be here. And I for one welcome our new insect overlords. I'd like to remind them that as a trusted TV personality, I can be helpful in rounding up others to toil in their underground sugar caves. --Kent Brockman

You'll notice there was no blogghorea, no endless whining about the name or whether symbols should be used or what colour the Core Rails team should paint the bike shed. The decision was made on your behalf. Rails applications should use #try.

We can wring our hands and philosophize about the whole thing, but this is the consequence of two forces interacting. First, Ruby's Smalltalk-like class architecture where changing a class has global effect. Therefore, any feature added to a core class like Kernel or Object for the convenience of a framework or gem is forced upon anyone using that framework or gem. If David likes having methods like #second, #third, and #fourth for his own purposes, you get them too. If he wants to have #try, then you get to have #try.

Second, The Rails philosophy of being a monolithic framework, or as David prefers to put it, A collection of defaults. That has benefits. A few years from now, there won't be anyone looking at a Rails code base and asking "What does #try do?" It will be standard, so everyone will know it. The down side, of course, is that there's a lot more documentation to read.

The larger a framework gets, the harder it is for someone to read the entire documentation and understand how all the parts fit together. After you've used it, you understand whether #try is important or not. But until then, you have to learn it all and you have no idea of whether #try is something that should be a pervasive idiom or simply a little trinket tossed in because it's handy.

Put the two factors together and you have what amounts to Rails becoming a large dialect of Ruby, with its own specific way of expressing certain programming ideas, and a central force that is dictating its evolution as a language.

But before protesting too loudly, remember that it could be worse. I recently discovered that despite a great deal of interest, closures will not be in the next official release of the Java language. It seems nobody could agree on how they should work, so the committee decided not to decide. If David Heinemeier-Hansson wasn't the type of person to decide what to do, Rails would be running on .NET today.

So, if you want to program "The Rails Way," start using #try. If "The Rails Way" doesn't suit you, you might want to have a look at Merb. It is based on a different philosophy, the assumption that it shouldn't dictate these things to you.

You have a choice.

p.s. A must-read: Try() as you might:

How wrong could I be when just a few minutes ago I wrote, with apparent misplaced confidence, that I'd accept the danger of anyone actually contributing a different try method. They might as well deliver me over to the mad doctor of blood island right now! No point in postponing the horrors that are my fate.

My recent work:

JavaScript AllongéCoffeeScript RistrettoKestrels, Quirky Birds, and Hopeless Egocentricity

(Spot a bug or a spelling mistake? This is a Github repo, fork it and send me a pull request!)

Reg Braithwaite | @raganwald