Slashdot Mirror
Programming Ruby: The Pragmatic Programmers' Guide
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.
http://www.rubycentral.com/book/
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
...it was written twice. Chad Fowler wrote it the first time while he was on vacation in Europe. Then he had to rewrite it after his Powerbook was stolen on his trip home. Argh!
More on Ruby Gems here.
The Army reading list
Ruby is like the glue that holds alot of my programs together.
:)
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
Why didn't reviewer say 'Brilliant, but slightly flawed'.
Who could hang a name on you
Oh come on someone had to do it.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
The non-Pragmatic Programmers' Guide
Yet Another Web Site
...thanks to Ruby Central for sponsoring it.
A BitTorrent of the presentations is available here.
The Army reading list
It comes from the pick and axe on the front cover of the book :-)
Many of us, Rubyists, have been introduced to Ruby by the very first version of this book. And the first version is online and is still handy for consulting:
http://www.ruby-doc.org/find/pickaxe
But this new version covers all the changes from Ruby 1.6 to Ruby 1.8; making this book a must have.
As far as I know, it's available as PDF and as paper, and I'm gonna have both.
Thanks Dave for helping the occident know Ruby and Matz for creating the must inspiring language for me.
Cheers!
I have to admit I've never tried Ruby. I use C++, Perl and PHP all the time. I just got started learning Python because of a book review I saw here on Slashdot. In fact, I also got interested in Python because someone suggested I use it to solve a problem that needs extensive parsing (Perl strength, nightmare in C++) and large, pointer-addressable arrays of objects(C++ strength, Perl weakness).
Anyway, I was told Python was a good compromise. I've just started into it, but maybe Ruby is a better fit for this problem? I can only learn so many languages at once, and still have time for my projects.
Can I get any advice? Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
I'm not sure what you mean by platform or "just runs". If you mean, do you need a certain OS? No. Do you need Apache in particular? No, though Apache and Ruby work very well together. Do you need any external web server? No. One of the standard libraries that comes with Ruby is WEBrick, which is a standalone webserver. You can get Ruby running web apps using WEBrick on any OS, no other software required.
Along those lines, let me throw in a quick plug for Ruby on Rails. Rails makes web application using the MVC model very quick and easy. The default setup includes a WEBrick servlet so you can have your application listening for requests minutes after installation, literally.
Visit #ruby-lang and #rubyonrails on freenode for more information about Ruby in general or Rails.
Jacob Fugal
...are also available on ruby-doc.org here.
The Army reading list
We have built an extremely robust distributed testing framework for a Java-based multi-agent system completely implemented in Ruby (see Cougaar for more on the project and the ACME testing framework). We were told on starting this project (at DARPA) that it would never work...I really like proving people wrong ;-) My company is using its Ruby expertise as a differentiator in the market and getting very good reception.
Why's Poignant Guide to Ruby has got to be the most entertaining Ruby read out there....
Tweet, tweet.
Well not exaclty, but the combination of Ruby and C is unbelievably powerful.
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.
-- Thou hast strayed far from the path of the Avatar.
I can live with Python's having no statement terminator (";" in C, C++, Perl, Java).
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
I got my copy a couple of weeks ago. It's a great followup to the first edition - much more information. I've already learned new things from it even though I've been programming in Ruby over 3 years now.
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).
Could you give some examples? I'd love to fix stuff. if it's broken.
Why not e-mail me directly as well as posting here: dave pragprog.com
Cheers
Dave
These Guys just hired about 4 Ruby programmers to work with Rails (a Ruby-based web application framework that uses an MVC model that's generating a lot of interest in Ruby)
I suspect that you'll see more small shops using Rails (and thus Ruby) in the coming months.
Comment removed based on user account deletion
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.
If you open yourself to the foo, You and foo become one.
What really struck me about Ruby is how it "solved" many of the issues that had been bugging me about other languages (and I've used a bunch). Such as:
* In many languages, a built-in method will either mutate an object "in-place", or it will work on a copy of the object and return that, leaving the original untouched. Sometimes pretty arbitrarily. But in Ruby, there's a convention like in Scheme (and maybe others): methods ending in "!", like "array.sort!" will sort the array in-place, and the other methods return a new sorted copy. Nice! One annoying issue solved.
And booleans end in "?" which is nice too. instead of "is_foo" you write "foo?".
* In many languages, you can have fields on objects, and you can have methods. So when you have "attributes" (like "first_name", "last_name" on a customer object), do you use fields which are simple and straightforward with natural syntax:
object.first_name = "Joe"
or do you use methods, which can be refactored:
object.setFirstName("Joe")
So, do you go for the awkward syntax, keep the fields private, and allow refactoring? Or do you expose the field, and rewrite all the code later when the requirements say "name must default to 'Anonymous Coward' when no name set"? Or do you convolute your code around the issue?
Ruby solves this elegantly. There are NO PUBLIC FIELDS! Instead, you always use methods:And no goofy "set_first_name"
AND you don't even have to create the basic getter/setters! Ruby classes have a built-in class method that creates them dynamically:Very elegant! Well-written programs are very clean and light.
* No need to use exceptions for non-local flow control.
Ruby has exceptions, but sometimes you want to jump out of a deep tree search (for instance), and an exception is what you need: "raise SearchFinishedException" or something like that.
But is that a good idea? Using "exceptions" for flow control? No because exceptions are, well, *exceptional*, they don't occur normally.
Ruby helps me here too. It has catch()/throw() which is a simple alternative to exceptions, designed for nonlocal flow control. And of course you can write your *OWN* flow control because it has continuations (encapsulate program flow into an object for later return).
Anyway Ruby is such an amazingly elegant language, and the pickaxe book is the appropriate companion! Buy a copy now, even if you don't use Ruby, it's very clear and easy to read (not just because of the language, but because of the enthusiastic and talented authors).
i own the first edition, it's a good tutorial-type ruby book
Ever notice that there's tons of Perl, PHP, and Ruby snippents all over the web but very few Python snippets? It's because you really can't copy Python from the browser and paste it into a text editor! The whitespace gets changed and the program breaks in very hard-to-diagnose ways. It's rather funny.
There are many features of Python that will be adopted by future languages, but I doubt that significant whitespace is among them.
What I find unacceptable in Python is that whitespace (tabs) determine the logical flow.
It also means you cannot take advantage of the auto-indenting feature of editors.
If I need to go back and wrap a chunk of code in an "if" statement, I can put a { at the beginning and a } at the end and the editor will correct the indenting.
Python will require me to go line by line and insert spaces or tabs.
Please drop me an e-mail (dave pragprog.com) and let me have them: I'll fix up any you find.
Cheers
Dave
a) See http://www.rubygarden.org/ruby?RealWorldRuby
b) It's a marvelous tool to increase productivity; I wrote something in ~2 hours which parses ~70 XML documents in ~10 directories and creates 150+ static HTML pages (for a help system shipping with the application) from moderately complex business logic off of 5 template files.
Changed or added an XML document? Run the ruby script. Need an HTML tweak? Change one template file and run the script. 3 seconds to parse the XML documents (and apply Textile markup to certain sections) and 3.5 seconds to create the HTML.
Ruby allowed me to very quickly write a complex tool that now saves me a huge amount of time every time I use it. Even *if* no companies were hiring specifically for Ruby skills, having a tool in your belt that makes you stand out is still a Great Thing.
Python will require me to go line by line and insert spaces or tabs.
No offense, but that's a load of crap and evidence that you've never actually coded anything in Python. If you had, you'd know that Python comes with a fully functional editor called IDLE, which includes auto-indentation. You can also select whole chunks of code and press ctrl+] to indent or ctrl+[ to unindent. Explicit scope declarators serve no purpose but to frustrate the programmer who forgets to declare that last '}' of 'end' statement. All Python forces you to do is write clean, readable code.
I downloaded both python and ruby when I started thinking about learning how to program. I cd download and install correctly both languages on my Win2K OS laptop, but ruby had two things python did not: a really neat intro tutorial out of berkeley, and some sample progams (like abouncing red ball in a box) to play with. For kids learning to progam, this sort of basic hold your hand stuff is invaluable
Based on this, ruby is better thought out. ON the other hand, I started to puke at all the ruby way stuff.
Sorry for an off-topic rant by an old man, but this pointless duscussion has just reminded me a recent story comparing Java to C# when someone apparently devoted to the macho side of programming made the bald and unvarnished statement: Real Programmers write in Perl.
Maybe they do now in the 21st century, in this postmodern era of blogs, smartphones, and "user-friendly" software, but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not Perl. Not C. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.
Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I'll call him Mel, because that was his name.
I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster -- drum-memory computer. Cores cost too much, and weren't here to stay, anyway. (That's why you haven't heard of the company, or the computer.)
I had been hired to write a FORTRAN compiler for this new marvel and Mel was my guide to its wonders. Mel didn't approve of compilers. "If a program can't rewrite its own code," he asked, "what good is it?"
Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LGP-30 and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP-30 booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.
Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located. In modern parlance, every single instruction was followed by a GOTO! Put that in Pascal's pipe and smoke it.
Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the read head and available for immediate execution. There was a program to do that job, an "optimizing assembler," but Mel refused to use it. "You never know where it's going to put things," he explained, "so you'd have to use separate constants." It was a long time before I understood that remark.
Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.
I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.
Mel never wrote time-delay loops, either, even when the balky Flexowriter required a delay between output characters
No, it is not more powerful than Perl. But than again, nothing is. The points is not what is more powerful per se, but rather which is more powerful in your hands and which one best fits your own brain. At this point it is extremely important to mention Parrot: "The amazing project [...] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)."
Perl, Python and Ruby, while not the only ones, are certainly the most important languages for the Parrot development. Parrot will not be considered ready until all of them are fully supported, and at this point Parrot will be their main target Virtual Machine, running each of them and allowing them to interoperate. At this point it won't matter which of those languages you personally use, because whatever you choose you will still have access to all of the libraries and module, class and object, of each of them.
Few years ago I will tell you: "go for Perl because of CPAN." Now my advice woule be: "go for whatever you please, for in few years it won't really matter. We will be able to work on the same project, write the same application. I will write my part in Perl 6, you will write yours in Ruby, someone will write in Python and another one in Scheme. We will all subclass our classes, invoke our methods, use our objects, and we will produce a single, monolithic Parrot application anyway."
Just imagine picking up some fresh, young and cutting-edge language designed weeks ago--or even designing your own language--and having every module from CPAN available at once, working just fine using your new language syntax. This is the future Perl, Python and Ruby. Interoperation instead of competition.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."