finish reading why's (poignant) guide to ruby

Once I’m done with my java course this semester, I’m going to read what there is of Why’s guide to ruby again. Once I’ve done that, I’ll be giving up on a happy ending and marking this as done.

I’ve tried, really I have, but it’s just too damn entertaining for a programming book! Plus I keep skipping ahead to see what the foxes are getting up to…

I’ll try again and see if I can manage the whole thing this time.

As much fun as _why’s book is, it is not a priority right now.

I seem to enjoy my programming language tutorials and fiction much better separate from each other. However, I do not mind the example code having a theme.

You have to read a lot of pages until you finally get some information.

OK i admit it the cartoons were the best bit, but i wish all tech guides were written with this much thought

The “story” (or should I say non sequitur rambling) composes 80% of the content—too much noise to information ratio. The technical stuff was good, covering a lot of advanced topics… just wished he could go more into the nuts and bolts instead of wasting his and my time with “entertainment”.

I may not remember all of why the lucky stiff’s bizarre and brilliant cartoons, but I remember nearly all of his Ruby metaphors. This book was a great introduction to what I now think of as the most advanced and beautiful programming language around.

8 years old, lying in bed. Suddenly I realize. There’s nothing stopping me from becoming a child dentist.

One thing i found tricky about finishing why’s guide is part of what makes it so great. All the little stories.

But the thing I found is that if you’re short on time and want to get to the next real meat of the book, just skip ahead when it gets into story-telling mode. Look for the next block of code, then start 1 or 2 paragraphs before that. Why was really good about keeping the important stuff right near the code examples.

Kudos to you _why!

Some of _why’s explanations about certain aspects of the language are better than I’ve heard elsewhere. Such as the following description of instance variables from chapter 3:

“Most variables are rather temporary in nature. Some parts of your program are like little houses. You walk in and they have their own variables. In one house, you may have a dad that represents Archie, a travelling salesman and skeleton collector. In another house, dad could represent Peter, a lion tamer with a great love for flannel. Each house has its own meaning for dad.”