Programming Ruby: The Pragmatic Programmers' Guide 231
| 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.
About the Ruby Gems chapter... (Score:5, Insightful)
More on Ruby Gems here [rubyforge.org].
Ruby is great. (Score:4, Insightful)
The first edition of this book came in really handy in college, when I'd have to find creative ways to do something (especially text manip), where C++ or Java just seemed to get in the way.
Ruby is quick to learn, and Dave Thomas from Pragmatic is a great teacher...he came to my school for a little lecture/speech one day, and talked on the merits of Ruby, which is how I got introduced to it.
The network aspects of Ruby are great too. Small concise ruby programs can do a whole lot
Re:It's got to better than... (Score:1, Insightful)
Ruby + C == World Domination (Score:2, Insightful)
A graceful and dynamic OO language coupled with, well C - fast, portable (more or less) and used everywhere.
Because it is so easy to go back and forth between Ruby and C you get the strengths of both languages (also all those C libraries out there).
If you haven't used Ruby, your missing out to say the least - and this book is an excelent way to get started.
Ruby and Perl over Python for cross-platform dev (Score:5, Insightful)
What I find unacceptable in Python is that whitespace (tabs) determine the logical flow. I once wrote a script on Windows and moved it to UNIX; the UNIX editor handled tabs differently, and my script wouldn't work without a few hours of attention just to set the spacing right.
Ruby has Pascal-like blocking. That alone makes it superior to Python. And for all other situations that do not require a good OO implementation, there is Perl.
Re:About the Ruby Gems chapter... (Score:2, Insightful)
Re:Too many new languages at once... (Score:5, Insightful)
That's really difficult to quantify. How do you define 'more powerful'?
Personally, I prefer Ruby's clean syntax to Perl's (especially when compared to OO programming in Perl, which is just a disaster from an aesthetic viewpoint, as well as the amount of work that is required from the Perl programmer to do OO). There are a few features that Ruby has that Perl doesn't: continuations, code blocks and exceptions.
and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?
This tends to be an area where there is a lot of dispute between the two camps. I've already revealed my bias toward Ruby, so take that into consideration regarding the following comments: In Python I get the feeling that object orientation was tacked on. Granted it was tacked on much earlier in the language's development than it was in Perl where OO programming is essentially a do-it-yourself project. There are a couple of nagging issues in Python which give me this idea:
1) why do I need to include 'self' as the first parameter of each method definition?
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.
Python now also has something similar to Ruby's iterators (though they're a bit different), but something to keep in mind is that Ruby's standard libraries and built-in classes were built from the ground up with iterators in mind - I think that's a big advantage that Ruby has over Python.
I suggest that you try to write a smallish program in each language (pick a project that might take an hour or two) and see how each language 'fits' with the way you think. I find Ruby fits my way of thinking much better than Python does, but as they say, YMMV.
Great book, great language (Score:3, Insightful)
I also think that the philosophy espoused in the chapter on 'Duck Typing' could apply to other agile languages like Smalltalk and Python. I haven't really seen these ideas come out as strongly in other language communities as they have in the Ruby community.
I don't think there is any one thing about Ruby that's truly revolutionary, but the combination of features (code blocks, very consistent and complete standard libraries, OO'ness, etc.) make it very compelling. Do yourself a favor and buy the book - learning Ruby can help you think differently about how you approach problem solving in your day-to-day programming work (even if you don't program in Ruby for pay).
Re:Too many new languages at once... (Score:2, Insightful)
Re:Too many new languages at once... (Score:2, Insightful)
Language selection parameters (Score:5, Insightful)
There are several kinds of programmers, at least when it comes to the language selection:
The first kind gives us applications that cannot be easily ported to other OSes or platforms, because everything is so low-level that it is tied to the underlying architecture. The second kind gives us duplicated effort and software that becomes unmantained whenever the main developer quits, since few other programmers know the language in which the project is written. The third kind gives us solutions that make sane people scream, like shell scripts that start with #!/usr/bin/php -q.
It's fun to learn other programming languages, and contribute to the development of new ones, but in the open-source environment it is also very important to remember that you a) do not and should not work in a vacuum, b) that there are freaks who will probably try to run your software on bizarre setups, and c) that there is always a chance that circumstances will require that you quit working on that project.
This is the reason why when picking a development environment for a project it is important to consider things like portability, maintainability, and suitability for the purpose. I'm not sure I can justify writing something in Ruby at this point, seeing as its adoption is far below Python, while its advantages over Python are slim to questionable.
Re:Too many new languages at once... (Score:2, Insightful)
Re:Language selection parameters (Score:3, Insightful)
Great developers know two rules that keep them happy:
1. Choose the best tool for the job
2. Given that, know that the best tool is not always the best choice (e.g. everybody in your company knows Java but you want to write in PHP)
And I suppose even before all of this is, learn at least a few languages. It will give you the clue factor that each language does indeed have its strengths and its weaknesses.
Re:Language selection parameters (Score:2, Insightful)
If everyone adopted the perspective you seem to present, people would only be interested in math because of what it can do, not what it is.
Re:Language selection parameters (Score:1, Insightful)
as a complete non programmer (Score:2, Insightful)
Based on this, ruby is better thought out. ON the other hand, I started to puke at all the ruby way stuff.
Re:Good/bad points (Score:1, Insightful)
I liked to have the corrected versions. TIA