Matz is accepting RCRs (Ruby Change Requests) for Ruby 2.0 and Rite until
the end of March. Tell the truth, is there something in Ruby that you
wished worked a little differently? If so, now is your chance to stand up
and be counted.
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
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
Before You Write an RCR
Before you write an RCR, make sure you cover the following bases.
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.
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
SolicitFeedback. 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
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.
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.
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.
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
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.
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.