Top Seven (Bad) Reasons Not To Use Modules

It seems fairly frequent that a supplicant will stop by wanting to accomplish task X in Perl, only to be told that a module exists which will accomplish that exact task. Sometimes this advice is accepted happily, but other times the asker will resist the suggestion to install a module.

So along with some of these oft-given reasons for wishing to avoid module use, I offer contrary arguments which I think you should seriously consider if you are still avoiding modules. I'm positive somebody has addressed all of this before, but since I couldn't find a node myself, I thought I'd collect my thoughts in this meditation.

Here are the reasons often given for wanting to avoid module use:

I don't need a module for this simple task

It may seem that way now, but what if you haven't considered all of the possible cases your code will have to handle? What about if (when) your requirements change? Module authors have usually had time to consider the edge cases. Better yet, modules typically come packaged with a set of tests to ensure that they can handle those cases well. Even if you were planning on testing your code yourself (you were, weren't you?), the module has saved you the effort of writing those tests.

Your task may be simple, but using a module keeps the conceptual complexity of your code to a minimum. In effect, using a module typically is the simplest solution to a simple problem.
The module includes features I will never use

So what? As noted above, how can you be sure you will never use those features? And even if you are really sure (ha!) that you will never use those extra features, they aren't doing any harm just sitting around disused. Unless... Well, that brings us to our next point.
Using modules will bloat my script, making it slower

I understand your concern, but really, this is a form of premature optimization. Instead of quoting Knuth here, I'll direct you to Andy Lester's Rules of Optimization Club. Until you have run the app and seen that it's too slow, and until you've profiled the app and you know that it's the module that's causing the problem, avoiding it just because it might slow down your program is not a good enough reason.

Besides, you have no guarantee that code you write yourself will be any faster. Many modules are implemented using XS bindings to compiled C. Those are typically going to be faster than any implementation you can come up with in pure Perl.
I want my script to have few dependencies

Okay, but why? If it's for optimization reasons, see above. If it's for portability reasons, see below. Otherwise I can only think that you're avoiding dependencies because you feel that you can do this better than any existing module and you want to be responsible for maintaining and supporting the code which does this particular task. If you're writing code that is in your core competency, that's actually a completely valid reason to roll your own and avoid a module. For a reference, see Joel on Software's In Defense of Not-Invented-Here Syndrome.

However, that said, if you have to ask the Monks about how to go about your solution, chances are that it's not your core competency, and you should seriously consider whether you are avoiding dependencies for good reasons.
I want my script to be easily portable

Perl code is wonderfully portable, even with module dependencies! Most modules depend on other modules, and they install just fine. I think this objection is just another way of saying "I don't know how to package my app so that it can be installed along with its dependencies." To address that, there are excellent resources available on this very site describing Creating and Distributing Modules, which include the concern of having your code declare its dependencies so they can be installed in a portable way.
I am not allowed to install modules sitewide

Fine, so install them locally! Perl doesn't care whether you have installed modules locally or sitewide, they'll work just the same. In fact, you can even set up your own version of Perl to make sure that all your module versions are controlled by you, locally, and not your OS or your site's administrator.
There's a module that almost does what I want, but it's buggy/broken

This is probably the most legitimate reason of all, because it shows that you've gone through the effort of trying to use a module, but through no fault of your own, you hit a dead-end. Sadly, this does happen.

One way to proceed is to report the problem to the module maintainer. If they are responsive, the problem can be resolved and you can proceed on your merry way, module in hand.

Sometimes, though, modules aren't being actively maintained. However, that doesn't mean you have to start from scratch. You probably want to write a patch for the module which you can apply that will make it work for your case, and then use your patched version. You can even ask for help on doing this from your fellow monks. In fact, once done you should submit your patch to the module maintainer, they will probably be very grateful for your efforts, if and when they return from wherever-they-are.

After all is said and done, this is of course only advice. But IMHO, it's good advice. As the author of your code, you're the only one who can make decisions about module use based on your specific needs and circumstances. Just keep in mind that when one of your fellow monks suggests that you use a module, it's not because they are lazy. It's because experience has shown that most of the time, that is the right thing to do.

If you really can't use a module for some particular reasons, make sure you've included that reasoning in your write-up before you post your question. That way, you won't spend valuable time debating these points with people who are only trying to help.

Comment on Top Seven (Bad) Reasons Not To Use Modules

Replies are listed 'Best First'.

Re: Top Seven (Bad) Reasons Not To Use Modules
by ELISHEVA (Prior) on Mar 13, 2009 at 04:42 UTC

++ 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