Loading
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?
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- One Hand Slapping
- What's the tweeting protocol?
- Trying to Tame the Tablet
- RSS Feeds
- Developer Poll
- Reply to comment | Linux Journal
5 hours 41 min ago - Reply to comment | Linux Journal
8 hours 13 min ago - Reply to comment | Linux Journal
9 hours 31 min ago - great post
10 hours 6 min ago - Google Docs
10 hours 28 min ago - Reply to comment | Linux Journal
15 hours 17 min ago - Reply to comment | Linux Journal
16 hours 3 min ago - Web Hosting IQ
17 hours 37 min ago - Thanks for taking the time to
19 hours 14 min ago - Linux is good
21 hours 12 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
Developer Poll
Comments
any...
any language is always a challenge specially when new...it just kinda difficult to say it's has its quirks in a blog...lots will condescend first then give an opinion...=)
ruby eccentricities
I came to ruby from bash/perl/awk and c/c++. there are a lot of differences, e.g. the extensive use of blocks, but only one has really proved difficult for me to absorb:
x = 0
puts "do what?" if x
=> do what?
str = ""
puts "do what?" if str
=> do what?
only false and nil are false, all other values are true. those used to languages that act like c will derive endless entertainment debugging things equivalent to
if ! blah
do_something
else
do_something_else
end
because their eyes will not see what is happening. for me this typically involved error handling code that is difficult to test and hence sometimes skipped; of course the false branch may never run due to the incorrect assumption that 0 is false.
I decided to try ruby not just for the sake of fooling around with a new language, but because of ruby on rails. my background there is long ago writing a modest web app using CGI.pm and DBI for MySQL. rails, had it existed then, would have allowed my to do in a few days what took me more than a month at the time.
to prep for rails I wrote a fairly extensive suite of tools to access Amazon S3, and I found ruby to be pleasant to write and read and to be accompanied by all the libs I needed (yes, CPAN is bigger, but I only care about what I use).
Agreed Rails is good, but Ruby?
I'd prefer Rails on Java or Rails on C++, why Ruby? Just another of syntactical learning curve. I don't think Ruby has gotten closer to English than any other language, more likely to have introduced confusions of its own among programmers of different backgrounds. I say no more languages need to be developed, unless one that is revolutionary, that introduces a new paradigm. And it must be the language that gets the headline, not a framework built on top of it, such as the case with Rails. I'd love if somebody build Rails on top of something else, is it possible? Anyone?
I did a quick test on the z
I did a quick test on the z = x or y in ruby 1.8.5
what's mentioned in the article is completely false.
z turns out to be true.
Your comment is false
In the interactive interpreter
>> y = false
=> false
>> z = true
=> true
>> x = y or z
=>true
>>x
=> false
Thus, the article is correct.
This line:
>> x = y or z
=>true
is actually:
>> (x = y) or z
=>true
Use || or be safe with
Use || or be safe with parenthesis if you're unsure. Not hard at all.
$ ruby -v
ruby 1.8.5 (2006-08-25)
$ irb
irb(main):001:0> y = false
=> false
irb(main):002:0> z = true
=> true
irb(main):003:0> x = y or z
=> true
irb(main):004:0> x
=> false
irb(main):005:0> x = y || z
=> true
irb(main):006:0> x
=> true
irb(main):007:0>
Ruby
There is a payoff in learning it. You will be amazed at how few lines of code it takes to get things done. My approach to learning a new language (I have learned many in 51 and one-half (as of today) years of programming) is to start right in trying to write some little program I want. That results in "fighting" the language for a while before I get the hang of it and start accomplishing things.
Get the Pick Axe book. I use it constantly (the PDF digital version) to look up the details of the many methods. I used its descriptions of Ruby and how to do things to get myself going. I was amazed at how often I discovered that Ruby did the right thing when I pushed the enevelope a bit and just coded what I thought should work and sure enough it did. Yes there were times when it didn't work too... The automatic variable typing took a bit of getting used to. And I had to stop trying to get it to act like Turbo Pascal where I first started doing OO programming 21 years ago.
FWIW I came to Ruby without knowing Perl, Awk, or Python. My friend who knows Perl can see the many similarities between it and Ruby. Before Ruby my language of choice for quickly accomplishing a computing objective with minimum code was REXX which originated at IBM. You already figured out that I am an old mainframe programmer. That's all there was... And only a few of them at that.
Try Ruby. You'll like it. I started doing Ruby in July of this year.
linux girl
yes, I have trouble adjusting to The Ruby Way of doing things, just so used the java way, maybe the java way is better :)
The Ruby Way 2nd Edition
Hi Nicholas,
I just found "The Ruby Way 2nd Edition" via Amazon and I was not sure to buy, because in the german version of amazon there aren't any reviews on this book yet... Well, I googled (sorry Mother Google for abusing your mighty brand) and I came here... Nice Blog, and thanks for your review.
Greets
Simon
This is the 2nd book to read after the pickaxe
Nicholas,
Well, basically, the title says it all. When I give presentations or trainings on Ruby I always recommend to read the Pick Axe book first and the Ruby way second. It is not a book for beginners for the reasons that you highlighted. But for Ruby programmers with some experience it is full of wise advices and usefull pieces of code in many different domains.
Definitely worth the money.
Ruby on Rails
I've been using RoR for about 4 months now. It's very easy to pick up and has been a blessing. I'm an application developer so this was my first web application. Ruby is a bit weird - but I don't need to use any of the powerful features it has.
The ruby way
Next to C, Ruby is my favorite language, by a wide margin.
And I have been programming for years in ruby and have not
been bitten by the = or precedence issue mentioned in this
article, so I wouldn't be put off by this issue at all.
Ruby is the first language that made OO programming come alive
for me, probably in large part due to the influence of the
pickaxe book, as much as the language itself. In any event,
give ruby a whirl. The principle of "least surprise" is only
rarely violated.
Every language has quirks
Ruby has fewer quirks than most languages. Studying the list of quirks is not a good way to learn a language, as you would run screaming with C's quirks or C++'s quirks or Perl's quirks running to hundreds of pages as opposed to several pages.
x = y or z
Hi Nicholas,
My friendly advice:
do not think like any procedural language. This is ruby. Just let your mind and imagination flow. And i assure you, ruby just fits intro your thoughts easily (unlike any other programming language you can think of).
so if i were to choose between
1) (x = y) or z
2) x = (y or z)
for the meaning of "x = y or z", i'd choose the former.
Why? That's how my brain naturally think. I just plain read from left to right. I don't have to think in C or Pascal or Java for that matter, really.
kind regards -botp
Right, just read from left to right
What about Chinese and Muslim coders dude? They read from right to left. What a shallow mind you have. I bet you don't know how to evaluate this:
x = y + b * a - z + m / u % v = x or j = 41 and -1
What do you think that gives? Oh, right, just read from left to right. I get it!
Most programmers think
Most programmers think mathematically, and most math dictates that:
x = false or trueis
x = (false or true)Intuition
I got hooked on Ruby because, very quickly, I found that I could guess at the correct syntax for whatever I wanted to do, and be right almost all the time.
Are there things that tripped me up? Sure. I prefer a language that has a small set of ground rules that are used to drive the rest of the language; Ruby is good for this, but it has its share of, "This is how it works, except when it doesn't."
Still, over all, Ruby seems to have fewer WTF? moments than most.
To answer your actual
To answer your actual question, I was having "wow" moments in the first few hours I spent with the language. I doubt it took more than a month for me to get reasonably comfortable and productive with it. I've been using it for a few years now, and I'm still occasionally learning new things about the language (or being reminded of features I'd forgotten); but the core language didn't take very long at all.
I'm a software engineer, and
I'm a software engineer, and I'd worked with a lot of languages before I tackled Ruby. Ruby is, by far, the most sensible and programmer-friendly language I have ever used. Unlike in, say, C++, most of the seeming "gotchas" are there for a reason, rather than just being ugly historical quirks. Once you start to grok Ruby's core idioms, you'll find yourself becoming amazingly productive. Things like Blocks and Ruby's phenomenally powerful "case" statement don't take long to learn, and are immediately useful.
The example you picked is not a Ruby quirk, per-se; it's really a feature that Ruby inherited from Perl. Most languages before Perl only had one logical "or" operator, usually the "||" operator. For convenience (and readability, believe it or not) Perl added a second "or" operator with the same semantics as "||" but with ultra-low precedence, which enabled certain boolean statements to have "unsurprising" semantics without resorting to lots of nested parenthesies. The example above has exactly the same result in Perl (although it's uglier, since Perl doesn't have first-class boolean types). If you want it to work the way you expect, use "||" - just like in C.
This is a strength, not a weakness. You can use a lot of the same operators and idioms that you are used to from other languages like C, Java, or Python; and slowly work your way into using more advanced Ruby idioms. Sure, there's a lot there to learn; but you don't have to learn it all at once.
However, you emphatically should NOT be starting with The Ruby Way. The Ruby Way is more of a cookbook and second-level guide for advanced users. Kind of like the Effective C++/Java books. Pick up a copy the Pickaxe (Programming Ruby, 2nd Ed.) instead.
Thanks for the comment
In fact, I would have used || anyway, since I'm used to that. But it still struck me as odd for Ruby to evaluate = first. I don't do Perl, so I missed the similarity.
I appreciate the advice about Programming Ruby. I will get that book, but I tend to gravitate toward the more advanced books like this one anyway. I've been a programmer for a long time, so I usually jump in the deep end of the pool. That isn't always a good idea, but it's just me. ;)
It's not a bug it's a
It's not a bug it's a feature :) "or" is designed to be used in 'do_something or exit' expression groups not the actual boolean OR operator (|| is used for that as you know).
The Pickaxe
If it's any help, the full text of the first edition is available at http://ruby-doc.org/docs/ProgrammingRuby/.
Seriously, I can't push this book enough; it's one of the most well-written and enjoyable technical books I've ever had the pleasure of reading (and I, like you, have little patience for novice-level stuff). It's also an essential reference to the core classes (although somewhat less essential since the advent of ruby-doc.org). Oh yeah, it's written by the authors of The Pragmatic Programmer, if you're familiar with that book.
Or you could always hit the [in]famous Poignant Guide, if you prefer short and mind-bending ;-)