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?
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Happy Birthday Linux
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- New Version of GParted
- Tor 0.2.8.6 Is Released
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- All about printf
- Blender for Visual Effects
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide