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.
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: 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. |
"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.
Thanks for the review! (Score:5, Informative)
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]
Re:Huh? Is this the "new" English? (Score:5, Informative)
Drawings are the work of Rubyist-extraordinaire "why the lucky stiff" [whytheluckystiff.net] and technical reviewers include well known Rubyists David A. Black, Charles Oliver Nutter, and Shyouhei Urabe.
The rest of it should be passable English.
Another good book to pick up... (Score:3, Informative)
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.
Re:Let's face it: (Score:3, Informative)
Ruby isn't lightning fast, but its fast enough for lots of things, and its easy enough to interface with C (if you're using the main implementation) or Java (if you are using JRuby) if you need to refactor identified bottlenecks in a lower-level, higher-speed language.
As to scalability, I don't know of any particular problems with Ruby there. Green threads pre-1.9 and a Python-style GIL in 1.9 limit the ability to benefit from SMP architecture in one process on the one side, but the standard library comes with some fairly useful distribution tools. Is not, say, Erlang or Oz, but then neither is Java.
WaveMaker seems to offer a Web application framework and a visual builder for web apps that is tightly tied to that framework. This might be a viable Java alternative to Rails for some web applications, but its certainly not a general alternative to Ruby. And its suggests that your scalability complaint is probably similarly a misplaced reference to the various complaints (the main and most frequently cited one of which was retracted by the people making it) about the scalability of Rails, for which there are many alternatives even within the Ruby universe (Waves, Camping, Nitro, Sinatra, Wuby, etc.)
Re:Thanks for the review! (Score:3, Informative)
Re:Which to learn first: python or ruby? (Score:3, Informative)
http://docs.python.org/tut/
http://diveintopython.org/
http://www.swaroopch.com/byteofpython/
http://openbookproject.net/thinkCSpy/
http://www.greenteapress.com/thinkpython/
http://en.wikibooks.org/wiki/Non-Programmer's_Tutorial_for_Python
Re:Thanks for the review! (Score:5, Informative)
Learning Ruby from Rails (Score:2, Informative)
Why? Because Rails gives you a *reason* to learn Ruby. How often do people learn a certain programming language "just cause"? While I love to learn new languages, I tend to learn them when I need to or when there's a great reason to
I actually didn't learn Ruby by learning _all_ of Rails
With 1 line of code ( to set the database connection ), I found that I was more productive in an interactive Ruby console than I was using SQL or using many of the libraries that wrapped the databases I was using. That was my *reason* ( or rather, *excuse* ) to learn Ruby.
So
P.S. If you're curious about what I'm talking about, using Ruby / Rails' ActiveRecord to work with your database(s)? Let's say I wanna interact with a little sqlite database
require 'activerecord'
ActiveRecord::Base.establish_connection
class User < ActiveRecord::Base; end
class Site < ActiveRecord::Base
has_many
end
puts Site.count
puts Site.find_by_name('Slashdot').users.map &:email
Or, if I have Dr. Nic's Magic Models [rubyforge.org]
require 'dr_nic_magic_models'
ActiveRecord::Base.establish_connection
# don't even have to define a classes
puts Site.count
puts Site.find_by_name('Slashdot').users.map &:email
Does Python have something equivalent? Sure, I'm sure Python's database ORM's make it just as easy (altho I doubt something as dynamic as Dr. Nic's Magic Models exists
Re:Thanks for the review! (Score:5, Informative)
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.