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

[SB]

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.=20
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?

#: (e-mail address removed) changed the world a bit at a time by saying (ast=

ral date: 1/19/2006 9:10 PM) :#

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

With all due respect, I would say these tricks are used _after_ you maste= r the API.
The discussion (as far as i got it) was about leaning it (so _before_ mas= tering the API). And having
6 methods with different names is kind of confusing while learning. You a= re 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 tha= t happen lately about human
interfaces vs good APIs vs ... (iirc the start was somewhere on Martin Fo= wler's blog)

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

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

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

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:

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 =3D Thread::new {
begin
require 'lib'
true
rescue SystemExit
nil
end
}.value

puts "Thread#exit called in lieu of Kernel#exit - whew" unless succe= ssfully_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 look= s 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] =3D 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 unde= r a key
was more appropriate to my design in the first place so using this inte= rface
saved me grief later.

synonyms exist elsewhere for clarity in ruby too

unless =3D=3D if not

thankfully.

regards.

-a

 

[Tom Allison]

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.

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

 

[Seth Thomas Rasmussen]

Hi John,

As somebody said, you start using whichever synonyms and the like that
you prefer, and it's just obvious that you'll have to check docs as you
go later on. Eventually you'll get used to the synonyms, whether method
names or alternate ways of expressing conditions, etc. I would think
it's not all that unlike learning synonyms in whatever spoken language
you use. Carrying on with that idea, would you prefer that everybody
were relegated to one term for every idea they could express vocally? I
shudder to think of those that would affirm that notion. Think of how
boring the internet would be.

I hope you are able to expand your concept of coding to include Ruby.
Since I picked up the Pickaxe last summer, I've been absolutely in love
with the language. One of the most significant features for me is the
freedom, simplicity and clarity of expression.

But that clarity comes only after you've taken the time to digest the
higher level abstractions and conventions that Ruby employs. I didn't
write a single line of Ruby code until I finished the Pickaxe because I
wanted to be sure I understood the general big picture well enough to
wade through the sludge with confidence.

I sound like a total fanboy these days, and I understand that there are
many other wonderful tools as well... but I've given Ruby time and a
fair appraisal, and I absolutely love it. I hope you'll give it the
same.

 

[Amr Malik]

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/theFullyUpturnedBin.html).

Either that or I'll have to learn Japanese.

-Amr

 

[Justin Collins]

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

 

[Tom Allison]

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

 

[dblack]

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

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black

 

[anne001]

I can't stand the pickaxe book because it is so verbose,
instead of puts "hello" they use examples like
puts "The title of this song is lets get to the moon and back..."
the lines don't parse,the concept gets lost in all the words.

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

In comparison, 21 days to ruby reads very well. The examples are
varied.
I wish there was an update coming up this year.

What I find missing, is OOP information, how you organize your code.
For example I found out that if an object calls another and back to the
first etc recursevly, you can reach too many layers. When you call
objects, there must be a point where the object does not call anyone,
so the control level can go back up. In other wards, objects calling
each other must not form loops, they must be like tentacles. I was told
on this list that objects should be organised in a vertical way,
objects talking to object they create or that created them... Inter
object communication is possible but difficult - there was some
discussion of that on the list. This kind of issue is not discussed
that I have seen in the ruby books.

I am hoping the book "OOP demystified" can help me with Object
programing design

 

[Ezra Zygmuntowicz]

Hi --



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
(e-mail address removed)

"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
(e-mail address removed)
blog: http://brainspl.at

 

[Tom Allison]

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]

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.

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

 

[Dave Thomas]

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

 

[Alex Combas]

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 :}

 

[Rubyist]

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.

 

[Chris Gernon]

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

 

[Donkey Agony]

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.

It *is* advertised that way, but -- from someone who has been
programming since the early 80s -- I'd say that not only is it much more
than that, but it's an *excellent* book for learning Ruby.