The Ruby Way


I've wanted to tackle Ruby for quite some time. Luckily, Addison-Wesley just sent me a copy of The Ruby Way, Second Edition by Hal Fulton. This is one of those books that makes me think publishers feel the need to sell books by the pound. The sad part about that is that, in many cases, books printed by the pound contain tons of fluff and useless information. Not so with The Ruby Way. Every page contains gems valuable for anyone who wants to program with Ruby.

But this isn't a book review, per se. If it were, I'd recommend The Ruby Way without reservation. Anyone even remotely interested in Ruby should get this book, now. It's worth every penny of $39.99 US.

But here's what really inspired me to write about this book. There are pages upon pages devoted to the unintuitive twists in the Ruby language. There are so many quirks that I'm almost afraid to tackle my first Ruby program.

To cite one example from the book, in the following code, x ends up equal to "false".

y = false
z = true

x = y or z

The reason for this is that Ruby evaluates = before it evaluates the "or". I imagine this would be terribly unintuitive to a Ruby newcomer, and would lead to a lot of wasted debugging time. Even now that I know this juicy tidbit, I'm sure I'd make the above mistake at least a few times before I could consistently remember how Ruby works.

Obviously, you can force Ruby to evaluate the "or" expression this way:

y = false
z = true

x = (y or z)

If this was a rare quirk of Ruby, I wouldn't give it much thought. But, as I said, there are pages upon pages of explanation on how Ruby deviates from traditional programming practices.

Granted, I'm new to Ruby. Maybe you Ruby programmers out there are keenly aware of the various oddities in Ruby and take them for granted. In some cases I can see how the quirks aren't quirks at all, but necessary decisions on the part of Ruby designers in order to give Ruby more power. I'm still at the point where I'm asking, "Why on earth would anyone design a lanaguage to do that?" Maybe if I programmed in Ruby for six months, I'd find out why all of these design decisions make sense. My first impression, however, was that I'd never remember all these oddities when tackling my first Ruby programs, and I'd spend the first month trying to figure out why nothing works the way I expect it to work.

Nevertheless, it would be foolish to take this as a launching point for a Ruby rant. The overwhelming success of Ruby speaks for itself. There must be an ultimate payoff for learning it.

So here's my question to you Ruby aficianados. Did you have trouble adjusting to The Ruby Way of doing things? How long did it take for you to get used to Ruby's approach to objects, classes, instances, and the various oddities? How long was it before you started to feel like you really began tapping the power inherent in the language, and how much of that power do you attribute to Ruby's unique approach?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


J.Well's picture

any language is always a challenge specially when just kinda difficult to say it's has its quirks in a blog...lots will condescend first then give an opinion...=)

ruby eccentricities

Anonymous's picture

I came to ruby from bash/perl/awk and c/c++. there are a lot of differences, e.g. the extensive use of blocks, but only one has really proved difficult for me to absorb:

x = 0
puts "do what?" if x
=> do what?

str = ""
puts "do what?" if str
=> do what?

only false and nil are false, all other values are true. those used to languages that act like c will derive endless entertainment debugging things equivalent to

if ! blah

because their eyes will not see what is happening. for me this typically involved error handling code that is difficult to test and hence sometimes skipped; of course the false branch may never run due to the incorrect assumption that 0 is false.

I decided to try ruby not just for the sake of fooling around with a new language, but because of ruby on rails. my background there is long ago writing a modest web app using and DBI for MySQL. rails, had it existed then, would have allowed my to do in a few days what took me more than a month at the time.

to prep for rails I wrote a fairly extensive suite of tools to access Amazon S3, and I found ruby to be pleasant to write and read and to be accompanied by all the libs I needed (yes, CPAN is bigger, but I only care about what I use).

Agreed Rails is good, but Ruby?

Ken Ji's picture

I'd prefer Rails on Java or Rails on C++, why Ruby? Just another of syntactical learning curve. I don't think Ruby has gotten closer to English than any other language, more likely to have introduced confusions of its own among programmers of different backgrounds. I say no more languages need to be developed, unless one that is revolutionary, that introduces a new paradigm. And it must be the language that gets the headline, not a framework built on top of it, such as the case with Rails. I'd love if somebody build Rails on top of something else, is it possible? Anyone?

I did a quick test on the z

Anonymous's picture

I did a quick test on the z = x or y in ruby 1.8.5

what's mentioned in the article is completely false.

z turns out to be true.

Your comment is false

Anonymous's picture

In the interactive interpreter

>> y = false
=> false
>> z = true
=> true
>> x = y or z
=> false

Thus, the article is correct.

This line:
>> x = y or z

is actually:

>> (x = y) or z

Use || or be safe with

gtcaz's picture

Use || or be safe with parenthesis if you're unsure. Not hard at all.

$ ruby -v
ruby 1.8.5 (2006-08-25)
$ irb
irb(main):001:0> y = false
=> false
irb(main):002:0> z = true
=> true
irb(main):003:0> x = y or z
=> true
irb(main):004:0> x
=> false
irb(main):005:0> x = y || z
=> true
irb(main):006:0> x
=> true


Bob W's picture

There is a payoff in learning it. You will be amazed at how few lines of code it takes to get things done. My approach to learning a new language (I have learned many in 51 and one-half (as of today) years of programming) is to start right in trying to write some little program I want. That results in "fighting" the language for a while before I get the hang of it and start accomplishing things.

Get the Pick Axe book. I use it constantly (the PDF digital version) to look up the details of the many methods. I used its descriptions of Ruby and how to do things to get myself going. I was amazed at how often I discovered that Ruby did the right thing when I pushed the enevelope a bit and just coded what I thought should work and sure enough it did. Yes there were times when it didn't work too... The automatic variable typing took a bit of getting used to. And I had to stop trying to get it to act like Turbo Pascal where I first started doing OO programming 21 years ago.

FWIW I came to Ruby without knowing Perl, Awk, or Python. My friend who knows Perl can see the many similarities between it and Ruby. Before Ruby my language of choice for quickly accomplishing a computing objective with minimum code was REXX which originated at IBM. You already figured out that I am an old mainframe programmer. That's all there was... And only a few of them at that.

Try Ruby. You'll like it. I started doing Ruby in July of this year.

linux girl

Anonymous's picture

yes, I have trouble adjusting to The Ruby Way of doing things, just so used the java way, maybe the java way is better :)

The Ruby Way 2nd Edition

Simon P.'s picture

Hi Nicholas,

I just found "The Ruby Way 2nd Edition" via Amazon and I was not sure to buy, because in the german version of amazon there aren't any reviews on this book yet... Well, I googled (sorry Mother Google for abusing your mighty brand) and I came here... Nice Blog, and thanks for your review.


This is the 2nd book to read after the pickaxe

Eljay's picture


Well, basically, the title says it all. When I give presentations or trainings on Ruby I always recommend to read the Pick Axe book first and the Ruby way second. It is not a book for beginners for the reasons that you highlighted. But for Ruby programmers with some experience it is full of wise advices and usefull pieces of code in many different domains.

Definitely worth the money.

Ruby on Rails

B's picture

I've been using RoR for about 4 months now. It's very easy to pick up and has been a blessing. I'm an application developer so this was my first web application. Ruby is a bit weird - but I don't need to use any of the powerful features it has.

The ruby way

T-T's picture

Next to C, Ruby is my favorite language, by a wide margin.
And I have been programming for years in ruby and have not
been bitten by the = or precedence issue mentioned in this
article, so I wouldn't be put off by this issue at all.
Ruby is the first language that made OO programming come alive
for me, probably in large part due to the influence of the
pickaxe book, as much as the language itself. In any event,
give ruby a whirl. The principle of "least surprise" is only
rarely violated.

Every language has quirks

Anonymous's picture

Ruby has fewer quirks than most languages. Studying the list of quirks is not a good way to learn a language, as you would run screaming with C's quirks or C++'s quirks or Perl's quirks running to hundreds of pages as opposed to several pages.

x = y or z

botp's picture

Hi Nicholas,

My friendly advice:
do not think like any procedural language. This is ruby. Just let your mind and imagination flow. And i assure you, ruby just fits intro your thoughts easily (unlike any other programming language you can think of).

so if i were to choose between

1) (x = y) or z

2) x = (y or z)

for the meaning of "x = y or z", i'd choose the former.

Why? That's how my brain naturally think. I just plain read from left to right. I don't have to think in C or Pascal or Java for that matter, really.

kind regards -botp

Right, just read from left to right

Ken Ji's picture

What about Chinese and Muslim coders dude? They read from right to left. What a shallow mind you have. I bet you don't know how to evaluate this:

x = y + b * a - z + m / u % v = x or j = 41 and -1

What do you think that gives? Oh, right, just read from left to right. I get it!

Most programmers think

Anonymous's picture

Most programmers think mathematically, and most math dictates that:

x = false or true


x = (false or true)


Mr. James G. Britt's picture

I got hooked on Ruby because, very quickly, I found that I could guess at the correct syntax for whatever I wanted to do, and be right almost all the time.

Are there things that tripped me up? Sure. I prefer a language that has a small set of ground rules that are used to drive the rest of the language; Ruby is good for this, but it has its share of, "This is how it works, except when it doesn't."

Still, over all, Ruby seems to have fewer WTF? moments than most.

To answer your actual

Avdi's picture

To answer your actual question, I was having "wow" moments in the first few hours I spent with the language. I doubt it took more than a month for me to get reasonably comfortable and productive with it. I've been using it for a few years now, and I'm still occasionally learning new things about the language (or being reminded of features I'd forgotten); but the core language didn't take very long at all.

I'm a software engineer, and

Avdi's picture

I'm a software engineer, and I'd worked with a lot of languages before I tackled Ruby. Ruby is, by far, the most sensible and programmer-friendly language I have ever used. Unlike in, say, C++, most of the seeming "gotchas" are there for a reason, rather than just being ugly historical quirks. Once you start to grok Ruby's core idioms, you'll find yourself becoming amazingly productive. Things like Blocks and Ruby's phenomenally powerful "case" statement don't take long to learn, and are immediately useful.

The example you picked is not a Ruby quirk, per-se; it's really a feature that Ruby inherited from Perl. Most languages before Perl only had one logical "or" operator, usually the "||" operator. For convenience (and readability, believe it or not) Perl added a second "or" operator with the same semantics as "||" but with ultra-low precedence, which enabled certain boolean statements to have "unsurprising" semantics without resorting to lots of nested parenthesies. The example above has exactly the same result in Perl (although it's uglier, since Perl doesn't have first-class boolean types). If you want it to work the way you expect, use "||" - just like in C.

This is a strength, not a weakness. You can use a lot of the same operators and idioms that you are used to from other languages like C, Java, or Python; and slowly work your way into using more advanced Ruby idioms. Sure, there's a lot there to learn; but you don't have to learn it all at once.

However, you emphatically should NOT be starting with The Ruby Way. The Ruby Way is more of a cookbook and second-level guide for advanced users. Kind of like the Effective C++/Java books. Pick up a copy the Pickaxe (Programming Ruby, 2nd Ed.) instead.

Thanks for the comment

Nicholas Petreley's picture

In fact, I would have used || anyway, since I'm used to that. But it still struck me as odd for Ruby to evaluate = first. I don't do Perl, so I missed the similarity.

I appreciate the advice about Programming Ruby. I will get that book, but I tend to gravitate toward the more advanced books like this one anyway. I've been a programmer for a long time, so I usually jump in the deep end of the pool. That isn't always a good idea, but it's just me. ;)

It's not a bug it's a

Anonymous's picture

It's not a bug it's a feature :) "or" is designed to be used in 'do_something or exit' expression groups not the actual boolean OR operator (|| is used for that as you know).

The Pickaxe

Avdi's picture

If it's any help, the full text of the first edition is available at

Seriously, I can't push this book enough; it's one of the most well-written and enjoyable technical books I've ever had the pleasure of reading (and I, like you, have little patience for novice-level stuff). It's also an essential reference to the core classes (although somewhat less essential since the advent of Oh yeah, it's written by the authors of The Pragmatic Programmer, if you're familiar with that book.

Or you could always hit the [in]famous Poignant Guide, if you prefer short and mind-bending ;-)