Nick Sieger: RubyConf: Matz Keynotetag:blog.nicksieger.com,2005:TypoTypo2010-11-22T18:17:31+00:00Nick Siegerurn:uuid:84824f7d-b010-4850-8e33-4f41df8179f72006-10-22T03:41:22+00:002010-11-22T18:17:31+00:00RubyConf: Matz Keynote<h1>The Return of the Bikeshed</h1>
<h3>or Nuclear Plant in the Backyard</h3>
<h2>Ruby is</h2>
<ul>
<li>Scripting (some people outside of Japan don’t like this one)</li>
<li>Programming (sure, it is)</li>
<li>Lightweight (see <a href="/articles/2006/10/20/rubyconf-history-of-ruby">Takahashi-san’s history</a> -- LL is a popular term in Japan)</li>
<li>Dynamic</li>
</ul>
<p>The agile manifesto claims 4 values. It encourages developers to act responsibly. What if these values were applied to programming languages?</p>
<ul>
<li>Individuals and interactions: language design should focus on users (i.e., developers).</li>
<li>Working software: language should encourage readability</li>
<li>Collaboration over contracts: expressive language, which helps communication.</li>
<li>Responding to change: language should embrace change</li>
</ul>
<p>Thus, Ruby is:</p>
<h1>The Agile Language</h1>
<h3>The Good, Bad, Ugly of Ruby</h3>
<h2>Good</h2>
<ul>
<li>Sweet language</li>
<li>RoR</li>
<li>Ruby people are nice (Martin Fowler -- “because Matz is nice”)</li>
</ul>
<h2>Ugly</h2>
<ul>
<li>eval.c</li>
<li>parse.y</li>
</ul>
<h2>Bad</h2>
<ul>
<li>Ruby 2 vaporware -- close to longest in open source (Rite > Perl6)</li>
</ul>
<h2>Bikeshed</h2>
<p>What is the bikeshed? (FreeBSD people hate the bikeshed.)</p>
<p>People tend to argue about little things that they know enough to do so. The amount of noise related to change is inversely proportional to the complexity of the change. Thus leaving important things behind.</p>
<p>The nuclear plant is too complex, so we leave it up to experts to think about it. As a result, we spend time on unimportant things.</p>
<ul>
<li>Symbol < String</li>
<li>#lines</li>
<li>removing private and protected</li>
</ul>
<p>Thus leading to suggest that Ruby is a...</p>
<h2>Fragile language</h2>
<ul>
<li>Ruby 1.8 is good enough! We’re not in a hurry.</li>
<li>Extreme arguing -- why not make everything easy enough to be argued by everyone?</li>
</ul>
<h2>Design game</h2>
<ul>
<li>Gather wild ideas</li>
<li>Try to make it the best language ever? (We feel good about Ruby, but I don’t know why.)</li>
<li>Shed light on undefined corners of Ruby</li>
<li>Document a specification</li>
</ul>
<p><a href="http://www.rcrchive.net/">RCRchive</a> so far hasn’t worked out, because a few people took it too seriously.</p>
<ul>
<li>Ruby will stay Ruby, but it shouldn’t be a vague idea. Rationale, analysis, discussion, with a prototype implementation</li>
<li>I (Matz) will stay the benevolent dictator, but will promise to be as open as possible.</li>
<li>80-90% compatibility. It can break, but we have to keep the same philosophy that we love.</li>
</ul>
<p><em>Hey, we need optional explicit typing in Ruby!</em> So what!</p>
<p>Look at Python, it has a very organized (ahem, strict, something [laughter]) PEP system that seems to be working well. Mailing lists are more suitable for discussion. Use RCRchive as a starting point, but use a new system/channel for each proposal. Prototypes are needed. Running code accelerates the discussion.</p>
<p>Why should we start this game? I want to share language design with the community. I’m tired of the slow evolution of Ruby. We’re using 3-year-old technology. We need to catch up, so that people aren’t saying “Ruby, we had that language a long time ago!” Educating the developer community is a great venue for learning about language design.</p>
<p>I may be hit by a truck someday, in which case Ruby will be Ruby 1.8 forever! In that case you can do whatever you want with 1.9.</p>
<p>Considering a submission deadline -- 2007-04-30, but it might not be needed. Classify proposals under GBU (Good, bad ugly), plus version (1.9 or 2.0). Implement them. Merge them. If it doesn’t work out, we’ll try another thing. We lose nothing but time. See you next year, hopefully with good news! Ruby 1.9.1 stable (but bleeding edge) will be out Christmas 2007.</p>
<h2>Q & A</h2>
<p><em>Q. Following the Agile tenets, perhaps we should submit tests and specs that document the feature?</em> [Missed the answer, perhaps it was agreement on the part of Matz?]</p>
<p><em>Q. Maybe you should leave 1.8 for others to maintain?</em> I’ll stay on 1.8 and there will be contributors to help with the new features going forward.</p>
<p><em>Q. You mentioned parse.y as ugly -- how would the parser become more accessible?</em> I have no concrete plan, but I’d like to create a simpler parser. <em>Would you be open to non-BC parser changes?</em> If someone raises their hand to make a new parser, I’ll discuss the compromises needed. <em>What about participation of the VM design? (e.g., I like Smalltalk can I try that out?)</em> I have no opposition to alternate implementations of 1.8 or 1.9, but it’s difficult to target 1.9 (moving target). Koichi took his role as chasing the moving target, and he suffers a lot. I’m sorry for him.</p>
<p><em>Q. With corporate support and alternative implementations, how worried are you about fragmentation?</em> I don’t worry about it. I don’t have any trademark on Ruby or any business on it. It’s more like a competition -- may the best interpreter win. Some will be fast, some will be stable, we can compare them.</p>
<p><em>Q. I like the aesthetic in Ruby. Can you push forward the beauty of the language, or are you happy as it is?</em> I’m not sure how much room we have left. 1.8 may be good enough. During the discussion, we’ll see.</p>