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.
Re:Trash (Score:4, Insightful)
Personally I don't like Ruby, but that doesn't mean the language is not good. It has some interesting syntactic sugar. And Rails didn't really invent anything new. MVC and ActiveRecord for example had been done to death before, but it packaged them in an attractive and simple little box with a nice glue language that made 80% of building a web app simple. It's always the remaining 20% that's hard, and I think Rails was not designed well enough to enable developers to jump the last hurdles. Much of the criticism I've read in the past few months about Rails is related to problems with how the public Rails API is designed and how too many developers are using runtime hacks to extend objects instead of having sane, language-specific inheritance/override methods for extension purposes. Again, nothing to do with Ruby the language, but you can't reall discuss Ruby without Rails because in the real world it's what currently drives its adoption. I doubt many people are writing desktop apps with it.
Let this be a warning to framework designers: your language, runtime and toolset better match the amount of hype you pile on your work. It's not good enough to have a cool language to go along. The popular Perl (Mason, etc), Python (Django, etc) and PHP frameworks prove it can be done.
Re:Let's face it: (Score:4, Insightful)
Yup. It's strange - folks will post comments like "Ruby can't scale for a huge enterprise app!". The odd thing there is that for a huge enterprise app the opcode execution speed is probably not going to be the primary bottleneck. In fact, almost anything that reaches over a socket into a database is going to have bottlenecks that have nothing to do with how fast the Ruby interpreter can navigate an AST or set up a stack frame.
Re:Coroutines (Score:4, Insightful)
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.
Re:Which to learn first: python or ruby? (Score:3, Insightful)
After 12 years of Perl, though, I hope I'm done with it. Either Ruby or Python are going to take you far as a programmer, since both languages are modern and elegant, in different ways. Perl 5.x is like BASIC, in that it teaches you bad habits.
Ruby does have a sense of enlightenment, though. I can't comment about Python, concerning this aspect. It seems that its "Lispiness" gives you a sense of "Aha" quite often. I feel that I am learning a lot about comp sci using Ruby that I never got in C, C++, Assembly, Perl, or PHP. All languages gave me an occasional "Aha" moment, but not as often as Ruby (combined, maybe). This is part of the fun, IMHO.
I am no Rails user, either. I'm currently limiting myself to straight Ruby and JRuby. I'm doing "pure shell scripting" and tiny apps.
The whole ideas of DSL's and Metaprogramming and the fact that "everything is an object" (like Smalltalk but not like C#/Java) are way cool and modern. These concepts are changing the way I think about programming in ways Perl couldn't. To my dismay, every full-time Perl developer I talk to (so far) isn't convinced "unless there are lots of Ruby jobs."
I could be wrong, not actually learning much about Python (donning asbestos suit), but I feel that Ruby is a more powerful, more elegant language than Python, for most problems at hand (but certainly not all). Python, on the other hand, is more mature (including speed) and has more code libraries. Both are incredibly powerful and elegant, however, and are worth learning. (I may pickup Python some day, myself).
I'm not really commenting much on PHP at this time, having had several years in this (mostly web) scripting language. Perl is more directly comparable to Ruby and Python.
Whatever you pick, both languages have a C (native) version and have active Java and
Pick one and consider taking a look at the other. Ruby is really fun, for most everyone who has sat down and really tried it. I assume Python can say much of the same.
I picked Ruby, for now, and have (mostly) not been disappointed.
Re:Let's face it: (Score:4, Insightful)
Performance is how fast an app runs for a given amount of hardware. This is usually measured in how fast it is with respect to a single core of a single CPU.
Scalability is how well the app behaves when you just throw more hardware at it. That is, if you give it another ten CPUs and five gigs of RAM, will it be able to take advantage of that?
Ruby performance sucks. It is impossibly slow, even compared to languages like Perl or Python. I make no excuses for that. Look at the performance improvements of rails 1.9, and you'll get an idea of just how bad 1.8 is.
But Rails scales very well -- in the simplest example, the default configuration for Rails nowdays is a mongrel cluster, even on a single machine. It's a really strange and perverse design where you put a load-balancing proxy in front of at least three Rails/Mongrel webservers, each listening on a different local port. And unless you've done something stupid, this will Just Work, right out of the box.
But as long as your database server can handle it, you can just throw another server behind that load balancer. A lot of work has gone into making load balancers and database servers scalable, and you can take advantage of that, if you really need to. (For awhile, Ruby is still going to be the bottleneck.)
What this means is that I probably would not write a performance-critical desktop app (like, say, a game) in Ruby. But for web apps, it makes sense. If you can write the same app twice as fast, with half the people, you can afford to throw four times the server resources at it -- and as a bonus, you got it up in half the time as your competitor, who thought scalability == performance.
Re:Trash (Score:4, Insightful)
Actually, the absence of features for explict overriding (vs. implict overrides as the default) is something to do with Ruby the language (just like dynamic rather than static typing, etc. are inherent to Ruby as a language.)
OTOH, the complaints about "monkeypatching" are pretty much just a variation on the complaints about dynamic typing: "the language doesn't bind your hands enough, and someone else might do (or has done) something I don't like that was enabled by that."
Fine, look, everyone knows where to find Java and C if they need them. Beyond that, if you don't like the way the Rails team (or certain third-party plug-in writers) have used the power to reopen classes and objects, its not like there aren't plenty of other Ruby web application frameworks, ORM solutions aside from ActiveRecord, and libraries available for most uses in Ruby. Maybe the one library you really want was programmed by someone whose ideas about how best to use the language don't match yours, but that's possible with any language no matter what features it has. If you want code written to your specs, you've either got to write it yourself or pay someone else to do it for you, and complaining about a language because someone has used it to write a library using techniques you don't like isn't going to solve anything.
I dunno, I find it pretty easy to discuss Ruby without Rails. Rails is certainly the framework that made Ruby really visible in the US (though I gather it was fairly popular in Japan even before Rails), but I think that as it is getting exposed, the size of the non-Rails Ruby community compared to the Rails segment is probably growing.
I would imagine that if there weren't quite a few people doing that, you would have fewer GUI toolkits for it. And, of course, its also useful for system scripting; not every programming task is about a big app, whether web or desktop.
Re:Let's face it: (Score:3, Insightful)
FYI, an Apache worker process can also handle 1 request at the same time. And Apache solves that by... spawning multiple Apache worker processes!
Wirth was Wrong (Score:3, Insightful)
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 your language gets ported and supported and people write libraries for it."
You do make a good point - a standard definition of Ruby behavior in ambiguous corner cases would be good to have. I suppose, as it is now, the Matz compiler is the correct behaviour. Strange - it never occurred to me that there might have been other perl compilers out there I should worry about. Back in the day I spent all kinds of hellish time trying to resolve compatibility between Pascal implementations (really their extensions that were made to make them more useful).