RubyConf 2006—Day 2 (Matz’s keynote, Saturday, 21 October 2006

---

This article was modified from its original published form. The most recent modification was on2014-09-25.

---

Series: RubyConf 2006

Matz’s keynote this year was entitled “The Return of the Bikeshed, or Nuclear Plant in the Backyard”.

Ruby is often seen by people as either a scripting language (which in the West is often seen as derogatory), a programming language (so vague as to be useless), a lightweight language (popular in Japan), and a dynamic language (relatively new). Matz applied the insights of the Agile Manifesto to programming languages (Steve Yegge is right that most people take the Agile Manifesto wrong and do it wrong; Steve Yegge is wrong in thinking that it’s therefore useless).

• Individuals and interactions over processes and tools: the language design should focus on users.
• Working software over comprehensive documentation: the language should encourage readability.
• Customer collaboration over contract negotiation: the language should be expressive, and helps communication between developers.
• Responding to change over following a plan: the language should embrace changes, and be dynamic.

Looking at this, Matz concludes that Ruby is an Agile Language.

Matz noted that Ruby has Good things (it’s a sweet language, Rails, the community—as Martin Fowler says, Ruby people are nice); Ugly things (eval.c, parse.y); and Bad things (Ruby 2 being vapourware for such a long time: it’s close to being the longest vapourware in open source—Rite the concept is older than Parrot and Perl 6)¹.

The Bikeshed represents an easy problem. People tend to argue about little things that they know enough about to do so, such as what colour a bikeshed should be. The amount of argument caused by a change is inversely proportional to the size of the change. Ruby has several bikesheds: the discussions on String and Symbol; the possible removal of private and protected; whether Ruby needs (optional) static typing.

On the other hand, nuclear plants are complex and important, so we tend to leave discussing them to the experts. So we spend most of our time discussing relatively unimportant things, leaving important things yet to be discussed.

Some consider Ruby a fragile language, but Ruby 1.8 is generally good enough. This means that although Matz would like to get Ruby 2.0 out, we’re not in a hurry and each idea has its own value which must be discussed. Instead of stopping bikeshed arguments, Matz says we should accelerate them: Extreme Arguing. If arguing is good, we should make things easy enough to be argued by anyone.

The RCR process hasn’t worked out as well as Matz wanted it to. Some people didn’t take RCRs very seriously; some took RCRs far too seriously. Thus, Matz is introducing what he calls the Design Game. The purpose of the Design Game is to open language design to everyone in an accessible manner. It will:

• Gather Wild & Weird Ideas
• Try to make Ruby the Best Language Ever
• Shed light to undefined corners of Ruby
• Finally (if possible), document Ruby specification.

There are some fundamental rules of the Design Game:

1. Ruby will stay Ruby. We’re not creating a new language or a new Smalltalk or a new Lisp. About 80–90% compatibility will be preserved, if not more. Each proposal must follow the same philosophy we love about Ruby.
2. Design Game proposals must not be vague ideas. It’s hard to impossible to start useful discussions with vague ideas.
3. Design Game proposals must have rationale and analysis. Entries that don’t have a rationale and analysis section will be rejected out of hand. Matz will probably use a format similar to the Python Enhancement Proposal (PEP).
4. Discussion will happen on one or more mailing lists, possibly a single mailing list per proposal. RCRchive² will probably be a starting point, but there may be a new system to control traffic: possibly qwik or trac³.
5. Proposals with a prototype implementation will be favourably smiled upon as concrete code helps a fruitful discussion.
6. Matz is still the Benevolent Dictator…but promises to be as open as possible.

Matz is doing this because he wants to share the fun of language design among the community and is tired of the slow evolution of Ruby (despite him being the bottleneck). Most of us are using technology from three years ago and if we (Ruby) don’t accelerate, others will catch up. This is also to help educate developers in the community: language design shares much in common with other software design. Additionally, Matz wants the process to be continuable if he were to be hit by a truck (heaven forfend).

Matz may or may not set a deadline for the Design Game and has tentatively considered 2007-04-30 as such a date. After that, we (the community) will classify proposals as either Good, Bad, or Ugly and as targeted for 1.9 or 2.0. The good proposals will be implemented, and if they are ready, they will be merged. If the game doesn’t work, it’s not a problem: we’ll try something else, we’ve lost nothing but time.

Matz is still planning on releasing a stable version of Ruby 1.9 (1.9.1) for Christmas 2007 with YARV and other changes to come.

Matz’s keynote slides

Important notes:

• The Game will apply to changes to core and standard libraries, but core is preferred.
• They will be keeping up with Windows changes as Vista came.
• Not necessarily for enterprisey stuff.
• Tests should probably included with proposals, too.
• The parser could theoretically be replaced in a non-backwards-compatible form.

---

• 2014-09-25: The original version of this article was written as a travelogue stream-of-consciousness that was a little hard to read. I have tried to make it a bit clearer, and have added some comments about how things have turned out in the years since.[ back ]

---