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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
508861510639b56d61eb30e6a28b01d9?d=identicon&s=25 John Maclean (Guest)
on 2006-01-19 13:40
(Received via mailing list)
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 ;)
71f1b6b2c3fd9af2e8c52618fb91caa6?d=identicon&s=25 Jules Jacobs (jules)
on 2006-01-19 13:51
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
32ba8c5c148da2653028dc7f8066b810?d=identicon&s=25 Doug Bromley (Guest)
on 2006-01-19 14:04
(Received via mailing list)
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.
508861510639b56d61eb30e6a28b01d9?d=identicon&s=25 John Maclean (Guest)
on 2006-01-19 14:19
(Received via mailing list)
Thanks Doug. More concise and articulate that I ever could be.

On Thu, 19 Jan 2006 21:25:46 +0900
Ce1f4ad22c0f38122258eb8f4c1cd5a5?d=identicon&s=25 Kenneth Collins (kcollins)
on 2006-01-19 16:00
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
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-01-19 17:21
(Received via mailing list)
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.
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-19 17:42
(Received via mailing list)
Mark Volkmann 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.


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
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-01-19 18:18
(Received via mailing list)
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
B000982a23d5c6a34292902caf225dd7?d=identicon&s=25 Yohanes Santoso (Guest)
on 2006-01-19 18:39
(Received via mailing list)
ara.t.howard@noaa.gov 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?
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-01-19 20:19
(Received via mailing list)
On 1/19/06, James Britt <james_b@neurogami.com> 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.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-19 20:46
(Received via mailing list)
On Jan 19, 2006, at 12:40 PM, Mark Volkmann 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 Gray II
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-01-19 20:49
(Received via mailing list)
On Fri, 20 Jan 2006, Mark Volkmann 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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-19 21:16
(Received via mailing list)
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.

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
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-01-19 21:19
(Received via mailing list)
On 1/19/06, James Edward Gray II <james@grayproductions.net> wrote:
> On Jan 19, 2006, at 12:40 PM, Mark Volkmann 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.
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-01-19 21:28
(Received via mailing list)
On 1/19/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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).
32ba8c5c148da2653028dc7f8066b810?d=identicon&s=25 Doug Bromley (Guest)
on 2006-01-19 21:43
(Received via mailing list)
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!
110e4bfa2a40cebb8ffe67982f58197b?d=identicon&s=25 Thomas Snide (Guest)
on 2006-01-19 23:17
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?
7f891fbe8e3bae7f9fe375407ce90d9d?d=identicon&s=25 Harold Hausman (Guest)
on 2006-01-20 01:18
(Received via mailing list)
On 1/19/06, Thomas Snide <Tom@tcssoftware.com> 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
5c4e57ad9f066e56297a60b4a1daa1d3?d=identicon&s=25 Alexandru Popescu (Guest)
on 2006-01-20 10:29
(Received via mailing list)
#: ara.t.howard@noaa.gov 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)
622fa8560c82dfaa59c91ec75efb0c19?d=identicon&s=25 Alex Combas (Guest)
on 2006-01-20 11:02
(Received via mailing list)
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 :)
A70c7d3ce6c24d7b2c6924988178f788?d=identicon&s=25 SB (Guest)
on 2006-01-20 12:02
(Received via mailing list)
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?
201ab62b10b1ce61759a091d3b307fa1?d=identicon&s=25 Tom Allison (Guest)
on 2006-01-20 13:06
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
>> when I can understand a concept, test it and see that it works. How do
>
> -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.

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".
D23f436b8e718e80f447712cdac67083?d=identicon&s=25 Amr Malik (Guest)
on 2006-01-20 18:24
Alex Combas wrote:
> 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 :)

As a newcomer I would tend to agree with this. What I did with my
PickAxeII was to actually split it along the spine into 3 more
manageable books and rebind (DIY style) each of the 3 smaller parts are
as follows:

1: Part I (Facets of Ruby)
2: Part II, III (Ruby in its setting, with objects explained at the end)
3: Part IV upto the end (Bulky reference)

I tend to get some reading done at night and I found it was getting a
bit too bulky for reading just the introdcutory parts. I don't really
see why I should carry around the bulk of the reference when I won't
even be using it for a while. I think it would be better to split the
book in 3 physical sections, and market them as one book (another
innovative thing to consider for Pragmatic Programmers.)

Also, I think that the book jumps around with its examples and tended to
frustrate me in the beginning when I was trying to use it as a tutorial.
What I ended up doing was take the 3 parts and read them buffet style.
Each chapter explains concepts well, if you don't mind not having a
cohesive strategy of code examples supporting the theoretical material.

So, how am I going about learning Ruby?

My approach is to read PickAxeII in conjunction with excellent tutorials
out there (Why's and Chris Pines come to mind). Read tutorial, See what
PickAxe has to say about it, read some more tutorial read the object
explanations etc. etc.

Right now, I would say to the newcomers to use Chris Pine's book in
conjunction with Why's tutorial and the Parts I, II and III of the
PickAxeII. To understand Objects in Ruby read the "A little Ruby, A lot
of objects" tutorial. Even though I tend to get lost towards the end of
the tutorial with the meta-classes/meta-meta-objects etc.

So, fellow newbies, this is how I'm going about it:
1. Chris Pines PDF book from PragProgg'rs (the pdf book is well worth
it)
2. Why's Poignant guide (take frequent breathers and come back to it.
You'll find that Why is literally sneaking ruby concepts through your
subconscious)
3. PickAxe2 : Part I, II, II (occasionally Part IV, but ri is always
easier and much lighter)
4. Brian Marick's "A little ruby A lot of objects"

Unfortunately PickAxeII is NOT the greatest Ruby tutorial out there,
even though Part I & II are excellent introductory texts, but the
pedagogical style suffers from inconsistency and code doesn't exactly
build on theory. I still constider it an excellent reference book and
frequently re-read parts to understand what's going on.

I personally would like to see some of the Japanese texts translated
which explain the internals of Ruby. One would be the Ruby Hacking Guide
which Why talks about in his article on Ruby GC.
(http://whytheluckystiff.net/articles/theFullyUptur...).

Either that or I'll have to learn Japanese. :)

-Amr
F3b7109c91841c7106784d229418f5dd?d=identicon&s=25 Justin Collins (Guest)
on 2006-01-21 01:11
(Received via mailing list)
Tom Allison wrote:
>>> even faster
>> at first - so much faster once you've got it. ;-)
>
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
201ab62b10b1ce61759a091d3b307fa1?d=identicon&s=25 Tom Allison (Guest)
on 2006-01-21 05:04
(Received via mailing list)
Justin Collins wrote:
>>>> Ruby seems like a great language and the book's good too. However a
>>>> posting ;)
>> Probably true.
> (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...
:)
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-21 05:13
(Received via mailing list)
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 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

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-01-21 19:51
(Received via mailing list)
On Jan 20, 2006, at 7:36 PM, dblack@wobblini.net wrote:

> safely read it :-)
> dblack@wobblini.net
>
> "Ruby for Rails", from Manning Publications, coming April 2006!
> http://www.manning.com/books/black
>


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
http://yakimaherald.com
ezra@yakima-herald.com
blog: http://brainspl.at
201ab62b10b1ce61759a091d3b307fa1?d=identicon&s=25 Tom Allison (Guest)
on 2006-01-23 00:44
(Received via mailing list)
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....
5d06917e13b29bcff1c1609492c06873?d=identicon&s=25 Dave Thomas (Guest)
on 2006-01-23 17:41
(Received via mailing list)
On Jan 20, 2006, at 3:23 AM, Alex Combas wrote:

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

It was a hard decision: showing full listings all the time would
significantly add to the size of an already big book. That's why we
did it the way we did, but also made sure we have full and complete
listings, ties to the page numbers, available online at http://
pragmaticprogrammer.com/titles/ruby/code

Cheers


Dave
5d06917e13b29bcff1c1609492c06873?d=identicon&s=25 Dave Thomas (Guest)
on 2006-01-23 17:44
(Received via mailing list)
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.


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
622fa8560c82dfaa59c91ec75efb0c19?d=identicon&s=25 Alex Combas (Guest)
on 2006-01-24 07:09
(Received via mailing list)
On 1/23/06, Dave Thomas <dave@pragprog.com> wrote:
> It was a hard decision: showing full listings all the time would
> significantly add to the size of an already big book. That's why we
> did it the way we did, but also made sure we have full and complete
> listings, ties to the page numbers, available online at http://
> pragmaticprogrammer.com/titles/ruby/code
>

Thanks Dave!
Is that mentioned anywhere in the book itself? That makes
a big difference. You've upgraded my opinion from Good to Great :}
De271a04fe7a67b884ce75404c1dcc61?d=identicon&s=25 Chris Gernon (Guest)
on 2006-01-24 18:09
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
This topic is locked and can not be replied to.