|Don't ask to ask, just ask|
Re: Recommended PDL Referencesby BrowserUk (Pope)
|on Nov 22, 2006 at 00:22 UTC||Need Help??|
It's a real shame (for me as an non-Spanish reader), that the only tutorial is not in English.
It's also a shame that the download mechanism for either of the "books" (Adobe RIH for foisting pdf on the world!), doesn't allow the size of the download to be identified before completion. Also that attempting to (view) results in "An Exception Has Occurred". Given these are both 5 years old, being able to preview them before downloading would be nice. Being able to discover how big they are before committing to downloading them would be the next best thing.
The Index of PDL Documentation is not an index. It's a 'Table of Contents'. It's not alphabetised. It list only the equivalent of Chapter heading, not keywords or functions or anything vaguely resembling an index.
It's also an extremely badly organised TOC. For example: What is the relationship/difference between
Which should the beginner read or ignore. The same questions apply to
A few (more) worked examples that are
The thing I notice about PDL when it comes up here at PM, in common with a quite a few other similarly complex frameworks, is that the responses that mention it, rarely ever go beyond the mention. There really are very few posts that provide worked examples. And those that do tend to be meditations that solve "classic" problems, rather than apply it's algorithms to the OP's real world problems.
The transition between knowing something exists and is smart and clever and fast; and being able to apply that something to somewhat intransigent, incompletely specified and badly summarised real world problems requires a high level of understanding of the package.
Data::Dumper is widely used, despite it's documented and well-known limitations, because it has a clearly defined & simple interface. Admittedly, being in core and and solving a rather simpler problem also helps. List::Util is widely used because, despite that it could export a single interface (reduce()) and still do most of what it does, it panders to the user and provides obvious aliases for several oft-used, common functions.
"rpic" and "rpiccan" would be far from obvious, even if there was a proper index. Likewise, "barf()", is hardly likely to be in the first three places I'm gonna look for that functionality--which would probably be die(), error() or croak().
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.