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 
John M. wrote:
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
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.
Thanks Doug. More concise and articulate that I ever could be.
On Thu, 19 Jan 2006 21:25:46 +0900
On 1/19/06, Kenneth C. [email protected] 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.
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.
John M. wrote:
Thanks Doug. More concise and articulate that I ever could be.
On Thu, 19 Jan 2006 21:25:46 +0900
Mark V. wrote:
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.
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - 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
[email protected] writes:
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.
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?
On Thu, 19 Jan 2006, John M. wrote:
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
On 1/19/06, James B. [email protected] wrote:
to do something. I love Ruby, but I’m not yet a fan of having many
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.
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.
On Jan 19, 2006, at 12:40 PM, Mark V. wrote:
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 G. II
On Fri, 20 Jan 2006, Mark V. wrote:
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.
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
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}
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
On Jan 19, 2006, at 10:43 AM, Mark V. wrote:
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 W.
On 1/19/06, [email protected] [email protected] wrote:
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
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 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.
exit = kill = terminate
for many synonyms consider duck typing usage as well - it’s not only about
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).
On 1/19/06, James Edward G. II [email protected] wrote:
On Jan 19, 2006, at 12:40 PM, Mark V. wrote:
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.
That’s a good argument for using include? instead of the other
possibilities.
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.
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?
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!
On 1/19/06, Thomas S. [email protected] wrote:
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
for:
http://www.pragmaticprogrammer.com/titles/fr_ltp/index.html
Especially if you’ve decided you like the pragmatic prgrammer style. 
-Harold
#: [email protected] 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.
.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)
I definitely agree that you could probably stumble along by learning
just one way but you’ll be left in the wilderness looking at someone
else’s code. At least that’s how I feel right now.
Ruby’s versatility is like English. You can speak English with a very
heavy Spanish accent or German accent and even your grammar could be
heavily influenced but it will still be valid English nonetheless. To
stretch the metaphor further two non-native English speakers coming
from different languages usually have trouble understanding each
other’s English.
I still wish there were more books out there on Ruby and Rails.
That’ll will change drastically in 2006. I’m sure our more
experienced rubyists would benefit from a Ruby Pocket Reference
(actually available in Japanese from Oreilly).
How long did it take most of you to feel comfortable enough in Ruby to
understand other people’s code as well?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs