But there're not THAT many ways to do something even in Ruby, so you
pretty quickly pickup most of them. Moreover, for me learnig about every
new way of doing things was quite educational and I enjoyed greatly when
realizing that something that took me 20 lines of code before, now takes
5 if not 1 (in some cases). This is what I found true about Ruby:
Another (better) way => less code => less bugs => more fun
Gennady.
···
-----Original Message-----
From: Mark Volkmann [mailto:r.mark.volkmann@gmail.com]
Sent: Thursday, January 19, 2006 7:44
To: ruby-talk ML
Subject: Re: My Thought on the "Pickaxe book" (from a Ruby novice)
On 1/19/06, Kenneth Collins <pine29@myfastmail.com> wrote:
John, pick out the way to do something that seems most natural to you
and get familiar with that. Then ignore the rest. I think Ruby's "more
than one way to do it" was intended as a blessing, not a burden.
That's not really good enough though. I you ever have a need to read
Ruby code that someone else wrote, you'll have to understand every way
to do something. I love Ruby, but I'm not yet a fan of having many ways
to do something unless there are cases where each possible approach is
better than the others.
A particular thing I dislike is synonyms for methods in the built-in
classes. Sure I can choose to use the method name that makes the most
sense to me, but I still have to be aware of all the synonyms so I can
read code that others wrote.
--
R. Mark Volkmann
Partner, Object Computing, Inc.
Have you been paying any attention to this maillist? Oh, my gosh. The recent thread about counting unique elements in an array generated an armload of possibilities, all different, for example. Some people will do Regex magic, others use .inject or some tricky form of .each. One person uses symbolic hashes, another adds a new method to the class.
I must agree; the Pickaxe book is a great reference but a lousy tutorial. I don't *want* to learn the nine ways to iterate. I want to learn one, so I can move on to other ideas. If I spend a lot of time iterating, THEN I'll go read the later chapter on iterating and find the shorter, quicker, less-typing way of doing it. But if I get them all at once, I can't even figure out which one to use until I've figured them all out, and to then discover that they're all the same dang thing is just exasperating.
I don't need && and "and" because i already know how to use parentheses, for example. The key lessons and important concepts are lost in the noise of learning nine ways to do the same thing.
Well, I'm sure somebody's going to write the "Learn Ruby in 14 days" book or the "Ruby for Dummies" book or something else, and the Pickaxe book can just be The Reference Book.
···
On Jan 19, 2006, at 8:07, Gennady Bystritsky wrote:
But there're not THAT many ways to do something even in Ruby,
Is it any surprise that there are an almost infinite
number of ways to construct an algorithm to count unique
elements? I just don't see how that observation says anything
at all about Ruby as opposed to something about the theory of
algorithms.
Or more simply, wouldn't you have the same response if the
solutions were required to be in any other language you might choose?
If I were forced to point out a redundant *language feature* of Ruby
I would point to for/in versus each.
Gary Wright
···
On Jan 19, 2006, at 6:22 PM, Dave Howell wrote:
Have you been paying any attention to this maillist? Oh, my gosh. The recent thread about counting unique elements in an array generated an armload of possibilities, all different, for example. Some people will do Regex magic, others use .inject or some tricky form of .each. One person uses symbolic hashes, another adds a new method to the class.
