in reply to Re: (OT) I prefer to do my learning with: dead trees or flying electrons? in thread (OT) I prefer to do my learning with: dead trees or flying electrons?
I mirror your concerns about the index--fortuantly, the index in the Camel is very good.
One of the reasons O'Reilly books can't charme is are the poor
indices, with no exception of the Camel. Granted, the index
of Camel III is better than the Camel II, but it's still poor.
(Early prints didn't even have an entry for 'regular expression', IIRC). You mention Knuth. Take the index of
The Art of Computer Programming, and compare that
with the index of the Camel.
What I also don't understand is that you wouldn't buy certain classes of books, because they are easily outdated,
yet you break a lance for the Camel. The Camel was released
shortly after 5.6.0, and large chunks were written before
5.6.0 was finalized. We know have 5.8.0 with 5.8.1 around
the corner. I'd say the Camel III is suffers from being
outdated as well.
Abigail
Re: Re: (OT) I prefer to do my learning with: dead trees or flying electrons?
by hardburn (Abbot) on Sep 23, 2003 at 15:19 UTC
|
One of the reasons O'Reilly books can't charme is are the poor indices . . .
Perhap. I'm comparing the Camel's index with the multitude of "Learning Perl for Fools" books out there, where they basically slap an index with a few common terms and leave the rest to the poor sod that bought the book.
What I also don't understand is that you wouldn't buy certain classes of books, because they are easily outdated, yet you break a lance for the Camel.
How much fundamental of the Camel was really obsoleted by 5.6.* or 5.8.*? Declaring variables is still the same. Looping and conditionals are the same. Declaring subroutines is the same, with at best a few attributes being added, if anything. Builtins are pretty much the same, with a few details being different. Complex datastructures, packages/modules, and OO programming are the same (notwithstanding meryln's complaints about ref $class || $class;, or the various other object systems you can use under Perl). Trying to output native, optimized code from your Perl code is still a tricky proposition. Tied filehandles became useable in 5.6.0 (IIRC), but that's a fairly small portion of the book, and it covers them anyway. Threading became somewhat useable in 5.8.0, but again, it's a small part of the book.
So small, specific sections might be a bit out of date, but I don't forsee it being unuseable at least until Perl6. That's a long ways off and a lot of Perl5 stuff will still be applicable by then. Probably Perl4, too.
---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
Note: All code is untested, unless otherwise stated
| [reply] [d/l] |
|
How much fundamental of the Camel was really obsoleted by 5.6.* or 5.8.*?
Well, first of all, the Camel isn't a book about fundamentals,
it's a reference guide. I'd say, the camel is as obsoleted
in three years, as a book about important CPAN modules does
in three years. How many fundamental modules arrived on CPAN
the last three years?
Declaring variables is still the same. Looping and conditionals are the same. Declaring subroutines is the same, with at best a few attributes being added, if anything. Builtins are pretty much the same, with a few details being different. Complex datastructures, packages/modules, and OO programming are the same
None of that has changed much since 5.000, and many
fundamental things haven't changed since perl4, or even
earlier Perls. If you look at fundamentals, even the pink
Camel still isn't obsolete. Some important things that have
changed from 5.6.* to 5.8.*, and are either missing from
the Camel, or insufficiently documented: Unicode support,
threading support, Perl I/O layers, signals, and a whole
bunch of new modules.
Look, it's fine if you don't want to call the Camel outdated. But then, be consistent, and don't call other
(hypothetic) books outdated either.
Abigail
| [reply] |
|
I'd say, the camel is as obsoleted in three years, as a book about important CPAN modules does in three years. How many fundamental modules arrived on CPAN the last three years?
Not to troll but what kind of logical argument is that? It's tantamount to saying the camel is obsolete because the price of crude oil has gone up. Backing it up by saying "11 million barrels of oil are imported into the U.S. per day!" doesn't really help the argument either.
You also seem fairly competent at Perl programming, if the camel is so out of date (and has such poor indicies, if that's really an important point) why not write one yourself?
| [reply] |
Re: Re: (OT) I prefer to do my learning with: dead trees or flying electrons?
by menolly (Hermit) on Sep 23, 2003 at 16:46 UTC
|
My Camel II certainly has an index entry for regular expressions. I can check the pink Camel when I get home tonight, but I've always been happy with ORA indices. I've occasionally wished for an index in the pocket refs, though. | [reply] |
|
My Camel II certainly has an index entry for regular expressions.
I'm sure it has. My claim was about early prints of the third
edition. Currently, I have 2 prints of the third edition.
From the index of the July 2000 print, page 1053, first column:
reftype function, 317
regex (see patterns)
regexes (see patterns)
regexps (see patterns)
registry (Microsoft Windows), manipulating,
398, 875
regular files, testing for, 28
re-initialization expressions, loops, 116
From the index of the March 2001 print, page 1054, first column:
reftype function (attributes pragma), 317
regexes (see patterns)
regexps (see patterns)
registry (Microsoft Windows)
manipulating, 398, 551, 875
.pl extensions and, 490
regular expressions (see patterns)
regular files, testing for, 28
Abigail | [reply] [d/l] [select] |
|
My bad; I was reading on insufficient coffee and misparsed the antecedent. Thanks for the excerpt -- though it does appear that one could still find the information fairly easily, since there are entries for "regex", "regexes", and "regexps". No excuse for omitting "regular expressions", of course, but it's not as bad as omitting the concept entirely.
| [reply] |
|
|