Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: Top Seven (Bad) Reasons Not To Use Modules

by JavaFan (Canon)
on Mar 13, 2009 at 10:45 UTC ( #750365=note: print w/replies, xml ) Need Help??

in reply to Top Seven (Bad) Reasons Not To Use Modules

Yet another "this is the way to do it, and anything else sucks" post. Let me pick at some of your arguments:
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 if I have? What if *I* have, but the author of the module didn't? How would I know the author did? I might audit the modules code, but if the task is simple (but important), writing it yourself may be more efficient.
What about if (when) your requirements change?
Well, so what? In point 4, you warn against premature optimization. Coding against any possible requirement change in the future is premature optimization. The scrum methodology actually forbids you to do so: it's just enough, just in time. Now, I'm not a full scrum adept, but one of the signs of a good programmer is that he can make the right trade-offs. Which does include knowing when to spend resources now against possible future requirement changes, and when not. Note that any resource spend coding for a possible requirement change that will not happen is a 100% loss. Certain things just are too unlikely to change before your code is discarded.
Module authors have usually had time to consider the edge cases.
Really? How do you know? Or more important, how do I know? If there's a module on CPAN doing X, what tells me the author has spend more time considering edge cases I will do? Remember, the existence of code on CPAN neither implies a stamp of quality on the code, nor on the author. I've a pretty good idea of the quality of my code, and of the quality of the code my co-workers write. I've some ideas about the quality of the code of a small subset of the CPAN authors. Of the majority of them, I've no idea how good they are, and whether the module I may use reflects that.
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.
There's something magical that happens with authors when writing code for CPAN that doesn't happen when people write code that may use a CPAN module? CPAN authors will use XS everytime it gives a significant speedup, and others never will? Come on. People write XS code. Some of it will stay in house. Some of it appear on CPAN. Some people never write XS code, even if it would make their code faster. And guess what? Some of that code ends up on CPAN as well.
Fine, so install them locally!
Oh goodie. So, you'll end up with code that passes 100% of the tests, but doesn't even compile when rolled out into production. Great advice! Not. I've worked in several companies where there's a procedure for installing third party software. Third party software is for instance only installed from RPMs. Which means that if I want module X to be installed, I have 1) find or create an RPM containing that module. 2) Do the same for every dependency. Recurse. 3) Create a ticket for operations to install the RPMs on development and production. 4) Wait for it to be installed. Now, at $WORK operations is pretty quick and there's seldomly an objection against installing CPAN modules. But if I work on a problem in the evening, and I've the choice between writing something simple myself and putting it live right the same night, or hunt down an RPM, create a ticket and wait till the next day, it's easier for me to write it myself (less work), and better for the company (bug fixed/feature implemented faster).

And here's another reason. Some time ago, I needed some piece of functionality. There's a CPAN module whose most recent versions having this functionality. We have this module installed at $WORK. Except, not the most recent version. With the most recent versions, our code will break. Considering that it's not an easy task to have two versions of the same module installed, and have some code use one version, and other code use the other (it's not impossible, but it doesn't work that way out of the box), I opted for writing the feature myself.

Perl code is wonderfully portable, even with module dependencies!
Often it is, but not always. Module authors usually don't have a wide range of platforms or OSses to test against. (Nor do I think there's any obligation for a CPAN author to test it against a wide range of platforms). Sometimes, code just doesn't work correctly in a different environment.
  • Comment on Re: Top Seven (Bad) Reasons Not To Use Modules

Replies are listed 'Best First'.
Re^2: Top Seven (Bad) Reasons Not To Use Modules
by bellaire (Hermit) on Mar 13, 2009 at 11:18 UTC
    JavaFan, all of your points are excellent, and valid counter-counter-arguments. You're obviously somebody who can judge for themselves, but not everyone who's avoiding modules has considered the ramifications of that decision in the depth that you have. In some cases, as in the case of corporate policy making you legally liable for installing modules, you literally have no choice. My post was addressed to those people who do have a choice.

    The intent of my post was not to say "do it this way, everything else sucks," it was to say that these arguments should be considered if you're avoiding modules. If you consider them, and deem them ridiculous or otherwise inapplicable, good for you. I am not asking you to treat my judgement superior to yours, I am merely offering something to think about (isn't that what meditations are?). I conclude by saying as much.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://750365]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2018-06-21 09:34 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (117 votes). Check out past polls.