Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Book Reviews Books Media

The Ruby Programming Language 172

bdelacey writes "In January 2008, just in time for Ruby's 15th birthday, O'Reilly published The Ruby Programming Language. The co-authors make a strong writing team. Yukihiro (Matz) Matsumoto created Ruby. David Flanagan previously wrote Java In a Nutshell and JavaScript: The Definitive Guide — he has a CS degree from MIT with a concentration in writing. Drawings are the work of Rubyist-extraordinaire why the lucky stiff and technical reviewers include well known Rubyists David A. Black, Charles Oliver Nutter, and Shyouhei Urabe." Read on for the rest of Brian's review.
The Ruby Programming Language
author David Flanagan & Yukihiro Matsumoto with drawings by why the lucky stiff
pages 444
publisher O'Reilly
rating 9/10
reviewer Brian DeLacey
ISBN 0-596-51617-7
summary A classic and comprehensive guide to Ruby.
According to the Preface, Flanagan and Matz modeled this book after the K&R "white book" — The C Programming Language by Brian Kernighan and Dennis Ritchie. Like the "white book", The Ruby Programming Language has a simple structure and provides complete coverage. Just as K&R served as the de facto standard for "C", The Ruby Programming Language will likely be seen as the most authoritative language book for Ruby. Flanagan and Matz provide the following guidance for their readers:

"Because this book documents Ruby comprehensively, it is not a simple book (though we hope that you find it easy to read and understand). It is intended for experienced programmers who want to master Ruby and are willing to read carefully and thoughtfully to achieve that goal. ... [T]his book takes a bottom-up approach to Ruby: it starts with the simplest elements of Ruby's grammar and moves on to document successively higher-level syntactic structures from tokens to values to expressions and control structures to methods and classes. This is a classic approach to documenting programming languages." (p. 17)

You'll read all about boolean flip-flops, duck typing, lambdas, maps, metaprogramming, reflection and patterns of rhyming methods (collect, select, reject, and inject!). You'll also learn about new features in Ruby 1.9, like fundamental changes to text for Unicode support and the introduction of fibers fo coroutines. If it's in Ruby, it's almost certainly in this book. Chapters flow together nicely, although some could even stand on their own as educational materials for a computer science course (e.g. Chapter 7: Classes and Modules covers object-oriented programming and Chapter 8: Reflection and Metaprogramming elaborates on concepts like hooks, tracing, and thread safety).

In Ruby programming, difficult tasks are typically not only possible but often easy. It seems the authors take the same approach in their writing. For example, the complex topic of Domain Specific Languages (DSLs) sometimes creeps into deep discussions involving Ruby. Flanagan and Matz describe it simply and clearly: "A DSL is just an extension of Ruby's syntax (with methods that look like keywords) or API that allows you to solve a problem or represent data more naturally than you could otherwise." (p. 296)

During Ruby's first ten years, nearly two dozen books were in print in Japan but very few were available in English. That changed in 2004 when the introduction of Ruby on Rails created momentum for the language. A flood of new books followed, including Programming Ruby (2004, 2nd edition), The Ruby Way (2006, 2nd edition), Ruby for Rails (2006), and Learning Ruby (2007).

Programming Ruby, with lead author Dave Thomas, is self-described as a "tutorial and reference for the Ruby programming language." The Ruby Way, by Hal Fulton, was intended to complement Programming Ruby. Fulton noted: "There is relatively little in the way of introductory or tutorial information." Ruby for Rails, by David A. Black, has a clearly defined audience: "This book is an introduction to the Ruby programming language, purpose-written for people whose main reason for wanting to know Ruby is that they're working with, or are interested in working with, the Ruby on Rails framework." Learning Ruby, by Michael Fitzgerald, is a 238-page survey for "experienced programmers who want to learn Ruby, and new programmers who want to learn to program."

Programming Ruby and The Ruby Way each weigh in at over 800 pages. The binding on my copy of The Ruby Way came unglued and split in the middle after a year of use. The Ruby Programming Language is a slim, more manageable 444 pages and, in contrast, is the only one to cover Ruby version 1.9. In general, this is a great example of "less is more". Informative text boxes are sprinkled across the book with brief highlights on key technical thoughts. The first chapter's text box on "Other Ruby Implementations" (e.g. JRuby, IronRuby, Rubinius) could, however, be expanded into a several-page discussion of Ruby's various interesting architectures. Inclusion of IDEs and development tools (e.g. Eclipse, NetBeans, and TextMate) might also be helpful. These topics would nicely round out Chapter 10: The Ruby Environment.

The Ruby Programming Language has excellent cross-referencing. Section signs () feel like embedded HTML links that enable you to easily follow your coding curiosity around the book. Or you can just read it the old fashioned way, straight through. As an example, Chapter 3: Datatypes and Objects has subheadings (e.g. 3.1 Numbers) and well defined sections (e.g. 3.1.3 Arithmetic in Ruby.) The page-footers, table of contents and index also provide efficient navigational aids.

Artwork at the "edge of abstract expressionism" is something you might expect from The New Yorker magazine, but a computer book? The Ruby Programming Language introduces readers to "the edge of graphite expressionism". Original "smudgy residue" pencil drawings by why the lucky stiff creatively start each chapter.The Beatles' album cover for Sgt. Pepper's Lonely Hearts Club Band sparked intrigue and investigations into coded messages with hidden meanings. The same could happen here.

In Words and Rules: The Ingredients of Language, author Steven Pinker asks a simple question: "How does language work?" When I think about a new programming language, I have the same type of question in mind: "How does this language work?" Flanagan and Matz provide the answers in outstanding fashion. The Ruby Programming Language should help seasoned programmers who want to master Ruby. In addition, there is enough structure and sample code for determined novices to begin their programming explorations. Better than any other, this book defines the language. It is a classic and comprehensive guide for Ruby and a great 15th birthday present.

One long-time Rails developer sent me an email with their first impressions of The Ruby Programming Language: "I have been finding the book very useful, and I'm glad I did get it sooner rather than later." Matz said "Ruby is designed to make programmers happy." It looks like similar design thinking went into this book.

Brian DeLacey volunteers for the Boston Ruby Group

You can purchase The Ruby Programming Language from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

The Ruby Programming Language

Comments Filter:
  • hyperbole (Score:-1, Interesting)

    by Anonymous Coward on Monday March 03, 2008 @03:47PM (#22626956)
    "The Beatles' album cover for Sgt. Pepper's Lonely Hearts Club Band sparked intrigue and investigations into coded messages with hidden meanings. The same could happen here. "

    ummm talk about bringing something in completely out of the blue.....yes, I'm sure this programming book will be very similar to Sgt. Peppers......
    Besides, what exactly is "intrigue and investigations into coded messages....."? Will we all start deciphering treasure maps? Or perhaps purchasing books of arcane linguistic rules which allow us to manipulate complex electronic devices? Or has that already occurred? At least introduce some sort of musical/artistic metaphor theme in the beginning so this attempt to inspire some sort of creative dynamism isn't entirely bizarre. And can't we give the Beatles a rest? Do the Beatles always have to be the standard [creative reference] insert that brings up all the untrammeled free market capitalism + technology = wonderfulness tech-geek ideological koolaid shit? /end rant.

    Other than that I find the review to be useful and thorough-sounding though not entirely critical (as in analytic i guess)...
  • by cmdr_tofu ( 826352 ) on Monday March 03, 2008 @04:12PM (#22627238) Homepage
    Please mod the parent up. I am a fellow PERL->Ruby convert. While PERL always has a soft spot in my heart and has one of the best communities in the world, Ruby really is an *easier* language. It is clean, simple and extremely easy to write readable code. I am not a Rails expert, but for sysadmin stuff, Ruby and Python are great alternatives to PERL.
  • by pileated ( 53605 ) on Monday March 03, 2008 @06:22PM (#22628762)
    Well whilst the author is here, and while I'm part way through the book, let me ask a couple of questions. I should preface this by saying that I think Javascript the Definitive Guide made me hate Javascript all the more, while Java in a Nutshell and Java Examples in a Nutshell seemed to exemplars of good programming books. So needless to say I've puzzled over David's writing over the last few years. Why do I have such mixed feelings about books by the same author? I still don't know but maybe the following questions will help.

    I was reading along today when I came to this: "Assignment to a constant that already exists causes Ruby to issue a warning. Ruby does execute the assignment, however, which means that constants are nor really constant." Now this is a bit of a surprising statement. Isn't this an elephant in the room? Shouldn't it get more of an explanation?

    A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement? Is is a common Ruby idiom? If so might it not be wise to offer some explanation of why it's an idiom?

    As I think back on what I've read by David, and I realize I'm sort of leaving Matz out right here and don't know how much of the writing is his, I think I see a sort of matter of factness to it. My recollection of Ruby for Rails is that it is much more interested in explaining some of the odder parts of Ruby and Rails. Perhaps the authors just prefer a matter of fact style and figure that readers can go elsewhere for a explanation of what seem to me to be rather odd elements of Ruby?

    I don't say this as a criticism but really more of a question. Don't the two examples I cite seem sort of odd? If so could someone explain why they are not explained any further. Is that not the intent or style of the book? If the answer to the last is true I think that's fine. All authors write in the way that best suits them. But I ask out of curiosity. If that is the case I think it might give other readers a better clue as to what to expect from the book. Some will like the matter of factness; while others probably would like something else to augment it.

    And one last, sort of unrelated question: is anyone else disappointed by the drawings? When I read that the book would be illustrated by whytheluckystiff I thought that this would make a probably good book even better. But I find them very disappointing and far less visually interesting than what can be found on whytheluckystiff's web site.

  • by DragonWriter ( 970822 ) on Monday March 03, 2008 @08:08PM (#22629966)

    Once you learn python you ain't gonna get past hello world in ruby. You will
    sit there, look at the syntax and say what the hell do I want to learn this for.

    I learned Python pretty much immediately before learning Ruby, and I personally find Ruby more attractive, from a syntactic perspective, even before considering Python's interesting use of whitespace, which doesn't bother me as much as it does some people, but still isn't as attractive to me as it appears to be to Python fans.
  • Here be Dragons (Score:2, Interesting)

    by remitaylor ( 884490 ) on Monday March 03, 2008 @11:05PM (#22631352)
    Depends on what you mean by "normal Ruby." Because Ruby is so flexible, it's a great language for writing domain-specific languages (DSLs). You could argue that these aren't "normal Ruby" because they're specific to certain libraries/gems, but ... they really are just Ruby.

    Take this bit of Ruby code, from _why's poignant guide to ruby [] ...
    class Dragon < Creature
        life 1340 # tough scales
        strength 451 # bristling veins
        charisma 1020 # toothy smile
        weapon 939 # fire breath

    or checkout some Ruby code, using Markaby [] ... ( also written by _why )
    html do
        head do
            title 'Ruby is Fun'
            link :rel => 'stylesheet', :type => 'text/css', :href => '/style.css'

        body do
            p flash[:notice], :style => "color: green"
            self << @content_for_layout

    ... is that conventional Ruby? Well ... it's plain-old Ruby ... it's just uses Ruby's meta-programming magic to make DSLs. Ofcourse, DSLs aren't always what you may want, but Ruby is really, really great at making them, so you can make your code better represent what you're really programming. Like the Dragon class above ... if you've got lots of creature classes in your application, isn't that a nice and clean example of some syntax you could use?

    Ofcourse, cleverness isn't good simply for cleverness' sake. If a DSL really helps, or using some other Ruby "magic," then you should use it ... but these things shouldn't be used just because you can. It can lead to overly complicated code.
  • Ruby is (Score:3, Interesting)

    by Martin Spamer ( 244245 ) on Tuesday March 04, 2008 @08:28AM (#22634220) Homepage Journal
    When will /. grok the fact that is well know in parser/grammar circles, that Ruby is a language with a problem so big it can only be considered fundamentally Borked. Slashdot used to be a place where most people where on the ball and a crude attempt like this to gain traction by leeching the good standing off K&R would have been spotted and binned.

    This Ruby Grammar tree [] shows part of the problem, that god like Primary token in the middle. Ruby requires an arbitrary look-ahead parser, an LL(k) parser which are notoriously problematic. LL(k) parsers are inefficient, difficult to implement and result in ambiguous semantics. The result is that the Ruby grammar requires the token analyser and parser to be tightly coupled, a code smell in most programs. Token lexical analysis is dependent on syntactic context and syntactic context is dependent on semantic information from dynamicaly typed local variables. This is lethal for parsers.

    It is not possible to separate the lexical grammar from the language grammar, nor is it possible to properly describe the language grammar in a rigorous way. What defines a good language is that its semantics are well defined and consistent without reference to an underlying mechanisms, The fact that Ruby needs a LL(k) makes the semantics ambiguity, the parser implementation must make arbitratory assumptions about the semantics.

    The Ruby syntax cannot be defined with by rigorous context-free grammar, it is ambiguous. This is lethal in Parsers, because two different parser implementations can attach different semantics to the same source code. YES, that's right a Ruby program can run differently on two platforms, even if they have correctly implemented parsers.

    This cannot be fixed because this big problem with Ruby is the very thing that makes it attractive, the syntactic flexibility. That flexibility cannot be decoupled from semantic ambiguity, making it error prone to write and more importantly read.

    Wirth said of good languages, a language is not so much characterized by what it allows to program, but more so by what it prevents from being expressed.
    If you want a dynamic typed languages there are better choices with rigourous grammars.
  • by remitaylor ( 884490 ) on Tuesday March 04, 2008 @02:00PM (#22638484)

    If you really need to get your ActiveRecord pattern on (it's the name of a pattern, not a product) ...
    We know what ActiveRecord is ;)

    Thanks for the reply - SQLAlchemy looks great, tho it kindof "feels" like talking to a database, rather than objects, with "fetching" and "executing." I like ActiveRecord because you could swap out the backend of your objects, re-implement the API, and everything would still feel right. Even when I use plain text files as my backend, I try to implement an API compatible with ActiveRecord so, if I move to a database, it'll be easier to refactor.

    Ruby's got tons of ORMs, as well. I knew there were lots of great Python ones out there, I just didn't know them.

    These make for a sweet excuse to play with Python :D

"Yeah, but you're taking the universe out of context."