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:

1. 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.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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.
   
   
6. 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.
   
   
7. 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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.