Happy Programming: Notes on Ruby
A brief, bullet-point history of Ruby by developer Nick Sieger cites as one of the language’s foundational philosophies: “the name of things matters.” This is, to a certain extent, tongue-in-cheek; Sieger goes on to summarize the process of naming the language itself:
Matz [Ruby inventor Yukihiro Matsumoto]: “I guess Ruby is cool”. Keiju [his colleague Keiju Ishitaka]: “I also like coral”. Matz: “oops”.
The arrival at the name Ruby in an online chat between Matsumoto and Ishitaka is recorded here, in an archive of the ruby-talk mailing list. The chat log was shared to the list in an English translation by Sugihara Hiroshi on Christmas day, 2003 (apparently to celebrate the release of Ruby 1.8.1). Ruby was maybe going to be called Coral, maybe even Tish — apparently for tissue, i.e., toilet paper, on the pattern of Bash (“Tish, if it’s like shell enough”). Or maybe Chorus, or Clouds. Or Bisque. “Bisque is cool, but sounds bad.”
Ishitaka is the one to propose Ruby, as a tribute to Perl. (Matsumoto has referred to Perl creator Larry Wall as his “hero.”) But Matsumoto is not immediately convinced — how about Oyster? Okay. Or akoyagai, which is Japanese for a pearl-producing oyster? No. Ruby or Coral. Eventually Ishitaka mentions that ruby is his birthstone, which seems significant enough to settle the matter permanently.
It seems unclear what else of Ruby—apart from the name and some kind of inspiration—existed at this point in time. But it was apparently not much. If the name didn’t come first, it was not far behind.
In sharing his translation of Matsumoto and Ishitaka’s chat to the ruby-talk mailing list, Sugihara writes: “If it would be your fun, I should be very happy.” I think this is significant—it speaks to an ethos fundamental to the language and a shared spirit heavily reflected in the discourse of its users: the happiness of programmers is a foundational concern of Ruby. Matsumoto says so in numerous lectures, interviews, and publications:
For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy…Often people, especially computer engineers, focus on the machines. They think, ‘By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.’ They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines.
What makes programmers happy? What problems does Ruby, in its design as a language, solve? How can we compare a language like Ruby to, say, one like JavaScript?
Ruby and JavaScript first appeared publicly at almost the exact same time, in December 1995. They share a certain amount in common. Yet they are very different kinds of entities. JavaScript is internationally standardized, as ECMAScript, by Ecma, an international regulatory association; Ruby is apparently not subject to any such standard. Yet Ruby has an enthusiastic international community of “Rubyists;” JavaScript does not seem to inspire the same kind of devotion. (This may be a function of its de facto dominance: compared to the sect of Ruby, JavaScript is mainstream orthodoxy. It may be too big to need evangelists like Ruby’s.)
Examining Ruby and JavaScript code on their surfaces, Ruby’s ambition “to be like…pseudo-code that runs” seems clear. There’s a cleanliness about it: less punctuation and more space. Its keywords make intuitive sense: “do,” “end,” “def[ine].” JavaScript has a more regimented look (with greater insistence on the use of parentheses and brackets, among other things) and a more abstruse vocabulary of keywords.
Ruby’s rigorous object-orientation also creates a distinctive experience—in my experience, an utterly different “headspace” from that of JavaScript. Ruby feels different; it’s a language designed with a keen awareness that programmers feel the languages they use as much as they feel their ergonomically designed keyboards and desk chairs.
The factors that give shape to programming languages and inform their ongoing evolution are diverse, encompassing commercial interests and theoretical ones, military concerns, and nerdy design sensibilities. Investigating and understanding them in their diversity no doubt makes programming a happier pursuit.