This was one of the better posts I've read here. I've read a lot of great posts here too, so that's saying something.

I got to thinking about some of the people who wander in here with real problems to solve. We usually advise them . . .

I usually dole out such generic advice because I'm sure that it's not wrong in most cases rather than because I think it is best for a specific case. It usually works out because if someone is asking a question which can be met with a canned answer then they are likely to be inexperienced enough that the canned answer will serve them best anyway.

I don't always follow my own advice. I often write scripts in which I implement the one hundredth of Random::Module's functionality that I need because I don't need the other ninety-nine percent of it. I make those decisions with my eye's open though. I keep my requirements in mind and I research alternatives if I'm not already familiar with them.

Available modules are often not the best solution. Using them doesn't always result in more robustness, more maintainability, or less work.

Using modules requires that you rely on the work of people outside your organization and code which isn't developed with your guidelines, procedures, or standards in mind. Module authors usually aren't paid for their work and maintenance can be sporadic.

Depending on your environment, installing modules may be difficult. Keeping versions synchronized may be realistically impossible. Upgrading modules can break current functionality. Unlike binary shared libraries, getting multiple versions of a Perl module to coexist isn't always easy to do. Modules often contain XS code or rely on external libraries for which cross-platform support isn't as good as it is for Perl itself.

Just as the module may add some overhead to the project, the module's interface may well add overhead to your actual code. Abstractions chosen by module authors in an attempt to make some difficult tasks relatively simple may also make some simple tasks relatively difficult and the added complexity can be more hassle than it is worth. This is evident in the number of *::Easy and *::Simple modules on CPAN.

A regular expression to extract an easily identifiable link from some HTML might well make more sense than parsing the whole document and it might be a lot more robust too. It's perfectly acceptable to just print "Content-type: text/html\n\n"; and get on with life if your CGI script doesn't take parameters. Why not open a socket and print "HEAD / HTTP/1.0\n\n"; if that's really all you need to do?

Knowing what you really need to is, afterall, the key. If you need to make multiple head requests for documents residing on different servers then you should probably be using LWP. If your CGI application is even mildy complex then you are better off using CGI.pm. If your application needs to extract links from random HTML, then parse it.

Canned solutions work well in the average case. I think the same can be said for the canned advice we give.

-sauoq
"My two cents aren't worth a dime.";