Hal E. Fulton
7/26/2006 11:48:00 PM
Chad Perrin wrote:
>
> I've seen references to this book a number of times, and heard good
> things about it. What, exactly, is its approach and "theme"?
Well, the first chapter is different: It's an overview of OOP in general
and Ruby in particular.
The rest of the chapters, for the most part, attempt to answer "how-to"
questions. These range from the trivial ("How do I find the legnth of
a string?") to the monumental ("How do I write a web app?").
It also serves as a kind of "inverted reference" by being
topic-oriented. Things are arranged by topic, not alphabetically.
Thus you'll see the String methods upcase, downcase, casecmp, and
capitalize all discussed together (with maybe a little regex stuff
thrown in).
Some of the design principles were:
- nothing is too small to be included (people's
opinions differ about what is "obvious" or
"trivial")
- cover almost all the core and standard libs
- things that are "missing" from the core and
standard libs are often coded
- it strives for good Ruby style, sometimes
with flaws
- examples are given whenever possible/practical
- it has a CS flavor rather than a corporate one
- it emphasizes principles rather than drop-in
usable code (though that is often there too)
- it gives pointers to outside info when possible
- it gives little tidbits outside its main topic,
for flavor
The first edition had nine chapters and 350+ code
fragments. Many of the chapters in the 2nd ed are
split up and rearranged, and the appendices are
gone. The 2nd ed will have 22 chapters -- how
many code fragments, I'm not sure. The new one is
significantly larger, more up to date, and generally
more accurate.
It's supposed to be available in early November.
Does that help?
> Ditto! In addition, thanks for asking a question that should probably
> be asked more often. I've seen two or three nontrivial efforts at a
> Ruby instructional text of some sort that start out with statements like
> "I was planning to write a book about object-oriented Ruby that started
> with objects and just explained everything form the perspective of using
> OOP in a way that would be comprehensible and quickly learned by
> programming newbies, but it was too hard, so I started with variables in
> the normal imperative/procedural style instead." That drives me up the
> wall. I'm no Ruby expert, but I have some familiarity, and what I know
> so far has quickly indicated to me that probably the best way to get
> someone up to speed quickly on OOP with Ruby from a standing start would
> be to teach OOP in a largely transparent manner, so that you're doing
> OOP without realizing it for a while. OOP has become such a ubiquitous
> and important part of the programming landscape that it makes sense to
> teach OOP first, when the alternative is strictly procedural code, for
> most purposes. Why hasn't this been done (as far as I'm aware) with
> Ruby as the example language?
>
> Yes, I'd do it myself, if I knew more Ruby than I do thus far. Some
> day, I suppose, I will -- if it hasn't been done by the time I'm ready.
I've thought about this, but I think it can only be taken so far.
In explaining OOP, you sort of have to understand what P is before you
grasp what OO is. Maybe we should use the French abbreviation, POO. :)
Hal