The Ruby Way
I've wanted to tackle Ruby for quite some time. Luckily, Addison-Wesley just sent me a copy of The Ruby Way, Second Edition by Hal Fulton. This is one of those books that makes me think publishers feel the need to sell books by the pound. The sad part about that is that, in many cases, books printed by the pound contain tons of fluff and useless information. Not so with The Ruby Way. Every page contains gems valuable for anyone who wants to program with Ruby.
But this isn't a book review, per se. If it were, I'd recommend The Ruby Way without reservation. Anyone even remotely interested in Ruby should get this book, now. It's worth every penny of $39.99 US.
But here's what really inspired me to write about this book. There are pages upon pages devoted to the unintuitive twists in the Ruby language. There are so many quirks that I'm almost afraid to tackle my first Ruby program.
To cite one example from the book, in the following code, x ends up equal to "false".
y = false
z = true
x = y or z
The reason for this is that Ruby evaluates = before it evaluates the "or". I imagine this would be terribly unintuitive to a Ruby newcomer, and would lead to a lot of wasted debugging time. Even now that I know this juicy tidbit, I'm sure I'd make the above mistake at least a few times before I could consistently remember how Ruby works.
Obviously, you can force Ruby to evaluate the "or" expression this way:
y = false
z = true
x = (y or z)
If this was a rare quirk of Ruby, I wouldn't give it much thought. But, as I said, there are pages upon pages of explanation on how Ruby deviates from traditional programming practices.
Granted, I'm new to Ruby. Maybe you Ruby programmers out there are keenly aware of the various oddities in Ruby and take them for granted. In some cases I can see how the quirks aren't quirks at all, but necessary decisions on the part of Ruby designers in order to give Ruby more power. I'm still at the point where I'm asking, "Why on earth would anyone design a lanaguage to do that?" Maybe if I programmed in Ruby for six months, I'd find out why all of these design decisions make sense. My first impression, however, was that I'd never remember all these oddities when tackling my first Ruby programs, and I'd spend the first month trying to figure out why nothing works the way I expect it to work.
Nevertheless, it would be foolish to take this as a launching point for a Ruby rant. The overwhelming success of Ruby speaks for itself. There must be an ultimate payoff for learning it.
So here's my question to you Ruby aficianados. Did you have trouble adjusting to The Ruby Way of doing things? How long did it take for you to get used to Ruby's approach to objects, classes, instances, and the various oddities? How long was it before you started to feel like you really began tapping the power inherent in the language, and how much of that power do you attribute to Ruby's unique approach?
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Play for Me, Jarvis