in reply to Top Seven (Bad) Reasons Not To Use Modules
++ for a great post. I would also add re "I don't need a module for this simple task" - if you have to ask the monks it isn't that simple.
But along with BrowserUK, I think that you are underestimating the problems caused by too many dependencies.
- Corporate no-use policies often reflect concerns about open-source "contamination" (a la Stallman) or ownership of IP. I realize there are a lot of strong feelings about this (pro and con), but the fact remains that case law is thin and lawyers themselves are not sure about the implications of some of the licensing agreements. Some corporations choose to err on the side of legal safety even if it means their technology costs are higher.
- Some CPAN modules require a C compiler. For security reasons some servers do not have C compilers. To install XS modules on these machines also means designing a build process that can draw from multiple lib directories, and rearrange them into a single image for bundling via zip files, PAR, debs, RPMs, or other packaging mechanism so that all dependent binaries can be shipped together . Designing multi-source build processes and packaging software (right) isn't really a topic for novices and some of the people most resistant to modules are, of course, novices.
- Some systems like Debian have some strong conventions for how the integrate Perl into the larger operating system. Setting up and getting CPAN working smoothly on those systems is non-trivial. Generating debs that play nicely is non-trivial and requires that you actually understand the Debian document on Perl policy. Relying on the well tested debs provided by the Debian project may put you several versions behind the latest updates and patches, especially if the patch has nothing to do with security.
- If Perl is part of a deployment solution (e.g. for an application stack), you may need a bootstrap strategy. In the first steps of the deployment solution using anything outside of core would put you in a chicken and egg problem. Using Perl to configure CPAN - oops need CPAN to get a module to configure CPAN.
- Also on the topic of deployment solutions - if your solution is going to be downloaded and jump-starts a configuration process on lots of little laptops or servers, KISS is the name of the game here. The simpler the deployment and configuration code is, the less likelihood for problems. So it generally does not pay to download "trivial" modules as part of the configuration process. Trivial though, of course, is relative. If you struggle to write a loop then nothing is trivial. But in general, the modules most worth using are those that reflect a high level of domain expertise, involve substantial amounts of code and features behind that very small subset of functions that you actually need, or for which test development is especially complex or time consuming.
The more I think about this, the more I'm coming to the conclusion that module use is like the conversation we had in the CB last night (paraphrased) - why do only the best coders think they make dumb mistakes? Clinton - because that's how they became good coders. SGML based languages look a lot simpler to parse than they really are. It takes a fair amount of experience to judge the amount of work involved in a rewrite, especially when 1K of code is backing a single function that you need. Many of our novices don't have that experience and so can't see why it isn't so simple.
The challenge for us is how to communicate that experience in just a few lines in the CB or a short post.
Best, beth