From: Mark Volkmann <r.mark.volkmann@...>
Date: 2006-01-20T03:40:37+09:00
Subject: Re: My Thought on the "Pickaxe book" (from a Ruby novice)

On 1/19/06, James Britt <james_b@neurogami.com> wrote:
> Mark Volkmann wrote:
> > 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.
>
> How many different ways are there for doing various tasks?  2? 3?
>
> For how many fundamental operations?
>
> Do the variations follow some general pattern or principle?
>
> Can anyone offer examples of multiple ways of doing something
> fundamental, and point out where it may be confusing?

I guess I'm more annoyed by synonyms than multiple syntax approaches
because there don't seem to be too many of those.

> I've read complaints about Ruby allowing both if/then and unless/then,
> as well as the option to put the test either at the start or end of the
> expression.  I don't find this a remarkably complex idea, but perhaps if
> it is poorly introduced then the options may seem arbitrary.
>
> > 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.
>
> In the long run I'd rather have to periodically go to ri or ruby-doc to
> learn something if it means I can choose message names that better
> express my intentions.

I guess that's the part I don't get. In the majority the cases, I
don't see how choosing a particular synonym better expresses the
intention.

For example, in the Hash class, has_key? = include? = key? = member?
When I see include? and member? it's not immediately obvious to me
whether they test whether a given object is present as a key or a
value. has_key? and key? are more clear and I don't see a benefit to
having both of them.

That may be the best example. Here are some others.

Enumerable:
  collect = map
  entries = to_a
  detect = find
  member? = include?
  find_all = select

Hash:
  store = []=
  merge! = update
  has_value? = value?

Integer:
  next = succ

IO:
  pos = tell

Kernel:
  fail = raise
  format = sprintf

String
  next = succ
  next! = succ!

Thread
  fork = start
  exit = kill = terminate

In most of these cases you could argue that one would guess that they
are synonyms. Still I think many will have nagging doubts about
whether there are subtle differences and decide to take the time to
look up their definitions. For example, is Thread.kill really the same
as Thread.exit? kill sounds so ominous. Maybe there is a small
difference, you'll think to yourself. Verifying these things makes it
take longer to read code, which is really the main point of my rant.

--
R. Mark Volkmann
Partner, Object Computing, Inc.