Coming From Ruby
Who knew?A large number of Japanese programmers knew, quite a while ago. No one who attended RubyConf 2002 in Seattle will ever forget the sight of a display table on which were laid out, not for sale but for our enlightenment, one copy of each Ruby book then in print in Japan. This, remember, was 2002. There were 23 books.
So in case you weren't sure: no, Ruby was not unknown before Rails!
Ruby wasn't even unknown outside of Japan before Rails. The publication of the first edition of Programming Ruby (Addison-Wesley, 2000) by Dave Thomas and Andy Hunt brought about the first big swell of interest in Ruby in the English-speaking (whether natively or not) world. And Dave and Andy must have heard of Ruby even earlier.
I fell in love with Ruby on the walk from the computer section of my local Borders to the cash register. I haven't looked back. I've been happy to have Ruby be my "home" language for more than six years. I guess you could say I "come from" Ruby.
The (relatively) old daysIt's a nice feeling, and in some respects a hard-won victory. In what now feels like the old days (i.e., a few years ago), the idea of "coming from Ruby" didn't seem to be on most people's radars.
The funny thing was that even as people reacted to Ruby with great enthusiasm, they also treated it like a kind of rookie or probationary language - a language in search of a style, a culture, a rationale. You'd see lots of questions and comments like this (these are made-up examples, but by no means parodies):
I'm just starting out with Ruby, and I think it's really great. There are a couple of things I'm not sure about, though. I come from C, so I was surprised to see that zero is true. Wouldn't it be easier for C and Perl programmers if zero were false?or this:
Coming from C++, I consider static typing very helpful. Are there any plans to add it to Ruby?or even advice like this:
Ruby lets you use under_score or camelCase for variable names, so just use whatever you used in the language you come from.I'm probably giving a skewed view of the use of "come from" in so many words. But the gist was always the same: Ruby didn't count, so everything had to be expressed in terms of other languages. There were C and Perl programmers, but not Ruby programmers (or if there were Ruby programmers, Ruby's feature set should have been less about them and more about the C and Perl programmers). Dynamic typing could stay or go, depending on how people who used languages other than Ruby felt about it. And there was no need to respect Ruby's stylistic traditions - in fact, Ruby wasn't a real language so it couldn't have traditions - so just airlift some conventions in from another language.
This kind of thing went on for a long time. (It still goes on, but there's less of it and there are more people who see how misguided it is. So I'll speak of it in the past, at least to paint with broad strokes.) It was weird. Weird on the merits, and weird to be on the receiving end, as a Ruby programmer, because it made one feel invisible.
The concept of "coming from" a language, I believe, served as an anchor for a lot of these questions and suggestions. It was as if the very fact that Person A had used Language X for N years somehow incurred an obligation on Ruby's part to emulate Language X. Leaving aside the slighting of Ruby (which I believe was largely unconscious, though extensive) - and leaving aside, too, the feature soup that would result if all of these requests for change were honored - putting that much stock in which language you "come from" just doesn't make sense.
Consider this scenario:
You "come from" C. So you think that having zero be false is "intuitive," and that zero should be false in Ruby. However, you grudgingly accept that it isn't, and you get on with programming in Ruby.
A few years later, you're very comfortable with Ruby, and you decide to try another language - perhaps Perl. Now, when you start using Perl, you "come from" Ruby. So you expect zero to be true. So Perl is doing it wrong.
In other words, you're always one language out of step. And only one language at a time can be correctly designed! You're always homesick, and never enjoy your travels.
That can't be right.
Come from Ruby!
Mind you, I'm not saying that Ruby exists, or ever existed, in isolation from other languages. Far from it: Ruby has borrowed a lot of features, and wears its heredity on its sleeve. Ruby's creator, Yukihiro "Matz" Matsumoto, is extremely knowledgeable and incredibly good at putting his knowledge to use in the language-design process. So the Ruby world is always abuzz with talk about how various bits of Ruby relate to bits of other languages.
Still, Ruby is anything but a feature-pastiche. It's got a style and design signature all its own. Matz takes the greatest care with design and feature decisions. After you've heard Matz discuss how he thinks about these things, all the more do you realize that "to make C++ programmers feel more at home" just isn't in the ballpark.
Nor do I mean to suggest that Ruby shouldn't change. In fact, Ruby is still in development. Matz has always encouraged and welcomed suggestions for changes to Ruby. Topics related to feature addition and change often dominate the mailing lists. So it's not that anyone wants or expects Ruby not to change. It's more a matter of where the change, or the suggestions for change, comes from. If someone feels that having zero be false would make Ruby better, for some reason other than that it would make Ruby feel more like one or more languages that aren't Ruby, then by all means let's hear it.
It's time to be allowed to come from Ruby. And that does not mean doing unto other languages what's been done unto Ruby. Believe me, I will never write to the mailing list of any language requesting that something be changed in the language so that Ruby programmers will feel more at home. (I might be tempted to... but I won't.) It means according Ruby full, first-class citizen rights in the programming-language world, and enough already with the implied asterisk next to its name.
So if you come to Ruby, stay for a while - and if you stay long enough, feel free to come from Ruby. You won't regret it!
About the author
David A. Black is a long-time Ruby and Rails programmer, author, and trainer. Active in the Ruby world since 2000, David is the author of Ruby for Rails: Ruby Techniques for Rails Developers (Manning Publications, 2006) and the PDF Short Cut Rails Routing Roundup (Addison-Wesley, forthcoming, 2007).
David is the owner and director of the Ruby/Rails consultancy Ruby Power and Light, LLC (http://www.rubypal.com), and a co-director of Ruby Central, Inc., parent organization of the annual RubyConf and RailsConf events (http://www.rubycentral.org). In his Ruby Central role he has co-organized Ruby and Rails conferences, including the annual RubyConf, RailsConf, and RailsConf Europe, since 2001, and has served as administrator for the Ruby Central Regional Conference Grant Program and Ruby Central's participation in the Google Summer of Code.
David is the chief author of Ruby's standard scanf library, and the author and maintainer of the official Ruby Change Request site.
Daniel Jebaraj Mar 12, 2014
Evolving Culture and Values. Understanding the Tradeoffs. Growth through Failure. The Importance of Leadership and Open Communication.
Pedram Keyani Mar 11, 2014
Summly: An Award Winning Mobile App's Journey to the Cloud with Five-9s Availability on a Shoestring Budget
Eugene Ciurana Mar 11, 2014
Christophe Achouiantz Mar 11, 2014