Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

The Ruby Programming Language 172

Posted by samzenpus from the read-all-about-it dept.
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 amazon.com. 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 More

The Ruby Programming Language

Comments Filter:
  • Why do computer software worth less than paper-printed books? Last I check, software codes do not destroy rain forest like books.
    • It can't be free because the author wants to get paid for his work on it.

    • Re: (Score:2)

      by Unoti ( 731964 )

      Why do computer software worth less than paper-printed books? Last I check, software codes do not destroy rain forest like books.
      Every computer language I've ever learned since BASIC I learned initially by reading in the bathroom, or while taking a break outside at work. Paper has always had the upper hand there over electronic, and will continue to have the upper hand there for a few more years.
      • Every computer language I've ever learned since BASIC I learned initially by reading in the bathroom

        So which language wastes more water, Ruby or Java?

    • Re: (Score:2)

      by nuzak ( 959558 )
      Books aren't exactly printed on rainforest hardwood either. Primarily it's cattle ranching that destroys rain forests.
  • 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.


    Error parsing sentence. Unable to comprehend.

    Is this like the use of the word "your" instead of the correct "you're" as seen in more and more sentences, including a graphic on MSNBC.

    Sorry, I'll stick to the old three score and twain. That's 62 in the "new" math.

  • Thanks for the review! (Score:5, Informative)

    by davidflanagan ( 645311 ) on Monday March 03, 2008 @02:41PM (#22626892)

    Thanks for the kind review Slashdot! Thanks, Brian!

    You can browse the table of contents of the book and read the beginning of each section at O'Reilly's website [oreilly.com].

    You can find another review of the book at rubyinside.com [rubyinside.com]

    • Comment removed based on user account deletion

      • Re: (Score:2)

        by scragz ( 654271 )

        For anyone else with programming-inclined progeny, take a look at one of why's other projects, Hackety Hack [hacketyhack.net]. It's an interactive Ruby environment for beginners.

        In the 1980s, a language called BASIC swept the countryside. It was a language beginners could use to make their computer speak, play music. You could easily draw a big smiley face or a panda or whatever you like! But not just BASIC. Other languages like: LOGO and Pascal were right there on many computers.

        In this century, you may have dozens of p

        • Comment removed based on user account deletion

        • Re: (Score:2)

          by dylan_- ( 1661 )
          Thank you! I've been considering stuff for my nephew and I was actually thinking of a ZX Spectrum emulator (Speccy was my first computer), to show how things worked, but this seems to have actual modern applications that can be understood. Helpful people like you are the reason I still read Slashdot comments. Thanks again!

    • Re: (Score:3, Interesting)

      by pileated ( 53605 )
      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

      • Re:Thanks for the review! (Score:5, Informative)

        by davidflanagan ( 645311 ) on Monday March 03, 2008 @05:42PM (#22629012)

        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.
        Have you read the JavaScript book recently? The 5th edition is an improvement over the fourth... It is different than Java in a Nutshell--simply because it is a "definitive guide" rather than a "nutshell". This Ruby book is probably more like my JavaScript book than my Java books, so if you end up liking it well enough, maybe you'll give the JavaScript book another chance :-)

        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?
        Frankly, I don't know the reason that constants are not constant. I could have pressed Matz to enlighten us on this point, but I suspect that the answer is not a simple one and would have been difficult to explain. In earlier drafts of the book I did actually draw attention to these rough spots in the language because they did, indeed, seem strange to me. As I spent more time with Ruby, however, I came to appreciate it more, and re-reading my drafts I felt I was being unnecessarily critical of the language I was documenting. So, as you surmise, I was left just being matter-of-fact about it.

        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?
        This is not a very common idiom, nor is it even very well known. The particular line of code you cite is, of course, extreme: I'm taking the destructuring parallel assignment syntax to an unreasonable level of nesting to test the reader's understanding of the concept. Its not a common idiom, but it is part of the language, so I document it. It actually seems pretty cool to me, not really an elephant in the room. In this case, were I writing a less formal book, I might have commented on how cool it is. In the same way, in a less formal book, I could have commented on how strange it is that constants can have their values changed.

        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.
        Please keep in mind that we had to get these drawings through the internal bureaucracy at O'Reilly--we were asking a lot of the production and design teams to include them. I shouldn't speak for _why, but I think his goal for these drawings was to keep it mellow, and to be stylistically distinct from his work for the Poignant Guide [poignantguide.net].

        • Re: (Score:2)

          by pileated ( 53605 )
          Thanks for the detailed response David. If I do need to use Javascript again (I currently don't) I'll take a look at the new edition. I must say I'm very fond of the newest Java in a Nutshell and Java Examples in a Nutshell.

          I suppose what I've written are more questions about the style of the book than anything else and I think you've answered them well. I hope they'll be useful to other potential readers of the Ruby book. And I look forward to finishing it myself.

          I realize that my comments on the drawings
        • Classes are constants in Ruby, so it's good to be able to modify constants (so you can modify classes).

        • Re:Thanks for the review! (Score:5, Informative)

          by shirai ( 42309 ) on Tuesday March 04, 2008 @12:12AM (#22632162) Homepage
          There is a very good reason that constants are not constants which relates primarily to the way the Ruby is "compiled." I put "compiled" in quotes because as Ruby users know, there is actually no difference between compile time and run-time. There is, however, a phase where you load the code in from your Ruby files at which point the classes are defined through executable statements. Constants are usually defined in classes at this point as well.

          If you couldn't redefine constants, the second time you loaded a file you would throw errors. The reason why you would reload files is in a running development environment such as a framework like Rails or Merb. I also have a web framework (currently private but possibly we'll open source later) so I know this issue pretty intimately.

          To clarify, the way it works is this: You are viewing a web page through a Ruby framework. The page rendering code is in a class. You want to make a change to a class so you go to the file and edit it. This may include changes to a constant. When you view the page again (by hitting refresh), the Ruby framework checks to see if the file has changed. If the file has changed (e.g. the constant we changed), then the file gets reloaded. Although we don't want to be changing constants in production, the ability to change constants in development mode is valuable. The alternative is we have to restart the server. The fact that it throws a warning is actually a good compromise because it means it's not normal behavior, but it is acceptable in certain circumstances.

      • 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?

        In the context of Ruby, where "private" methods and instance variables are just a wee bit harder to get at rather than actually private, not enormously, though it would probably be cleaner (and consistent with h

        • Re: (Score:2)

          by doti ( 966971 )

          I've rarely seen a multiple assignment much more complex than the simple swap case ("a, b = b, a") in Ruby; I don't think anything remotely like that example is common.
          I don't do Ruby yet, but in Perl I see this multiple assignment is often used.
          Examples:
          my ($x, $y) = ($i % $width, $i / $width);

          my ($from, $to, $subject, $date) = get_email_info($email_header);

          my ($dirname, $basename) = $path =~ m{^(.*/?)([^/]+)$};

        • Re: (Score:2)

          by pileated ( 53605 )
          I agree with you that it's good to have a variety of books and styles on Ruby. I didn't mean to criticize this one, just to get a better explanation, esp. when the author was available. To me it seems odd to say that "constants are constant" and then move on without further explanation. I believe David's response explained just why he did so: he felt speaking about some of the languages rougher spots might seem overly critical.

          I come from a different background that thinks something is more easily understo
  • Did someone here actually use callcc for something "real" in production code that could not be done someway else or was best implemented with callcc? For what? Can you make an example? I am really just curious (personally I love callcc, but only ever used it as a style exercise).

    • Re: (Score:3, Funny)

      by sfraggle ( 212671 )
      You can use it to implement [soulsphere.org] the Intercal COME FROM [wikipedia.org] statement. No serious modern programming language should be without this feature.
      • This is actually the coolest thing ever :)
        I didn't know about COMEFROM. This is pure genius:

        $ cat test.rb
        require 'comefrom.rb'
         
        come_from 'a label'
        puts 'hello'
        label 'a label'
         
        $ ruby test.rb
        hello
        hello
        hello
        hello
        hello
        hello
        hello
        hello
        ...

        • didn't know about COMEFROM. This is pure genius:

          Why is joke syntax genius?

          • Why is joke syntax genius?

            Just because it remained me the old times... you know

            10 PRINT "I am the coolest guy"
            20 GOTO 10
            Making it the other way around is funny and brilliant.

    • Re:Coroutines (Score:4, Insightful)

      by krog ( 25663 ) on Monday March 03, 2008 @03:32PM (#22627508) Homepage
      Call/cc can become useful in web applications where you have a batshit insane workflow. Seaside [seaside.st], the Smalltalk web framework, bets the farm on it. It's in other places like Perl's Jifty too.

      Most of the web apps I write wouldn't benefit from this sort of treatment, so I haven't jumped in too far, but call/cc has its uses for sure.
      • Just to be clear, Seaside isn't "batshit insane". :) Frankly, I love the way it works... will it be the Next Big Thing (tm)? I have no idea... I don't even know if it's really a good idea in the long run. But it should makes building stateful transactions in the stateless world of the web incredibly easy.

        • Re: (Score:2)

          by krog ( 25663 )
          I never said Seaside was batshit insane, only the workflows of the apps which are well-suited to it. Seaside isn't insane, it's just esoteric.
          • Actually, I would disagree. In traditional webapps, we build systems that are stateful and transaction oriented. Thus is fundamentally a consequence of the way the web works. Basically, the nature of the web has dictated how we build our systems. Seaside, OTOH, allows one to build apps in a much more straightforward manner. Workflows with the user are, in code, represented as just that. Workflows. It is, I think, a much cleaner way to look at the problem.

            But, we are getting off the topic, here, which

            • Re: (Score:2)

              by krog ( 25663 )
              In traditional webapps, we build systems that are stateful and transaction oriented. Thus is fundamentally a consequence of the way the web works.

              Not so fast! I think you trivialize how well 90% of websites fit into a stateful, transaction-oriented architecture -- especially when hosting and serving requirements are factored in. I don't think that's a consequence of the way the web works, but rather the opposite; I think the way the web works is a consequence of the tools that power most of it.

              Of course S

            • But, we are getting off the topic, here, which is, of course Ruby.


              To bring it back on topic, there is a Ruby continuation-based web application framework (Borges [rubyforge.org]) that is (or began as) a port of Seaside 2 to Ruby.

    • Re: (Score:2)

      by arevos ( 659374 )
      I've seen some rather nice syntax sugar for monads implemented with callcc in Ruby.

    • Did someone here actually use callcc for something "real" in production code that could not be done someway else or was best implemented with callcc?

      I don't have the code for either handy, but I've used it to implement an asynchronous discrete event simulations environment (loosely based on DEMOS [demos2k.org]) and a stateful-backtracking set up for intertwining syntax and semantics in a natural language system.

      In the first case, a multi-threaded version has proved easier to maintain, and in the second case Moore's

  • I may have to grab this. The Ruby scripting capability of Google Sketchup is calling out to me, and I loves me some 3D modeling. :-)

  • Another good book to pick up... (Score:3, Informative)

    by tcopeland ( 32225 ) <(tom) (at) (thomasleecopeland.com)> on Monday March 03, 2008 @02:59PM (#22627114) Homepage
    ...if you're doing Rails apps is Advanced Rails [oreilly.com] by Brad Ediger. It's got a ton of helpful hints on all sorts of things - sessions, memcached, how Rails uses Ruby's dynamic features, how plugins work, how to do complex associations, details on REST, etc etc.

    The nice thing is that he doesn't fool around with explaining the simple stuff that you know already if you've done even one Rails app; he gets right down to business. Of course there are always interesting gotchas [blogs.com], but this is a book every Rails developer should have.

  • The Ruby Programming Language is a slim, more manageable 444 pages and, in contrast, is the only one to cover Ruby version 1.9.


    This is true of the dead-tree editions of the three major books you list, though it may be worth noting that the 3rd Edition of the Pickaxe (Programming Ruby) is currently available (in PDF) as a beta book and covers Ruby 1.9.
    • That it does, but it's not as good as this one.

      • That it does, but it's not as good as this one.

        The Ruby Programming Language is a great book, from what I've seen of it (I've read a bit on Safari), but I still like Programming Ruby (and The Ruby Way and Ruby for Rails -- a great general Ruby book that doesn't have as strong a Rails focus as the name might suggest -- even though neither of those two has yet been updated for 1.9), too. I wouldn't particularly want to do without any of them, though if I had to choose only one right now, I might lean toward T

  • David Flanagan is responsible for writing O'Reilly's old, unreadable JavaScript books... not a lot of confidence that he did much better on Ruby. If an O'Reilly book has been written by Flanagan, I don't buy it.

  • collect, select, reject, and inject (Score:5, Funny)

    by A nonymous Coward ( 7548 ) * on Monday March 03, 2008 @03:29PM (#22627460)
    Sounds like they should have listed Arlo Guthrie as co-author.

    I bet mods don't get the reference and mark me down.

  • On Friday, a bunch of people asked me about Ruby on Rails. I decided it was time to educate myself. After reading O'Reily's book that provided an overview of Rails, I felt that I should spend some time understanding the underlying language.

    By pure coincidence, I bought this book. It's well-written. Last night, I couldn't put it down.

    Ruby is a complex, but expressive language. I can't speak from real-world usage, but Ruby appears to provide many subtle variations in its syntax as a way of simplifying

    • Here be Dragons (Score:2, Interesting)

      by remitaylor ( 884490 )
      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 [poignantguide.net] ...
      class Dragon < Creature
      life 1340 # tough scales
      strength 451 # bristling veins
      charisma 1020 # toothy smile

      • Re: (Score:2)

        by GWBasic ( 900357 )
        As you can probably tell, I haven't made it to the part of the book that covers DSLs... But it looks like they are what I want.

  • Ruby is (Score:3, Interesting)

    by Martin Spamer ( 244245 ) on Tuesday March 04, 2008 @07: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 [flickr.com] 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.

    • Wirth was Wrong (Score:3, Insightful)

      by bill_mcgonigle ( 4333 ) *
      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.

      Wirth was wrong. At least for common definitions of 'good'. I dumped pascal for perl in the 90's, and the only people I know of who still actually use it are maintaining old Delphi. Yeah, there are some others I'm sure, but the practitioners of the art have decided Pascal is no longer useful.

      Bill says, "a good language encourages a strong community, so y

Slashdot Top Deals

If imprinted foil seal under cap is broken or missing when purchased, do not use.

Close