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.

First edition is available online.

[Kenja]

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

RubyConf 04 was held recently....

[tcopeland]

...thanks to Ruby Central [rubycentral.com] for sponsoring it.

A BitTorrent of the presentations is available here [rubyforge.org].

Re:pickaxe?

[Rich_Kilmer]

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

Eager to have this book

[rolling_bits]

Many of us, Rubyists, have been introduced to Ruby by the very first version of this book. And the first version is online and is still handy for consulting:
http://www.ruby-doc.org/find/pickaxe

But this new version covers all the changes from Ruby 1.6 to Ruby 1.8; making this book a must have.

As far as I know, it's available as PDF and as paper, and I'm gonna have both.

Thanks Dave for helping the occident know Ruby and Matz for creating the must inspiring language for me.

Cheers!

Re:Web programming

[Luk Fugl]

The review mentioned web programming, does one need a specific platform installed or it "just runs"?

I'm not sure what you mean by platform or "just runs". If you mean, do you need a certain OS? No. Do you need Apache in particular? No, though Apache and Ruby work very well together. Do you need any external web server? No. One of the standard libraries that comes with Ruby is WEBrick, which is a standalone webserver. You can get Ruby running web apps using WEBrick on any OS, no other software required.

Along those lines, let me throw in a quick plug for Ruby on Rails [rubyonrails.org]. Rails makes web application using the MVC model very quick and easy. The default setup includes a WEBrick servlet so you can have your application listening for requests minutes after installation, literally.

Visit #ruby-lang and #rubyonrails on freenode for more information about Ruby in general or Rails.

Jacob Fugal

Re:Too many new languages at once...

[tcopeland]

> Ruby is a better fit for this problem?

There's a good C2 Wiki page on this - PythonVsRuby [c2.com].

Note that the Ruby standard library docs...

[tcopeland]

...are also available on ruby-doc.org here [ruby-doc.org].

Re:RubyConf 04 was held recently....

[chadfowler]

Thanks Tom. It's actually http://rubycentral.org.

Poignant vs Pragmatic

[weston]

Why's Poignant Guide to Ruby [poignantguide.net] has got to be the most entertaining Ruby read out there....

Re:Too many new languages at once...

[jonastullus]

at the risk of being totally flamed by all the ruby followers out there:

i have for quite some time now been programming in python and it just works like a CHARM!!
i used to be so proud of my perl skills, but at some point i just felt dirty using perl and once i had started with python there DEFINITELY was no turning back! (well, maybe for a few-line regexp script...)

from what i have gathered about ruby, the distinction between ruby and python is really slight! the syntax of ruby is VERY similar to that of python and python's object orientation is really decent.
so in case you have already started into python i wouldn't swap for ruby, but as i said, the difference seems rather marginal to me, so it doesn't make that much of a difference.

Re:RubyConf 04 was held recently....

[tcopeland]

Curses... thanks. Would that there was a post editing capability... ah well. Retry:

Thanks to Ruby Central [rubycentral.org] for sponsoring RubyConf 2004!

Re:Too many new languages at once...

[fredrikj]

It is not true that Python is "half-OO", at least by the merit of your argument. Finding the length of an object is done by calling a method:

>>>"bla".__len__()
3

>>>class Foo:
... def __len__(self): return 5
>>> Foo().__len__()
5

You can also do len(Foo()) or len("bla"), and although I agree that the existence of this legacy function makes the language less consistent I fail to see how it makes it any less OO.

Re:Good/bad points

[PragDave]

Could you give some examples? I'd love to fix stuff. if it's broken.

Why not e-mail me directly as well as posting here: dave pragprog.com

Cheers

Dave

Re:Too many new languages at once...

[baka_boy]

Ruby has first-class functions; you just have to disambiguate them syntactically, since bare property access (like foo.bar) is actually calling method bar on the object foo. So, if you want to reference the method explicitly, you have to write foo.method(:foo), which returns a Method instance which can be invoked or used like any other scalar value.

So, while in Python, you might write something like this:
controller.set_handler('some_action', myObject.handle_some_action)
...the Ruby idiom would be one of the following:
controller.set_handler('some_action', myObject.method(:handle_some_action))

-or-
controller.set_handler('some_action') { myObject.handle_some_action }

The extra method(...) syntax is needed to ensure that all communication between objects is via method calls, rather than direct property access. Python allows you to directly assign to and read from object attributes, much like public members in C++ or Java classes. Ruby forces all attribute access to be wrapped in get/set methods, but provides a lot of support to make implementing those methods effectively automatic.

The latter example also uses a code block, cover many cases where first-class functions would be otherwise -- they're basically a compact syntax for lambda expressions, and prevent you from needed sugar like list comprehensions in most situations.

For example, instead of the following Python list comprehension:
[x*2 for x in myArrayOfValues if x % 3 == 0]

...you would use this:
myArrayOfValues.map {|x| x*2}.find_all {|x| x % 3 == 0}

Blocks are also a general idiom used throughout the standard library and most Ruby code in the wild. You can use them to write callbacks, query databases, and even to build domain-specific languages (another traditional stronghold of functional languages).

Really, though, neither Ruby or Python is a truly functional language; both borrow from the more "academic" languages those features and concepts they find useful, and leave behind those that the maintainers and users don't want, need, or understand. (Except for continuations, of course -- Ruby has those, and I would guess that only a very small percentage of Ruby coders ever grok them.)

Re:Too many new languages at once...

[fredrikj]

1) why do I need to include 'self' as the first parameter of each method definition?

It's nicer for unbound methods, and makes calls to superclass methods clearer. This is also answered in the Python FAQ [python.org].

2) In Python people tend to prefer, for example, to find the length of an array by saying:

length( array ) instead of array.length (the latter being the way you would do it in Ruby). Of course Pythonistas are now screaming that you can also say: array.__length__ (or something similar) in Python as well.

See my previous post in this thread. I agree that this is something of a wart, but a minor one.

As for Ruby vs. Python, I don't think it's a big deal as they are similar in many ways. If you're comfortable with either language, there's probably no need to switch to the other. Myself, I don't think the higher level of consistency in Ruby's object system offers any practical advantage, and find Python's syntax much nicer. Haven't seen anything particularly interesting in Ruby that isn't also in Python.

Indeed, if I had discovered Ruby before Python, it's quite possible that I would've stuck to that instead.

Re:What demand is there for RUBY in the workplace?

[CatGrep]

These Guys [robotcoop.com] just hired about 4 Ruby programmers to work with Rails [rubyonrails.org] (a Ruby-based web application framework that uses an MVC model that's generating a lot of interest in Ruby)

I suspect that you'll see more small shops using Rails (and thus Ruby) in the coming months.

Re:What demand is there for RUBY in the workplace?

[Anonymous Coward]

There was absolutely no demend for it where I work until an enthusiastic Ruby programmer gave a talk on the language and its libraries. Now it has helped to make people here quite a bit more productive because of both its simplicity and how fun it is. So first, learn it (it's really easy---don't worry), and if you decide it'll help where you work, then create the demand. This won't make you any more money however, but this is about making your job easier and more enjoyable.

Re:Too many new languages at once...

[cmowire]

Notice I said "functional-programming types of paradigms", not functional programming.

It does have first-class functions (the Proc class) it's just that the syntax is driven towards making closures accessible instead of functions and creating Procs is a lot more involved.

On the other hand, what they do with the closures (a.k.a. Code Blocks) is quite amazing on its own merits. The concept of being able to iterate over arbitrary stuff in a variety of ways with them comes in quite handy, plus all of the other ways to make the language easier to deal with.

And, then of course, there's the functional library [www.ping.de]. ;)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Too many new languages at once...

[Jerf]

There are a couple of nagging issues in Python which give me this idea:

Here's how I think people should evaluate Python vs. Ruby:

1. Run Python, downloading it if necessary.
2. Run a Python shell (OS-dependent).
3. Type "import this", and read it.

If everything speaks to you, as it does me, than try Python first. Otherwise, try Ruby. I'll leave a Ruby-ist to explain the exact differences.

I can give a couple of the differences, though; mostly, the differences between the languages and capabilities are philosophical. Ruby has more "purity", Python says "Although practicality beats purity." (although with a strong cultural understanding that purity isn't worth tossing away as Perl seems to). Python also thinks "Readability counts.", Ruby seems more interested in making the syntax always concise. I'd much rather read a Ruby program than a C++ program, but the Python one will look more like pseudo-code with real English words, and Ruby will have a bit more syntax. Python has no culture of saving keystrokes and such things are usually considered a joke when the topic comes up, as are various language comparision benchmarks that incorporate that as a measure. (Typing speed is very, very rarely the constraint on programming speed.)

Which is right? Well, it mostly depends on what you want.

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).

ruby documentation

[pizza_milkshake]

one thing that really hurts ruby is that it's documentation is sparse. i used to be a big ruby fan, but documentation has not kept up with its releases. whereas i think ruby is a very nice language, languages like perl, php and python have much more complete docs, and it makes the difference between 30 seconds to figure out the right function/method and digging around 15 minutes through out-of-date docs and finally going in and reading the source code.

i own the first edition, it's a good tutorial-type ruby book

Re:First edition is available online.

[Anonymous Coward]

The 1st edition is very out-of-date. It's kinda like reading a Perl 4 book to learn Perl 5.8. But the author was generous to provide it for free and it is available in MANY formats online from PDF to Microsoft Help to HTML.

I own the 2nd edition and am VERY happy with it except for the quality of paper. Reminds me of Java in a Nutshell because it quickly teaches the language and also provides a reference to keep on your desk. This is my first and only hardcopy Ruby book and I doubt I'll need another one for a few years.

For those of you new to Ruby or just curious, here are some useful links:

Ruby Home
http://www.ruby-lang.org

Ruby Forum (new! primarily for beginners)
http://www.ruby-forum.org/bb/

Ruby Online Docs
http://www.ruby-doc.org

Ruby Project Archives
http://raa.ruby-lang.org
http://rubyfor ge.org

Ruby Package Manager (easy to install ruby apps)
http://rubygems.rubyforge.org/wiki/wiki.pl

Ruby IDE (free!)
http://freeride.rubyforge.org/wiki/wiki.p l

Ruby One-Click Installer for Windows
http://rubyinstaller.rubyforge.org/wiki/w iki.pl

Ruby IRC channel
#ruby-lang at irc.openprojects.net

Ruby Newsgroup
news://comp.lang.ruby

Ruby Links
http://www.rubycentral.com/links/index.html
http://dmoz.org/Computers/Programming/Languages/ Ru by/Software/

Re:Good/bad points

[PragDave]

Please drop me an e-mail (dave pragprog.com) and let me have them: I'll fix up any you find.

Cheers

Dave

Re:Ruby and Perl over Python for cross-platform de

[Tellalian]

Python will require me to go line by line and insert spaces or tabs.

No offense, but that's a load of crap and evidence that you've never actually coded anything in Python. If you had, you'd know that Python comes with a fully functional editor called IDLE, which includes auto-indentation. You can also select whole chunks of code and press ctrl+] to indent or ctrl+[ to unindent. Explicit scope declarators serve no purpose but to frustrate the programmer who forgets to declare that last '}' of 'end' statement. All Python forces you to do is write clean, readable code.

Re:awesome book, awesome language

[OmniVector]

one of my favorite featuers of ruby is the ability to dynamically modify built in data types at runtime. say, for example, i want to add a pretty format method to hashes. i just type:

class Hash
def format
data = self.keys.collect do |key| key = "#{key} => #{self[key]}" end
"{ #{data.join( ', ' )} }"
end
end

now i can make a hash and print it just by saying:

hash1 = { 1 => "one", 2 => "two", 3 => "three" }
puts hash1.format

which outputs

{ 1 => "one", 2 => "two", 3 => "three" }

i don't know of any OOP language that has an ability that powerful.