Rubyconf Wrap-Up

Posted by Nick Sieger Tue, 24 Oct 2006 22:51:55 GMT

Whew! Back home from my first RubyConf, it’s taken me a couple days to collect some parting thoughts. As you might have noticed, I was pretty busy last weekend.

First of all, what an awesome and welcoming community. It’s going to sound cliché, but there are so many intelligent and motivated people walking around that you can’t help but be inspired to roll up your sleeves and get your hands dirty.

There were definitely some high points for me. The beauty and power of the language, even after using it for almost two years, still amazes me. Pretty much every piece of code I saw, whether in a presentation or looking over someone’s shoulder, had a clear purpose and communicated its intent better than any general-purpose machine language I have seen. The simplicity of Evan’s new Ruby-in-ruby VM, the syntax integration tricks of John’s RubyCLR project, the forthcoming RubyOSA APIs, and Geoffrey’s graphics programs, are all great testaments to Ruby’s power.

There was an implementer’s summit on Friday night, which I attended (see also coverage here and here). There are now at least 8 active implementations of Ruby (Ruby, Yarv, JRuby, Cardinal, Rubinius, MetaRuby, Ruby.NET, IronRuby), and two interop bridges (RubyCLR and RubyCocoa)! The biggest news was that there are plans to revive the Ruby testing project (formerly the Rubicon) and share as many tests as possible among the implementations.

RejectConf was a huge success, due largely to the indefatigable Adam Keys. Kevin Tew has a decent wrap-up of the talks that occurred. Charlie’s demo of NetBeans in-place refactoring feature drew a couple oohs and ahs and even one f-bomb. Heckle, in time, should be an awesome tool as well. Big thanks to zenspider for coordinating it. It’s destined to become an annual tradition. Perhaps the organizers of future RubyConfs could account for it in the budget?

On a lighter note, there were quite a few humorous moments that kept popping up. A summary may read like a list of inside jokes, so here’s some context. THAT GUY is a reference to a disclaimer in Zed’s talk about the know-it-all guy who always pipes up during your talk with skepticism. THAT GUY kept getting called out during the rest of the conference. Ani, the developer evangelist from Microsoft was pretty thick-skinned. She was heckled constantly about MS, Vista, and everything else, and still kept a smile on her face. And of course you already watched Adam’s one-act play, right?

My note-taking streak wasn’t quite perfect; I didn’t take notes Kevin’s mkmf talk nor Rich’s talk about indi, and I slept in and missed Justin’s Streamlined talk. Also, the beer was flowing for RejectConf, and despite the quality summer of code talks, I was spent. Fortunately, you can fill in the blanks by following along with Curt Hibbs and the rest of the blogosphere. Thanks for tuning in, and I hope you got something worthwhile here. See you next year!

Tags ,  | 2 comments | no trackbacks

RubyConf: Your Ruby in My CLR

Posted by Nick Sieger Mon, 23 Oct 2006 14:16:00 GMT

John Lam wanted to build a photo-flash-card application using Avalon and Indigo and Flickr, but also using Ruby as the implementation language. So along the way he decided to build an interop layer (a bridge) between Ruby and the CLR to do it.

Now that John has joined Microsoft, his new mission (bigger picture) is to further dynamic language implementations on the CLR.

Bridging type systems

  • Dynamic methods in the CLR allow you to do better than simply invoking the reflection API.

    Ruby          |  C               |  CLR
    shadow class  |  dynamic method  |  instance
  • Polymorphic inline caching -- caching method dispatches on different call sites based on the assumption that types don’t change that often

  • Generate shadow classes and method stubs using const_missing and method_missing
  • Overload resolution happens in the method shims (a one time cost) to choose, e.g., which constructor to use for
  • Integration is done to make the CLR feel more Rubyish


  • This changes identity (proxied object):
  • This is less Rubyish, but identity is preserved:


There are trade-offs and warts to a bridge approach to Ruby integration on top of a platform such as the CLR: there is a need to inject artificial type information occasionally to be able to construct CLR objects (e.g., arrays -- Array.of(Int32).new(3)). Generics are evil! Simple stuff doesn’t seem so bad: List.of(Int32).new, but there’s more pain to be had (see John for details). John also built a RubyInline-like implementation for the CLR languages too, to allow for getting things done (even if it’s dirty). Finally, method overloading is a problem, especially when there is no equivalent Ruby type -- this gave way to instance_shim which is a sort of aliasing method that mixes in type metadata for use by the interop layer.

On the other hand, there are many places where Ruby (even in bridged mode) can make the experience of developing on the CLR better. Implementing CLR interfaces is a feature that allows Ruby objects to cross to the CLR side, (e.g., adding IEnumerable to Ruby Array). Performance across the CLR boundary (marshalling data) is ~100 times slower than C#, but still fast (3 million calls/second). Huge benefits are gained from using DSLs in Ruby to help with the implementation of the interop layer. Also, RubyCLR allows mixing in methods into CLR types, so we can re-skin APIs that feel clunky in Ruby. This is really leveraging the power of Ruby in the best possible way.

My take is that it looks like the RubyCLR project will probably not be seeing much further development, unless John finds a willing maintainer -- but this is speculation, I haven’t confirmed with John. Yet, the problem of impedance matching between type systems is a recurring theme in the dynamic language arena, and so John’s work is valuable in helping us to understand this issue.

More Info

Posted in  | Tags ,  | 3 comments | no trackbacks

RubyConf: YARV on Rails

Posted by Nick Sieger Mon, 23 Oct 2006 14:15:00 GMT


Update: corrected performance numbers -- 20x, not 20%!

  • Got a job developing YARV at the University of Tokyo! He’s now employed at Akhihabara, Otaku City.
  • Member of Nihon-Ruby-no-Kai
  • Present at RubyKaigi 2006 (200 tickets sold in 3 hours). RubyKaigi 2007 will be June 9-10 (Saturday and Sunday).
  • Member of Nihon-Perl-no-Kai
  • Co-author of Perl book on Parrot in Japanese


  • [Demo creating Rails app]
  • Create app with YARV (rails foobar)
  • Edit config/boot.rb, add a GC.disable line (there’s a bug to be fixed when he gets back to Japan).
  • Start up WEBrick, and it works!


  • Rite: code name of Ruby 2.0 (a.k.a. vaporware!)
  • YARV: Yet Another Ruby VM


  • Supported by funds from IPA (now finished)
  • Simple stack machine, with VM instructions, a compiler and interpreter
  • Optimization techniques to improve performance
  • Open source

Optimizations include compile-time optimization, native threading, specialized instructions, instruction unification, inline method cache, and stack caching. YARV can build with configure/make, but doesn’t work with AC 2.6 (maybe you know why?). It passes most of the Ruby tests, but misses a few due to implementation differences.

[Koichi showed a demo controlling iTunes on Windows with Win32/OLE with YARV, and a native-threaded scenario in IRB.]

Myths of YARV: YARV is great! YARV will solve all problems! It makes Ruby programs go 50 times faster! It solves character issues! It finds your girlfriend!

Truths: YARV is for running Ruby programs, fast. It provides up to a 20x speed up for some algorithm benchmarks (Ackermann, Fib), but not for others [graphs shown]. You assemble and disassemble YARV instruction sequences, or serialize and de-serialize them. They are just Ruby literals, so they can be packed in YAML or some other human-readable format.

require 'yasm'
require 'yaml'

iseq = YASM.toplevel([:a, :b]) {|ib|

p iseq.to_a.to_yaml # => (gave a readable YAML view of the assembly)


  • Ruby thread is mapped 1:1 to a native thread
  • Supports POSIX and Win32
  • Many existing Ruby libraries are not synchronized at the C level, so many C libraries need synchronization added to them
  • Thread model 2: 1:1 mapping, with a Giant Lock (GL). Only the thread that has the lock can run. No need for sync, but no parallelism
  • Thread model 3: Ruby threads in parallel, but when thread-unsafe code is executing, GL needs to be obtained
  • Mutex class will become builtin
  • Thread.critical will vanish (not obsolete, but unsupported) [this was a controversial point for some -- the comment was that it’s a near impossibility to keep it with a native threading model though, the two are in compatible]

Matz: 1.9.1 in 2007 Christmas, but Ruby 1.9.1 is also to be merged with YARV, so Koichi hopes to complete the merge by spring or summer 2007. Thread model 2 will need to be used to begin with.


  • set_trace_func hook functions -- what to do here? [It was suggested by Charles Nutter to remove it, to which Matz replied that we could as long as we have a good replacement debugging API.]
  • Catch up with Ruby 1.9
  • JIT/AOT compiler (AOT compiler started but incomplete)
  • Koichi also has a side project: high-performance Ruby, with the goal of making it easy to write performant code.


More developers and testers are welcomed to the project!

Posted in  | Tags ,  | no comments | no trackbacks

RubyConf: Matz Keynote

Posted by Nick Sieger Sun, 22 Oct 2006 03:41:22 GMT

The Return of the Bikeshed

or Nuclear Plant in the Backyard

Ruby is

  • Scripting (some people outside of Japan don’t like this one)
  • Programming (sure, it is)
  • Lightweight (see Takahashi-san’s history -- LL is a popular term in Japan)
  • Dynamic

The agile manifesto claims 4 values. It encourages developers to act responsibly. What if these values were applied to programming languages?

  • Individuals and interactions: language design should focus on users (i.e., developers).
  • Working software: language should encourage readability
  • Collaboration over contracts: expressive language, which helps communication.
  • Responding to change: language should embrace change

Thus, Ruby is:

The Agile Language

The Good, Bad, Ugly of Ruby


  • Sweet language
  • RoR
  • Ruby people are nice (Martin Fowler -- “because Matz is nice”)


  • eval.c
  • parse.y


  • Ruby 2 vaporware -- close to longest in open source (Rite > Perl6)


What is the bikeshed? (FreeBSD people hate the bikeshed.)

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.

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.

  • Symbol < String
  • #lines
  • removing private and protected

Thus leading to suggest that Ruby is a...

Fragile language

  • Ruby 1.8 is good enough! We’re not in a hurry.
  • Extreme arguing -- why not make everything easy enough to be argued by everyone?

Design game

  • Gather wild ideas
  • Try to make it the best language ever? (We feel good about Ruby, but I don’t know why.)
  • Shed light on undefined corners of Ruby
  • Document a specification

RCRchive so far hasn’t worked out, because a few people took it too seriously.

  • Ruby will stay Ruby, but it shouldn’t be a vague idea. Rationale, analysis, discussion, with a prototype implementation
  • I (Matz) will stay the benevolent dictator, but will promise to be as open as possible.
  • 80-90% compatibility. It can break, but we have to keep the same philosophy that we love.

Hey, we need optional explicit typing in Ruby! So what!

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.

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.

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.

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.

Q & A

Q. Following the Agile tenets, perhaps we should submit tests and specs that document the feature? [Missed the answer, perhaps it was agreement on the part of Matz?]

Q. Maybe you should leave 1.8 for others to maintain? I’ll stay on 1.8 and there will be contributors to help with the new features going forward.

Q. You mentioned parse.y as ugly -- how would the parser become more accessible? I have no concrete plan, but I’d like to create a simpler parser. Would you be open to non-BC parser changes? If someone raises their hand to make a new parser, I’ll discuss the compromises needed. What about participation of the VM design? (e.g., I like Smalltalk can I try that out?) 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.

Q. With corporate support and alternative implementations, how worried are you about fragmentation? 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.

Q. I like the aesthetic in Ruby. Can you push forward the beauty of the language, or are you happy as it is? I’m not sure how much room we have left. 1.8 may be good enough. During the discussion, we’ll see.

Tags ,  | no comments | no trackbacks

RubyConf: Natural language generation and processing in Ruby

Posted by Nick Sieger Sun, 22 Oct 2006 00:07:34 GMT

Speaker: Michael Granger

Michael’s talk was full of excellend pre-recorded video demos, and thus was difficult to note-take. Instead, here are links to most of the pieces of software he discussed for your perusal:

Tags ,  | 1 comment | no trackbacks

RubyConf: I18n, M17n, Unicode, and all that

Posted by Nick Sieger Sun, 22 Oct 2006 00:06:00 GMT

Tim Bray is going to talk about characters and strings. He will gladly talk about text until your arm falls off, and buy half the beer.


English is no longer the majority language on the web. It’s nonsensical to ignore i18n issues with new apps.

This is probably a bug:


Problems to solve to help us with i18n

  • Identifying characters
  • Byte-character mapping and storage
  • A good string API


  • Worlds writing systems
  • Character model for the web (W3C)
  • The Unicode 5.0 Standard (forthcoming book) (same as ISO 10646)


  • Numbers identified by code points (> 1,000,000)
  • 17 Planes each with 64k
  • Original characters (available in any computer anywhere before Unicode was invented) in Basic Multilingual Plane (BMP, first plane)
  • Characters identified as U + (4 hex digits)
  • Unicode character database


  • Repertoire
  • Room for growth -- lots of space left in the middle planes
  • Private use
  • Sane process --
  • Character database
  • Ubiquitous standards and tools


  • Combining forms -- need to normalize the characters for comparison (1/2 vs. ½) and this is not something you want to do in your String#== method
  • Awkward historical compromises with other encodings
  • Han unification (note: Tim considers wikipedia article to be biased)-- characters that might mean something different were given one codepoint by asian linguistic specialists.


  • Official: UTF-8, UTF-16, UTF-32
  • Practical: ASCII, EBCDIC, Shift-JIS, Big5, EUC-JP, EUC-KR, MS code pages, ISO-8859-*, etc.

But with Video the largest bandwidth eater, does text size really matter?


How to identify what text is coming in over the wire?

  • Guess -- browsers, python lib
  • Charset headers, which are known to be wrong
  • Trust -- two partners agree in advance for a pattern of exchange
  • XML [this last one was quite obvious right]

Language approaches

  • Java -- design flaw; characters are UTF-16, which is unfortunate. Implementation is sound and well tested, but Java is clunky.
  • Perl 5 has excellent support in theory, but practically speaking, it’s difficult to round-trip text through a DB without some breakage.
  • Python has byte arrays and strings, some string-like methods on byte arrays, binary or text data, glosses over issue of plaform file encoding


  • Some core string methods have i18n problems due to counting, regexp, equality and whitespace concerns.
  • String#each_char seems to be a missing method; string class maybe should be aware of its encoding.
  • Behavior of String#[] seems ok for byte buffers but it probably doesn’t need to be efficient for characters. Most of the use-cases for String iteration should be for characters (exception: Expat)
  • Case-changing methods -- avoid them at all costs in a mixed language environment!
  • Regexps need unicode properties for safer matching (p{L} for lower-case letters, p{N} for numbers)
  • Does Ruby need a Character class or a Charset class?

What is next for Ruby? [Tune your divining rods toward ruby-talk for the rest of the story!] Matz has m17n; Julik, Manfred and crew now have ActiveSupport::MultiByte in Rails; JRuby is built on a platform that already has a Unicode string, so the discussion is heating up.

Update: slides available here.

Q & A

Q. What if I have a stream of bytes with no knowledge of encoding? Don’t try to impose an encoding lens above the level of a string, programmers want to treat a string as a string with associated methods.

Q. What if I need to change case of text? Get used to the fact that it won’t work reliably work. What about characterizing the finite amount of languages? Java does that, and it’s still not really possible. Shouldn’t the string class know the encoding? Couldn’t it optimize better? Couldn’t you raise an exception? Just don’t do it! Isn’t there a body of knowledge that could be acquired about case? Hmm, next question that isn’t about case!

Q. Is there a resource for edge cases of processing text in XML? Search for “xml test cases”. The decision is between ignoring the metadata provided, and choosing not to process it.

Q. What is the python library that can guess the charset? It’s in the feedvalidator suite.

Posted in  | Tags , ,  | 3 comments | no trackbacks

RubyConf: Rinda in the Real World

Posted by Nick Sieger Sat, 21 Oct 2006 19:01:35 GMT

Speaker: Glenn Vanderburg

Rinda is a distributed coordination system, by Masatoshi SEKI, based on work by David Gelernter (called Linda). It’s similar to JavaSpaces, but more in the Ruby spirit. It uses DRb for communication (also by Seki-san).

There are several existing tutorials on Rinda, but none with a broad, real-world applicability. As Glenn started to go deeper with Rinda, flaws began to be exposed.

Rinda Basics

  • The TupleSpace is in the conceptual middle, as a bag of tuples “arrays”. Participants can write tuples into the space, or take them out (usually according to a set of conditions).
  • Tuples are usually requests to do some work by some unknown requester, or responses to that work.
  • A RingServer is a broadcast/multicast lookup service for finding Rinda tuplespaces.
  • Templates are used to find tuples to take. Template#match requires that the tuples have the same length, and that all the non-nil elements are triple-equal (===).
  • In practice arrays are always used in the #take and #write methods, and they’re implicitly converted to the appropriate object.

Protocol design

When you’re deciding what to store/read in the tuples, you’re essentially designing a communication protocol. So you need to take the extra precautions required as you would when designing any API or protocol, including documentation, evolution of changes, process workflow, etc.

  • Parts of tuples: command/request, identifiers, and associated parameters/data. Usually templates will match on the command, sometimes on the ID, but never on the data.
  • Strings work well in tuples, because you can use Regexps to select them.
  • Numbers work well, because you can match them with Ranges
  • Symbols don’t work so well (at least until Symbol < String)
  • Communication patterns -- synchronous communication is not a good fit for a Rinda architecture (e.g., a request for status)


DRb does not marshal code/behavior (unlike Java and RMI). This is a limitation that forces you to consider how to use custom objects in the tuples, because the code must be shared (and thus jointly upgraded) across all participants.

Multiple processes are probably more reliable for the various components of the architecture (RingServer, TupleSpace, clients) rather than using green threads, although this is just a hypothesis.

The TupleSpace is the single point of failure -- if the process with it crashes, when it starts back up, it’s likely to have a new DRb URL, so it’s helpful to have a proxy around the tuple space in clients that can rediscover it if it crashes.

Be wary of multiple ring servers on the same subnet! Behavior may be unexpected. You may notbe using the tuple space that you wanted, and when the other ring server goes away, so does your tuple space.

DRb does not have any security built into it, such as unforgeable object IDs, encrypted transport, authentication, etc. This can be a problem in some situations.

There is no persistence by default, so consider adding some for crash resistance, or deal with occasional loss of tuples.

There are no transactions, so the requester will never know if it still processing or was lost.

As Ruby matures and gains exposure, some libraries that have been good enough for a while may need reconsideration. As a case in point, Rinda and DRb haven’t been updated since February of 2004.

Q & A

Q. Are write/take atomic? Yes, if you timeout, the tuple will still be there. Two workers cannot get the same tuple.

Q. Where would you use this instead of traditional message queues (reinvent the wheel)? There’s more flexibility in this architecture. (Justin Gehtland) In this particular case, they have a JMS backend, but the Ruby code could not assume connectivity to that backend.

Q. Is there a common correlator design pattern? Tie response types to request types to limit the pool of potential matches. In the situation where there is a single requester, it’s simple to just generate sequential numbers. In a P2P situation, you may need to use a hostname or PID to help distinguish. [Sounds like a GUID/UUID system to me.]

Q. Have you used expiry dates to grab abandoned tuples? No, sounds like an interesting possibility.

Tags ,  | no comments | no trackbacks

RubyConf: Mac OS X and Ruby

Posted by Nick Sieger Sat, 21 Oct 2006 18:58:33 GMT

Laurent Sansonetti, who works at Apple Computer, is now in charge of maintaining Ruby inside the OS.

History of Ruby in the OS

  • 10.2 shipped with Ruby 1.6.7
  • 10.3 shipped with Ruby 1.6.8
  • 10.4 shipped with 1.8.4, and the latest software update has Ruby fixes to allow compilation of C extensions

Apple is actively looking to improve Ruby support in future versions of the OS in several areas:

  • Ruby.framework
  • 64 bit support
  • Controlling scriptable applications
  • Cocoa development


Why a framework? It’s easier for Mac development. It allows multiple versions, and lets you bundle Ruby inside your application. It’s also compatible with original layout /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Current/bin/ruby


  • Include IRB support, RubyGems, plus important gems: Rake, Rails, libxml2 and sqlite3 bindings, DNSSD (Zeroconf)

Controlling scriptable applications

Traditionally applications are scripted by AppleScript. Apple Events are the IPC glue between the two.

RubyAEOSA is a Ruby wrapper for Apple events, that was started in 2001, but not active since 2003. The code required is unnecesarrily verbose. Instead, you could wrap and execute with AppleScript, but it’s slower and limited by knowledge of AppleScript.

RubyOSA is a new project created by Apple, intended to be a successor to RubyAEOSA, under active development and used today. It has a much more Rubyish API, generating Ruby code on the fly and sending events lazily. Apple events are completely hidden.

require 'rbosa'

itunes ='itunes')
itunes.sound_volume = 0
100.times {|i| itunes.sound_volume = i; sleep 0.1 }

0.1.0 release is coming soon, gem install rubyosa.

Cocoa development

Mac development framework, mostly using Objective-C. RubyCocoa is a Ruby/Objective-C bridge, now under active development with support from Apple. It creates Obj-C classes to Ruby proxies and vice-versa. Messages and exceptions are forwarded, and types are converted.

It uses a message convention. ‘:’ are substituted with ‘_’ in the method name (selector). The final ‘_’ can be omitted, but can lead to ambiguities. It may be mandatory in a future release.

Some challenges remain in the Ruby/Obj-C bridge.

Problem: Speed of method invocation. Solution: libffi from gcc, allows invocation of arbitrary foreign function interfaces.

Problem: Maintenance. Currently RubyCocoa needs to be rebuilt to take into consideration new APIs, so to solve, a metadata framework is being built to allow the information to be more dynamic, and a metadata generator tool will help with creating a metadata file for new APIs

These latest developments are available from the apple-unstable branch in SVN from rubyforge.


  • “Toll free bridge” -- implement Ruby primitive types with CoreFoundation objects so that no type conversion is necessary
  • Garbage collection -- Objective-C will be getting garbage collection in the future, and the idea is to implement the Obj-C garbage collector in Ruby through Obj-C APIs.

Tags , ,  | 5 comments | no trackbacks

RubyConf: Nathaniel Talbott: Open Classes, Open Companies

Posted by Nick Sieger Sat, 21 Oct 2006 18:54:00 GMT

Update: Full text of Nathaniel’s talk.

Nathaniel is honored to be speaking at RubyConf for the sixth year in a row. His basic premise for today is this: the language you’ve chosen has certain characteristics that reflect back on you. In turn we can reflect on those characteristics and how they relate to what we value in business as well.


Ruby’s typing system (contrast to static typing). I’m thinking about my program, not satisfying the type checker. Static typing sounds good in theory but I haven’t found it that helpful in practice.

How about dynamism in business? How about job titles. If you stick a person in a “box”, they pretty much stay in it. It’s easy for HR, but not good for the growth of the business. In Ruby we have duck-typing, but a fixed job title is kind of like static typing. It makes it harder for you to adapt to the situation at hand, or keeps you from growing into new roles you never thought you could do. Nathaniel mentions how he, as a programmer, never thought he could be good at sales, but now he likes it.


The behavior of the program is order-dependent (contextual). Once you embrace that Ruby interprets statements as it encounters them, you find power in it. It allows you to delay decisions until they’re necessary, a feature that supports dynamic business.


A stated design goal for ruby (by Matz) is succinctness, but not just brevity for brevity’s sake (e.g., extremely compact Perl), but in a read/write sense.

A succinct legal agreement is wise use of the limited time a client has to figure out what he’s signing up for. Legal agreements should have one purpose -- to set expectations so that no one is surprised.

Maybe your employment agreement is so long and full of legalese that you’ve inadvertently signed up as a corporate slave. Be wary; ask for a summary; consider how it might affect your ability to contribute to open source projects.


Ruby the language permits and even encourages a high degree of introspection. Does your workplace reward introspection, or penalize it? Or is it a “fire and forget” environment?

Open classes

Ruby allows any code to open any class, add/remove code, muck with state. Could we break things everywhere? Yes. But Ruby values implementor power over safety or security through obscurity. This can be scary for some.

When people close to you know a lot about you, they can hurt you. You’re vulnerable. But the other side of this is that being open builds trust, which is an essential component of a successful business relationship.

Do you know what your peers are paid? Do you know what deals are in the pipeline? Can you look at the books?

Ruby’s open nature may seem naive, but it’s wonderfully naive.


Q. Would these techniques work outside of a technical hub? My business is not driven by locale. I’m able to assign work in a distributed manner.

Q. You assume that your peers are trustworthy and honest. What about in a more cutthroat competitive environment? You either need to change your organization or “change your organization”, i.e., switch jobs or try to effect change to find a place that reflects your values.

Q. Transparency meets the real world. Crashing software and crashing companies are two different things -- perhaps the analogy can only be taken so far? The worst that could happen is that I get nothing for the time I invest other than the learning experience. It’s more a matter of limiting risk. I’m not saying I’m broadcasting every detail to every client.

Q. Do you scope clearly and bid, or do you do ongoing hourly work? I only do time and materials. RFPs make me gag. People spend time on the piece of paper and then give it more credence than my own opinion.

Q. How does testing play into this? One thing that Ruby values is constant feedback, which is also a big tenet of testing. Constant and short feedback cycles, “testing your customer” -- don’t get caught in a long-term agreement.

Q. How do you put that in a statement of work? I make sure the client knows that we’re building a trusting relationship. I also don’t claim to have this all figured out.

Q. Can you scale this (team of trustworthy people) to a larger model? This is in a way like the evergreen question about Ruby; “does it scale?” Partly, I don’t care because it’s working for me now. On the other hand, I’m thinking about it because I like the thought of bringing more people into the fold. [A comment from the audience brought up the subject of lifestyle companies as an example of why it wouldn’t.]

Q. There are two types of contracts -- the 2-page business agreements and the 50-page CYA edge cases. True, I have the luxury of working with clients that small enough that they are not likely to sue me.

Q. If everyone is a sub-contractor, there is no career path or “carrot”. Part of the goal of my business is to catapult people beyond it by allowing them enough free time to work on their own things.

Q. How do you balance work and life? I’m not always the best at it, but now I’m working out of my house and can be with my family when things come up. Some days I shut the door and get things done. Work/life balance is messy and I work on it on a daily basis.

Posted in  | Tags ,  | 2 comments | no trackbacks

RubyConf: Matz Roundtable

Posted by Nick Sieger Sat, 21 Oct 2006 02:59:38 GMT

An annual tradition at RubyConf is the “Roundtable”, where any member of the audience can come up and ask Matz any question. Transcript follows with partial paraphrasing.

Q. Will Ruby ever get the features of evil built in? Will we get become? No.

Q. If Symbol is a “frozen” String, why do we need Symbol? I don’t have a complete answer to that question -- following tradition.

Q. What’s the most unusual architecture Ruby has ever run on? Ruby...I can’t think of one...JRuby? Some guys ran compiled Ruby on the NECS supercomputer. [From the audience] Symbian.

Q. As Ruby gains acceptance, it becomes more resistance to change. How do you keep agile while gaining momentum? We have forked off 1.8, so if you want stable, use Ruby 1.8 forever.

Q. The array patch -- is there any chance of a backport for those of us who want 1.8 forever? Could be, but the current patch has a bug in 1.9.

Q. Why isn’t YARV the only VM for 1.9? [Comment about register-based VM] I’m not sure whether stack-based or register-based VMs are better...[THAT GUY!]...[Given the hook]

Q. It seems like momentum is based on strong metaprogramming facilities. With 1.9 there are more user-friendly features. Will code eventually be data, or are we just patching on techniques on a tool that is being used more heavily? An extreme way to do metaprogramming is to use Lisp, but for practicality we have to start somewhere. I’m not sure that s-expressions are the way to go. We’re not going to have macros. It will remain similar to what we have in 1.9. The ability to serialize code would be really powerful -- will that happen? Disclosing internal state is tricky because it changes. It could be a platform-specific feature.

Q. Recently for 1.9, there was a patch for Array and String to be in the object header. Was this profiled? It seems like it would be an incredible performance problem. It was done for slowness of malloc and gc. In some cases it could run slower, but it benchmarked at about 5% faster. It should be tested thoroughly.

Q. Ruby 2.0 will not have green threads or continuations, correct? Are there specific reasons for that decision? It is difficult to implement green threads in YARV.

Q. People want to see development move quickly, but may not be able to contribute code. Can you suggest ways for those programmers to contribute? Submit patches to the list. What is the obstacle to joining us? [Question restated] Submit testing, submit documentation. Contribute to RubyCentral? (looks at Chad Fowler)

Q. The CSV library is useful, but slow. Can we see FasterCSV in stdlib? It’s ok to replace the csv library with FasterCSV, as long as the compatibility issues are resolved.

Q. I want to thank you because I love writing in Ruby every day. I tried to write Python first. Recently an unrelated upgrade broke my Python apps. Will we be able to manage multiple versions of Ruby? You’ll have to have two versions, 1.8, and future ones.

Q. What would you say is the most important feature of your personality that has given you success? Endurance? Can you elaborate? It’s easy to design a language, many of them disappear in a year or two. I’ve been working on Ruby for 13 years.

Q. I wanted to see in IRB how the class was implemented at runtime. (He means an uneval feature) [Audience member (Eric Hodel?) mentioned ParseTree]

Q. If there wasn’t Ruby, what would you be programming in? Some language of my own not named Ruby.

Q. Do you still look at RCRchive? Yes. I’ll talk about it in the keynote.

Q. I would like a feature abstraction that would allow Ruby to fork itself rather than actually forking. Can you see this added to core? We have to define the behavior of that feature. We have to have a good name for the method. Then there will be no problem to add it to core.

Q. Why do you need to bind methods to an object of the same original module? If you bind a method taken from String class to Array class, it will crash, and we need to prevent it.

Q. What do you think of Ruby.NET? I’m pretty open to new implementations. Should there be a standard (language specs) that other projects should follow? Charles started work for a written 1.8 spec, and I’ll help him with that if I have time.

Tags ,  | 2 comments | no trackbacks

Older posts: 1 2