Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
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.

In reply to Top Seven (Bad) Reasons Not To Use Modules by bellaire

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others exploiting the Monastery: (2)
    As of 2018-03-24 08:24 GMT
    Find Nodes?
      Voting Booth?
      When I think of a mole I think of:

      Results (297 votes). Check out past polls.