Damian is fallible like every else. O'Reilly has released several very bad books. Randal has made mistakes in articles. Search results don't tell much, especially for more complex queries. Perlmonks reviews are hardly ever in-depth, and tend to be regurgitating the API docs.

Trust nothing. Analyze the code for yourself.

The question is: they certainly make mistakes, too, but are you less fallible than TheDamian, Abigail or merlyn?

Makeshifts last the longest.

Actually, maybe he is. I think we should be very careful to put people on pedestals like this. Damian, merlyn, myself, and others you didn't mention might sometimes have ideas noone sane would ever have, inside the sugary layer with chemical flavours are regular coders. If would take some code of Damian, and post it here for review, without telling it was from Damian, it would be shredded to pieces, if only because it doesn't use strict or warnings. Merlyn probably has posted more articles containing buggy code on Usenet than the average monk has read articles. As for myself, well, my code is of course perfect, it's just taking the rest of you a long time to agree.

Never assume that because it's written by person $X, it has to be good. Unless $X eq "Knuth" and $X is willing to pay money for each mistake found.

Well, I'm incredibly egotistical so I won't answer that. I will however say that using someone else's code, even if they are a far better programmer than you, creates several additional areas of concern. You have to ensure:

• The code is not intentionally flawed.
• The code is not trojanned in transit or due to server compromise
• The original programmers are at least as competent as you at the task at hand
• There are no licensing issues (including maintenance issues)

I left out unintentional bugs although I've often found (keyword: found) far fewer in my code :). A much larger problem (especially in Perl) is style. I can read my code far, far easier than most other people's. I'm not talking about indentation, and unimportant/easily fixable issues here, but larger (mildly subjective) design issues. Often I've found it quicker to write a module than to read it, understand it, and do a quality assessment.

However, your point is obviously a valid area of concern. To an extent it is the same issue that I'm using perl instead of writing my own language (rest assured, it is in my todo.list). You could even take it down to the level that I should be creating all hardware and software from scratch (unfortunately I'm not that good... yet). There must be a level of trust, or more accurately an acceptable risk threshold, when dealing with any technology. I'm just a little more paranoid than most.

There are other advantages to this approach as well. If I had always just used existing tools and taken the easy way I don't think I would know half the things I do now. I also occasionally come up with something that improves upon the existing. And as crazy as it might sound, I also enjoy writing what is often considered tedious code (XML parsers, template systems, drivers). It's sort of a "well I haven't written project x yet, might as well go ahead." Or more articulately, as Richard Feynman once said "What I cannot create, I do not understand."

So yeah, I'm just babbling on now, I intended this to be a two sentence response, really :). So point taken, but there are a bunch of other things to consider, and even if they don't outweigh your point, it clears out a couple bytes of my memory needed for reinventing stuff :).

The music that you are willing to give a listen might not follow a strict set of rules. Code is analogous to music. My idea is that you might have a favorite artist or a favorite art critic, and this is analogous to having a favorite module author or module reviewer.

You might invest a few dollars to buy the newest release from your favorite musician without first listening to it. This is analogous to spending a few hours evaluating a module from your favorite CPAN author without knowing why you need the module or if it is any good.

It should work perfectly the first time! - toma