The Ruby Nuby Syndrome

I’ve noticed a trend on the ruby-talk mailing list. A nuby appears on the list, likes the language, except for one minor nit. Wouldn’t it be nice if Ruby would do (insert fix for minor nit here). A nit might be Ruby’s lack of overloaded functions, static typing, explicit interfaces, or anything else in Language X that is different in Ruby.

Now there is nothing wrong with static typing or interfaces. It is just that these topics have been hashed out on ruby-talk over and over again.

How Ruby Sucks

Don’t get me wrong. Ruby isn’t perfect by any means. In fact, I thought the Matz’s Keynote speech at the 2003 RubyConf was particularly healthy. Matz titled his talk "How Ruby Sucks" and then detailed the direction Ruby was moving for version 2.0.

And now that the features of Ruby 2.0 are beginning to solidify in Matz’s mind, he is encouraging Ruby Change Requests (RCRs) to be submitted through March at the RCRcive.net site.

But before you go and write up your favorite change request, consider the following.

Before You Write an RCR

Before you write an RCR, make sure you cover the following bases.

1. Research. Has this change been requested before? Search the ruby-talk archives (Google is your friend). Also read the list of RCRs, both current and legacy entries to see if there are similar RCRs. Be sure to read and understand any issues raised during any previous discussions.
2. Investigate. What would it take to implement your RCR. Can you simulate it with Ruby code today? What are the tradeoffs? Are there performance issues? Are there complexity issues? What about backwards compatibility?
3. Solicit Feedback. If your suggestion is way out there, perhaps it would be wise to get feedback before you write up your RCR. It wouldn’t hurt to post a message on ruby-talk saying "I’m considering writing an RCR on XYZ, am I on track here?". Many ruby-talk members are tired of the same-old changes being discussed over and over again, but if you’ve made it past the research and investigate phase, a ruby-talk message would not be out of line. The feedback you get may help you tighten up the RCR.

Writing the RCR

Once you are ready to actually write the RCR, do the following

1. Read the Submission Guidelines and Suggestions for submitting an RCR.
2. Fill out each section of the RCR submission form. Pay special attention to the purpose of each section. The RCR submission help page goes over the sections, so I won’t repeat the information here.
3. Remember the purpose of the RCR is to convince Matz and other Rubyists that they would benefit from your proposed language change. Clearly lay out what the perceived problem is and exactly how your proposal addresses that problem. Don’t skimp in the Analysis section, but carefully layout both the pros and cons to your RCR. Good, compelling examples are worth their weight in gold.
4. If there is any way possible, provide an implementation of your suggestion. If your suggestion cannot be done in the current version of Ruby, approximate it as best you can. If you can’t provide a full speed implementation, provide a slow one (but include performance analysis as appropriate). Working code speaks much louder than vague suggestions.
5. Don’t bother to invoke POLS (Principle of Least Surprise) as a justification for the RCR. Matz is the final arbiter of what is surprising and what is not, and telling him what his expectations are will not advance your position.

After You Write Your RCR

1. Go back to review and comment on other RCRs. Make sure you vote too. But remember, the voting is only there to provide Matz with some indication of the interest in a given feature. This isn’t a democracy, Matz still makes the final call.
2. Listen to feedback on your RCR. Several RCRs have already been withdrawn or rewritten based on the feedback provided by the RCR process.

It’s an exciting time for Rubyists, we are beginning to get a picture of what Ruby 2.0 might be like. So if you have an RCR in mind, please go ahead and submit it.

Just make sure you do the homework too.