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 Maclean
MSc (DIC)
07739 171 531
John Maclean 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
--
Posted via http://www.ruby-forum.com/\.
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.
On 1/19/06, John Maclean <info@jayeola.org> 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
--
John Maclean
MSc (DIC)
07739 171 531
--
Wisdom is the reward you get for a lifetime of listening when you'd
have preferred to talk.
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 Thu, 19 Jan 2006, John Maclean 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
--
strong and healthy, who thinks of sickness until it strikes like lightning?
preoccupied with the world, who thinks of death, until it arrives like
thunder? -- milarepa
anne001 wrote:
I have no use for databases, and the whole
book uses one single database example, it
seems -- I am allergic to the word "song", it
shows up too many time in that book, every
other word it seems --
I agree, I agree, I agree... The "Jukebox" example made me down.
Furthermore, many concepts were built upon this example which made the
things worse.
But generally it is a good book and it *IS* a classic.
Thanks Doug. More concise and articulate that I ever could be.
On Thu, 19 Jan 2006 21:25:46 +0900 Doug Bromley <doug.bromley@gmail.com> wrote:
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.On 1/19/06, John Maclean <info@jayeola.org> 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
>
> --
> John Maclean
> MSc (DIC)
> 07739 171 531
>
>
>--
Wisdom is the reward you get for a lifetime of listening when you'd
have preferred to talk.
--
John Maclean
MSc (DIC)
07739 171 531
ara.t.howard@noaa.gov writes:
On Thu, 19 Jan 2006, John Maclean 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.
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?
Probably true.
But I am finding I can't really do much writing of the code, or driving of the car until I'm upwards of pages 120. Contrast this with the first Perl Book I had from O'Reilly and it's a bit frustrating. Sorry about the perl analogy but it's my best and most recently used language.
I'm badly hung up on trying to find out things like:
variable scope.
declaration.
loops/branches/control_structures.
They are presented in bits and pieces with a lot of forecasted references (if you want to know the details about 'xxx' see pages '...') which makes for a LOT of page turning.
Because of the extensive differences between Ruby and where many people will be coming from, I would think more time spent on the pre-conditions of writing code would be helpful. I don't understand the framework for writing the language.
As a specific example (again contrasting to Perl) the introduction of objects and method from external objects or files is going to be required much sooner in Ruby than it will with Perl. But it's not really explained until quite a distance in the book that, unlike perl, a filename doesn't match the modulename or object you are loading. Perl would use something like Time::HiRes to pull a module into the code where Ruby would use something like 'time' or 'hires' or some path implied string like 'time::hires'.
But the module has little of any bearing on the objects affected and the name used in the require statement is not going to match the name found on your filesystem. These inconsistencies, by not being pointed out and addressed specifically, have lead to enormous frustration and a very bad first impression of the language (being immature and inconsistent). Inconsistencies at this level can be very scary to a newbie.
It was past page 100 that I found out that the subject of scope was not the same as what I would have expected after decades of programming in other languages. This was another nasty surprise. And after 100 pages of other stuff. This explained a lot of problems I was finding in my code that I was playing with.
I realize that I've biasedly presented these two issues as problems with the ruby language. Well, I can do that because I'm too new to know any better and I have yet to "see the light" on why this is a good thing in contrast to all my experiences so far in life. From my background, SCOPE is a flaw and non-strict pragmas is a condition to be aware of when tracking bugs. But like I said, I'm new.
I am reminded of the Monty Python skit where the Inspector was going on about the sweet titled "Crunchy Frog" and that, since it contained real live dead unboned dead frogs lightly killed and lovingly coated in sucrose that the box should contain a large red label "CAUTION: Real Live Unboned Dead Frog".
ara.t.howard@noaa.gov wrote:
On Thu, 19 Jan 2006, John Maclean 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
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 Maclean wrote:
Thanks Doug. More concise and articulate that I ever could be.
On Thu, 19 Jan 2006 21:25:46 +0900
--
Posted via http://www.ruby-forum.com/\.
Tom Allison 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
Probably true.
But I am finding I can't really do much writing of the code, or driving of the car until I'm upwards of pages 120. Contrast this with the first Perl Book I had from O'Reilly and it's a bit frustrating. Sorry about the perl analogy but it's my best and most recently used language.
Which book was that? The only Perl book I've read is "Programming Perl," which is much like "Programming Ruby." It is meant to be the EVERYTHING book, which gives you probably way more information that you ever needed (the Perl book explained how strings are stored - good to know, but not something you need to know right away.) It's not meant to be quick dive into the language.
So, I don't feel the Pickaxe book is good for just learning the language, especially if you don't have a solid programming/comp sci background already. You'll probably need to do some tutorials, etc. However, it is really good if you want to know how to do a particular thing.
Just my thoughts...
-Justin
ara.t.howard@noaa.gov wrote:
On Thu, 19 Jan 2006, John Maclean wrote:
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.
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.
--
R. Mark Volkmann
Partner, Object Computing, Inc.
Justin Collins wrote:
Tom Allison 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
Probably true.
But I am finding I can't really do much writing of the code, or driving of the car until I'm upwards of pages 120. Contrast this with the first Perl Book I had from O'Reilly and it's a bit frustrating. Sorry about the perl analogy but it's my best and most recently used language.
Which book was that? The only Perl book I've read is "Programming Perl," which is much like "Programming Ruby." It is meant to be the EVERYTHING book, which gives you probably way more information that you ever needed (the Perl book explained how strings are stored - good to know, but not something you need to know right away.) It's not meant to be quick dive into the language.
Learning Perl (actually from the CD).
Programming Perl is a fantastic book but only after you've exhausted the Learning perl book. It's a fine example of a reference book. As I read through the Pragmatic Ruby book I am seeing where it has that potential. I'm starting to come to terms with it.
So, I don't feel the Pickaxe book is good for just learning the language, especially if you don't have a solid programming/comp sci background already. You'll probably need to do some tutorials, etc. However, it is really good if you want to know how to do a particular thing.
Well, I don't have that exact background but I've always found books like the typical "21 days" and "dummies" are mostly useless. no pain, no gain... 
ara.t.howard@noaa.gov wrote:
On Thu, 19 Jan 2006, John Maclean wrote:
Mark Volkmann 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'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
On 1/19/06, Kenneth Collins <pine29@myfastmail.com> wrote:
--
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
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
On Jan 19, 2006, at 10:43 AM, Mark Volkmann 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.
Hi --
Well, I don't have that exact background but I've always found books like the typical "21 days" and "dummies" are mostly useless. no pain, no gain...
I wrote three of the "days" in "Teach Yourself Ruby in 21 Days", and I
went out of my way to make them excruciatingly painful, so you can
safely read it
But seriously... that book did get a lot of "not a typical book of its
genre" remarks, for which I take a mini-bow but mostly give a big nod
to Mark Slagell, the chief author.
David
On Sat, 21 Jan 2006, Tom Allison wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
To be fair, the PickAxe was never intended to be a "Learning Ruby" book, as much as a "Programming Ruby" book. For a ground-up book on learning to programm using Ruby, I'd recommend Chris Pine's.
Dave
On Jan 20, 2006, at 9:25 PM, Tom Allison wrote:
Learning Perl (actually from the CD).
Programming Perl is a fantastic book but only after you've exhausted the Learning perl book. It's a fine example of a reference book. As I read through the Pragmatic Ruby book I am seeing where it has that potential. I'm starting to come to terms with it.
Mark Volkmann 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.
On 1/19/06, James Britt <james_b@neurogami.com> wrote:
> On 1/19/06, Kenneth Collins <pine29@myfastmail.com> wrote:
--
R. Mark Volkmann
Partner, Object Computing, Inc.
I agree. The 21 day ruby book is probably the most useful 21 day type book I have ever read. It does cover a bunch of very useful stuff.
Cheers-
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra@yakima-herald.com
blog: http://brainspl.at
On Jan 20, 2006, at 7:36 PM, dblack@wobblini.net wrote:
Hi --
On Sat, 21 Jan 2006, Tom Allison wrote:
Well, I don't have that exact background but I've always found books like the typical "21 days" and "dummies" are mostly useless. no pain, no gain...
I wrote three of the "days" in "Teach Yourself Ruby in 21 Days", and I
went out of my way to make them excruciatingly painful, so you can
safely read itBut seriously... that book did get a lot of "not a typical book of its
genre" remarks, for which I take a mini-bow but mostly give a big nod
to Mark Slagell, the chief author.David
--
David A. Black
dblack@wobblini.net"Ruby for Rails", from Manning Publications, coming April 2006!
Ruby for Rails
dblack@wobblini.net wrote:
I wrote three of the "days" in "Teach Yourself Ruby in 21 Days", and I
went out of my way to make them excruciatingly painful, so you can
safely read it
Well, I certainly do need to keep that in mind.
Glad it's painful.
Many are not....
Dave Thomas wrote:
To be fair, the PickAxe was never intended to be a "Learning Ruby"
book, as much as a "Programming Ruby" book. For a ground-up book on
learning to programm using Ruby, I'd recommend Chris Pine's.
"Programming Ruby" is a great, great book, but it is basically the
equivalent of O'Reilly's "Programming Perl" - more of a reference than a
learning tool. What the community really needs now is a Ruby equivalent
of "Learning Perl", which is one of the best guides to learning a
programming language I've ever seen. A book to get you started before
you move up to the Pickaxe, just like the Llama prepares you for the
Camel. (The Rock Hammer?)
How is "Learn to Program" for learning Ruby? I got the impression that
it was aimed at people who had never done any programming before, as
opposed to "Learning Perl", which is intended for otherwise experienced
programmers who have simply never encountered Perl.
Chris
--
Posted via http://www.ruby-forum.com/\.