[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: My Thought on the "Pickaxe book" (from a Ruby novice

Gennady Bystritsky

1/19/2006 4:08:00 PM

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.



4 Answers

Dave Howell

1/19/2006 11:22:00 PM

0


On Jan 19, 2006, at 8:07, Gennady Bystritsky wrote:

> But there're not THAT many ways to do something even in Ruby,

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.



Tim Hunter

1/19/2006 11:26:00 PM

0

Dave Howell wrote:

> 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.

How about "Sams Teach Yourself Ruby in 21 Days"?
http://www.amazon.com/gp/product/0672322528/sr=1-5/qid=1137713058/ref=pd_bbs_5/103-0423753-3758208?%5Fenc...

dblack

1/19/2006 11:38:00 PM

0

Gary Wright

1/19/2006 11:47:00 PM

0


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.

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