Programming Ruby: The Pragmatic Programmers' Guide

James Edward Gray II writes " Programming Ruby: The Pragmatic Programmers' Guide (Second Edition), known as the Pickaxe II to its fans, is an extremely current view of the Ruby programming language. Revised primarily by Dave Thomas, a founding father of the English Ruby community, Programming Ruby is distilled expertise from a reliable source. In the past, quality English documentation of Ruby has been in short supply, but if any one volume could solve that problem, this is it." Read on for the rest of Gray's review. Programming Ruby: The Pragmatic Programmers' Guide author Dave Thomas with Chad Fowler and Andy Hunt pages 830 publisher Pragmatic Bookshelf rating 9 reviewer James Edward Gray II ISBN 0974514055 summary The definitive source for all things Ruby.

If you're not familiar with it, Ruby is a very fun and elegant scripting language that has been described as "more powerful than Perl and more object oriented than Python." I won't start a language war by defending that statement, but I will tell you what makes Ruby very attractive to me: Extremely object oriented, super clean syntax, and a smooth blending of iterators and code blocks for straightforward, concise solutions. If that sounds like a language you would like to know more about, Programming Ruby is the book for you.

At 830 pages, this edition is considerably larger than the first. It represents an expansion on many topics originally covered, in addition to all new coverage on topics like unit testing, RDoc documentation for Ruby source code, and more. Better still, "Duck Typing," a topic central to Ruby philosophy, receives its own enlightening chapter. This volume covers the very latest release of the language, often highlighting new features and even giving tips for things to watch for in future versions.

Programming Ruby is divided into four distinct sections. "Part I - Facets of Ruby" is a tutorial on the Ruby Programming Language. It's very effective, but I probably better give a warning here: This book teaches you how to program in Ruby, not how to program. You likely won't feel comfortable, even in this tutorial section, unless you have some experience with other programming languages. As an example, Ruby is object oriented on a scale with languages like Smalltalk, so you'll need to know object oriented programming. This book makes no attempt to teach such concepts, excepting how they apply to Ruby. As long as you come with the proper background, this section will get you on your feet with Ruby in under 200 pages. It's very well thought out.

"Part II - Ruby in its Setting" is a mixed-bag tour on the many places Ruby sees use. Web programming, command-line hacking, using TK to build GUIs, and Windows programming are just some of the covered topics. Other chapters in here focus on elements unique to Ruby, like the earlier mentioned RDoc or "irb," the interactive Ruby shell. There's even a chapter in here on package management with RubyGems.

When you're ready, "Part III - Ruby Crystallized" will take you deep into the core of Ruby syntax and functionality. This section tells you all the details about how Ruby reads your code, and how it runs. I think few people could soak in all the tidbits in here in one scan. I've read it twice now and learned about as much both times. There's a lot of great Ruby knowledge waiting to be mined out of here.

Finally, "Part IV - Ruby Library Reference" is the best Ruby reference I've yet run across. It covers every class, module, method and constant in core Ruby. The descriptions for these entities tell you exactly what you need to know, the examples, though short, are inspiring, and the comments sneak in subtle hints that are more than useful. Following this, the book gives an overview of all Standard Libraries included with Ruby. This section really opened my eyes to the tools I've been missing out on simply because I didn't know they were there. Be warned: These Standard Library summaries won't teach you every feature available. They just tell you what they're for so you'll know where to look for the information you need. The last great feature in this section is a terrific index. I care about the index and a book that has a bad one will really bother me. Luckily, that couldn't be further from the truth here.

Programming Ruby isn't perfect, of course. Some of the chapters are not as thorough as you wish they could be, simply because of the amount of information that needs to be covered. The chapter on threads is probably the biggest example of this, but remember that entire volumes have been written on threading. Another minor point is that some of the examples are quite contrived. This bothers some people, but I don't feel it's too much trouble for the book's target audience. As I've said, you're expected to know how to program going into this book, just not how to program in Ruby.

Programming Ruby at least touches on most things central to the Ruby Programming Language, and goes into considerable detail more often than not. There's something for all levels here. You can learn Ruby from the tutorial, as I did with the first edition, but you'll keep coming back to the wonderful reference and to go deeper into specific areas of interest. That's a lot of great mileage for one book. I'm willing to bet most Ruby Gurus keep it in arm's reach, because Ruby wouldn't be half as much fun without it.

You can purchase Programming Ruby from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

First edition is available online.

[Kenja]

http://www.rubycentral.com/book/

Re:pickaxe?

[Rich_Kilmer]

It comes from the pick and axe on the front cover of the book :-)

Ruby and Perl over Python for cross-platform dev

[Dystopian Rebel]

I can live with Python's having no statement terminator (";" in C, C++, Perl, Java).

What I find unacceptable in Python is that whitespace (tabs) determine the logical flow. I once wrote a script on Windows and moved it to UNIX; the UNIX editor handled tabs differently, and my script wouldn't work without a few hours of attention just to set the spacing right.

Ruby has Pascal-like blocking. That alone makes it superior to Python. And for all other situations that do not require a good OO implementation, there is Perl.

awesome book, awesome language

[Anonymous Coward]

I've been using Ruby since I read about it in DDJ a while back.

What really struck me about Ruby is how it "solved" many of the issues that had been bugging me about other languages (and I've used a bunch). Such as:

* In many languages, a built-in method will either mutate an object "in-place", or it will work on a copy of the object and return that, leaving the original untouched. Sometimes pretty arbitrarily. But in Ruby, there's a convention like in Scheme (and maybe others): methods ending in "!", like "array.sort!" will sort the array in-place, and the other methods return a new sorted copy. Nice! One annoying issue solved.

And booleans end in "?" which is nice too. instead of "is_foo" you write "foo?".

* In many languages, you can have fields on objects, and you can have methods. So when you have "attributes" (like "first_name", "last_name" on a customer object), do you use fields which are simple and straightforward with natural syntax:

object.first_name = "Joe"

or do you use methods, which can be refactored:

object.setFirstName("Joe")

So, do you go for the awkward syntax, keep the fields private, and allow refactoring? Or do you expose the field, and rewrite all the code later when the requirements say "name must default to 'Anonymous Coward' when no name set"? Or do you convolute your code around the issue?

Ruby solves this elegantly. There are NO PUBLIC FIELDS! Instead, you always use methods:

# setter
def first_name=(f)
@first_name = f
end

# getter
def first_name
@first_name
end

object.first_name = "Joe"

And no goofy "set_first_name" .. it's UNIFORM ACCESS. Beautiful! Now when the anonymous coward requirement comes in, just rewrite:

def first_name
@first_name || "Anonymous"
end

No client code has to be changed. And "first_name = 'joe'" still works.

AND you don't even have to create the basic getter/setters! Ruby classes have a built-in class method that creates them dynamically:

class Customer
attr_accessor :first_name, :last_name
end

Very elegant! Well-written programs are very clean and light.

* No need to use exceptions for non-local flow control.

Ruby has exceptions, but sometimes you want to jump out of a deep tree search (for instance), and an exception is what you need: "raise SearchFinishedException" or something like that.

But is that a good idea? Using "exceptions" for flow control? No because exceptions are, well, *exceptional*, they don't occur normally.

Ruby helps me here too. It has catch()/throw() which is a simple alternative to exceptions, designed for nonlocal flow control. And of course you can write your *OWN* flow control because it has continuations (encapsulate program flow into an object for later return).

Anyway Ruby is such an amazingly elegant language, and the pickaxe book is the appropriate companion! Buy a copy now, even if you don't use Ruby, it's very clear and easy to read (not just because of the language, but because of the enthusiastic and talented authors).