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

[John Maclean]

Chaps,

Ruby seems like a great language and the book's good too. However a novice like me won't be able to appreciate *.rb when there's soooo many examples of "there's more than one way to do it". I learn pretty quickly and even faster when I can understand a concept, test it and see that it works. How do you other novices feel about this?

This is not a rant/flame/plug my book/some other language is better posting

 

[Jules Jacobs]

Chaps,

Ruby seems like a great language and the book's good too. However a
novice like me won't be able to appreciate *.rb when there's soooo many
examples of "there's more than one way to do it". I learn pretty quickly
and even faster when I can understand a concept, test it and see that it
works. How do you other novices feel about this?

This is not a rant/flame/plug my book/some other language is better
posting

I think I do not understand what you mean...

If you mean that you have to create a new *.rb file to test something:
use IRB.
IRB is really good for testing. Just type: "irb" in a console.

Jules

 

[Doug Bromley]

I think what John is saying is that in the other languages he's used
there is a single way of doing something and once you've learnt the
concept - thats it. Done.
However, in the Ruby language there's multiple ways of doing the same
thing and having every example of a concept thrown at you can be a
little overwhelming and leave you feeling a little lost, asking - Why
not just have one way?!

Its a common frustration of people who've come from other programming
backgrounds besides Perl, etc.

Chaps,

Ruby seems like a great language and the book's good too. However a novic=

e like me won't be able to appreciate *.rb when there's soooo many examples=
of "there's more than one way to do it". I learn pretty quickly and even f=
aster when I can understand a concept, test it and see that it works. How d=
o you other novices feel about this?

 

[John Maclean]

Thanks Doug. More concise and articulate that I ever could be.

 

[Kenneth Collins]

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.

Thanks Doug. More concise and articulate that I ever could be.

--
Posted via http://www.ruby-forum.com/.

 

[Mark Volkmann]

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.

 

[James Britt]

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


James
--

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

 

[ara.t.howard]

Chaps,

Ruby seems like a great language and the book's good too. However a novice
like me won't be able to appreciate *.rb when there's soooo many examples of
"there's more than one way to do it". I learn pretty quickly and even faster
when I can understand a concept, test it and see that it works. How do you
other novices feel about this?

This is not a rant/flame/plug my book/some other language is better posting

think of it as learning to drive a short throw six-speed transmission - harder
at first - so much faster once you've got it. ;-)

-a

 

[Yohanes Santoso]

think of it as learning to drive a short throw six-speed transmission - harder
at first - so much faster once you've got it. ;-)

How true,

It took me sometimes learning to drive a machine of mine with such
transmission. Now I'm much faster.

YS.
1992 CBRF2 -- what? you're expecting a Ferrari?

 

[Mark Volkmann]

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.


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? =3D include? =3D key? =3D 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 =3D map
entries =3D to_a
detect =3D find
member? =3D include?
find_all =3D select

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

Integer:
next =3D succ

IO:
pos =3D tell

Kernel:
fail =3D raise
format =3D sprintf

String
next =3D succ
next! =3D succ!

Thread
fork =3D start
exit =3D kill =3D 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.

 

[James Edward Gray II]

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's interesting. I always use include?() so it doesn't matter if
I'm dealing with a Hash or an Array.

I am sure glad we can both have it our way.

James Edward Gray II

 

[gwtmp01]

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.

When I first starting reading this thread I was a bit puzzled as to
what features of Ruby are replicated in a variety of ways that might
cause confusion.

This message seems to indicate that the issue at hand is
library/api/class design and not necessarily Ruby the language.
I think it is an important distinction to make when discussing these
issues.

API/class/library design is *hard*. Being an effective programmer
in any object oriented language is as much (if not more) about learning
the library as it is about learning the language semantics.

I think there is probably room for improvement in the Ruby documentation
to help people learn about the library. An alphabetical list of methods
is helpful when you are looking for something in particular but when
you want to understand the structure of the API it isn't all that
helpful.

I think Smalltalk had the idea of 'protocols' as named collections of
methods that could be used to navigate through large class libraries.
Eiffel has the 'flatten' tool to produce a complete API of a particular
class by incorporating all the methods defined in ancestors into a
version of the class documentation. This would be helpful, for
example,
with the File class which seems to be missing some important methods
until you realize that they are inherited from IO and documented there
instead of with File.

So I think better documentation tools/standards might make programmers
more effective in discovering, understanding, and using the class
libraries.


Gary Wright

 

[Mark Volkmann]

That's interesting. I always use include?() so it doesn't matter if
I'm dealing with a Hash or an Array.

That's a good argument for using include? instead of the other possibilitie=
s.

I am sure glad we can both have it our way.

Since you've convinced me of the benefit of your way, I'll make that my way=
too.

 

[Mark Volkmann]

i couldn't disagree more. names, for variables or methods, are of utmost
importance to better expresses intention:

puts 'this makes sense even without knowing what set is!' if set.membe= r? 42

puts 'this is requires a comment' if s.has_key? 42

Good example. I guess what I'm looking for is an example of when
set.has_key? expresses intent better than set.member?. If there is no
such case then it seems to me the Set class shouldn't support
has_key?. Maybe this is related to what James said about being able to
use a different class without changing the code .. switching from a
Set to a Hash.

p signals.detect{|sig| sig.freq > 42}

p list.find{|x| x.freq > 42}

That seems like a domain-specific example. I guess you're saying that
you detect signals, you don't find them. I feel like Ruby would really
be a mess if we added lots of domain-specific method names to the
built-in classes.

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

Integer:
next =3D succ

IO:
pos =3D tell

Kernel:
fail =3D raise
format =3D sprintf

String
next =3D succ
next! =3D succ!

Thread
fork =3D start
exit =3D kill =3D terminate

for many synonyms consider duck typing usage as well - it's not only abou= t
making sense when reading:

Yes, that makes sense. I guess you could say that having synonyms
allows you to decide on a case-by-case basis whether you care more
about readability or the ability to change classes later without
changing code (for example, the case James pointed out where he could
switch between an Array and a Hash).

 

[Doug Bromley]

If you think the Ruby documentation is lacking you should try Pythons.
I've often noted their excuse for poor documentation is that the
language is easy to learn.

I don't think thats a valid excuse!

i couldn't disagree more. names, for variables or methods, are of utmo= st
importance to better expresses intention:

puts 'this makes sense even without knowing what set is!' if set.mem= ber? 42

puts 'this is requires a comment' if s.has_key? 42

Good example. I guess what I'm looking for is an example of when
set.has_key? expresses intent better than set.member?. If there is no
such case then it seems to me the Set class shouldn't support
has_key?. Maybe this is related to what James said about being able to
use a different class without changing the code .. switching from a
Set to a Hash.

p signals.detect{|sig| sig.freq > 42}

p list.find{|x| x.freq > 42}

That seems like a domain-specific example. I guess you're saying that
you detect signals, you don't find them. I feel like Ruby would really
be a mess if we added lots of domain-specific method names to the
built-in classes.

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

Integer:
next =3D succ

IO:
pos =3D tell

Kernel:
fail =3D raise
format =3D sprintf

String
next =3D succ
next! =3D succ!

Thread
fork =3D start
exit =3D kill =3D terminate

for many synonyms consider duck typing usage as well - it's not only ab= out
making sense when reading:

Yes, that makes sense. I guess you could say that having synonyms
allows you to decide on a case-by-case basis whether you care more
about readability or the ability to change classes later without
changing code (for example, the case James pointed out where he could
switch between an Array and a Hash).

 

[Thomas Snide]

The book is an excellent beginning and a decent reference, but I wish
that the topics were introduced in a more logical manner (from simple to
complex, or essential to might-never-use). In a metaphor, if the topics
are 1 (easy) through 10 (complex), I think the book reads like this:

1,3,5,3,4,7,2,6,8,7,6,9...

I'm ready for the Ruby for Dummies book. Anyone?

 

[Harold Hausman]

I'm ready for the Ruby for Dummies book. Anyone?

I've skimmed a bit of "Learn to program", maybe it's what you're looking fo=
r:
http://www.pragmaticprogrammer.com/titles/fr_ltp/index.html

Especially if you've decided you like the pragmatic prgrammer style.

-Harold

 

[Schüle Daniel]

Chaps,

Ruby seems like a great language and the book's good too. However a novice like me won't be able to appreciate *.rb when there's soooo many examples of "there's more than one way to do it". I learn pretty quickly and even faster when I can understand a concept, test it and see that it works. How do you other novices feel about this?

This is not a rant/flame/plug my book/some other language is better posting

Hi Maclean,

I consider myself also as newbie and I can understand your problem
it's sometimes difficult to remember "all the ways" and I
can only agree with Mark Volkmann
the problem is, when I see grep, find, scan, match ..
I cannot tell (without having to ask google for example)
whether they are just aliases or differ in their semantic
I think to be a little bit "pythonic" wouldn't harm,
one precise name for one thing

Regards, Daniel

 

[Alexandru Popescu]

#: (e-mail address removed) changed the world a bit at a time by saying (astral date: 1/19/2006 9:10 PM) :#

i couldn't disagree more. names, for variables or methods, are of utmost
importance to better expresses intention:

puts 'this makes sense even without knowing what set is!' if set.member? 42


puts 'this is requires a comment' if s.has_key? 42

With all due respect, I would say these tricks are used _after_ you master the API.
The discussion (as far as i got it) was about leaning it (so _before_ mastering the API). And having
6 methods with different names is kind of confusing while learning. You are loosing a lot of time
trying to identify if there are any differences between them.

I agree with you that after mastering the API these may become handy.

cheers,
/alex
--
w( the_mindstorm )p.

ps: I guess this is pretty much in the idea of a series of blog posts that happen lately about human
interfaces vs good APIs vs ... (iirc the start was somewhere on Martin Fowler's blog)

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

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

p signals.detect{|sig| sig.freq > 42}

p list.find{|x| x.freq > 42}

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

for many synonyms consider duck typing usage as well - it's not only about
making sense when reading:

if i have a lib that does this

exit if bug

then i can use it like this

require 'lib'

or like this

successfully_loaded = Thread::new {
begin
require 'lib'
true
rescue SystemExit
nil
end
}.value

puts "Thread#exit called in lieu of Kernel#exit - whew" unless successfully_loaded


the interface polymorism gained by synonyms is often handy.

if i design a table class an initially design it around a hash and use

table.store key, value

in my code, but later decide i need to store multiple values under one key and
switch to a database backend i can simply have a store method that looks like

def store key, *values
...
end

and then start using

table.store key, v0, v1, v2

without changing the other code. if i'd used

table[key] = value

all over the plase initially i'd have a strange mixture of methods and would
require a special [] method for storing one value, which would quickly become
code smell. in this case the abstract idea of 'storing' something under a key
was more appropriate to my design in the first place so using this interface
saved me grief later.

synonyms exist elsewhere for clarity in ruby too

unless == if not

thankfully.

regards.

-a

 

[Alex Combas]

I'm working through the book myself
but I personally find it a little tedious.
Its not a bad book so far, but I would
have to rate it just so-so compared to
other programming books I've read.

One way I think it can improve is
by having unified source code for programs.
They seem to have this style that they
show a little piece of a program, then another
piece a few pages later, then another piece
maybe even a few chapters later... its really
frustrating not being able to get a program
to run because its code is scattered across
half the book.

I would upgrade my rating from so-so to good
if they would unify more of the source code
in the next version of the book.

Just my $0.02