Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Top Seven (Bad) Reasons Not To Use Modules

by bellaire (Hermit)
on Mar 12, 2009 at 15:46 UTC ( #750190=perlmeditation: 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.

Comment on Top Seven (Bad) Reasons Not To Use Modules
Re: Top Seven (Bad) Reasons Not To Use Modules
by moritz (Cardinal) on Mar 12, 2009 at 15:52 UTC
    Luckily the portability question can be answered rather easily for the more often used modules, by looking at Slaven Rezić's CPAN Tester Matrix, here an example view for DBI.

    If it's red on all but one platform, chances are that it's not very portable. If it's mostly green (as in the example above) you don't have to worry too much.

    Oh, and it's linked from the distribution page on search.cpan.org, for example from DBI.

Re: Top Seven (Bad) Reasons Not To Use Modules
by toolic (Chancellor) on Mar 12, 2009 at 16:00 UTC
Re: Top Seven (Bad) Reasons Not To Use Modules
by dreadpiratepeter (Priest) on Mar 12, 2009 at 16:44 UTC
    I am the choir that you are preaching to.

    I find that the use of modules is the most compelling reason to use Perl. Once you get into the habit of looking on cpan before you code, you will find your productivity growing in leaps and bounds (as well as your reputation as a miracle worker at your job).

    Let me share what happened to me this morning. I was writing code to deal with a really bad ticketing system that my company uses. The saving grace is that it is built on top of a database, so i can manipulate it's data.

    I wrote a query that inserted formated data into a field in the db, but when i looked at the results in the app, the newlines were gone, replaced by black boxes. I (correctly) assumed that the app was expecting to see dos eol semantics, rather than unix.
    I'm old and the part of my brain that remembers eol semantics punted them long ago to make room for something more important. But...

    A quick search on cpan for "DOS NL" revealed the Text::FixEOL module, "cpan Text::FixEOL" installed it, and 2 lines of perl code implemented it. In less than 5 minutes, my problem was solved.

    And because the modules is on cpan, i know it is tested on any platform i might ever use this code on, and i am far more sure that it is correct than I ever would be if I had implemented it myself.

    Yay Perl!


    -pete
    "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."
      I too have found CPAN to be indispensable. Not only does it help my productivity by solving one problem, but I often find myself writing code with future uses in mind. My code is also physically portable. I use a portable version of Strawberry on a thumb drive since our PC's are managed. All the better for me since I can take it anywhere I need it. Like dreadpiratepeter said, once you start using CPAN, you'll realize the benefits of not have to re-invent the wheel. My current favorite module is Text::CSV_XS. It's so handy I could cry...

        ++ To to original post. Nice summary.

        My current favorite module is Text::CSV_XS. It's so handy I could cry...

        licking9Volts, thanks for the compliment, I feel flattered :)


        Enjoy, Have FUN! H.Merijn
      A quick search on cpan for "DOS NL" revealed the Text::FixEOL module, "cpan Text::FixEOL" installed it, and 2 lines of perl code implemented it. In less than 5 minutes, my problem was solved.
      Wait, you spend a whole five minutes, installed a module when all you need is:
      $text =~ s/\R/\r\n/g;
      That doesn't really sound as a convincing anecdote.
        You seem to have missed my point: I don't remember what the semantics for newlines are.
        I would have had to do a lot of looking stuff up to come up with that line, and I wouldn't be sure that it covers all cases. In addition, if you look at the module in question, I now have a tool that can also do the reverse translation, do the same for mac eol semantics (which again I have no idea what they are), and will handle all the edge cases properly.

        As a side note, I the negative and dismissive nature of your post to be completely counter-productive to what I hope the Perl monks should be accomplishing. It's wonderful that you know that line of code, but to post so condescendingly because someone else might not, is just rude.
        If you wanted to point out that there is a simple solution to this you could have done so in a much more positive way.
        But, I guess my expectations are too high in a medium where you never have to talk to someone face-to-face as a person.


        -pete
        "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."

        Erm ... what do you expect the \R to mean? I don't know, maybe it means something in Perl 5.10, but in 5.8 it's equivalent to R. So what you wrote was equivalent to

        $text =~ s/R/\r\n/g;
        probably not what you wanted, right?

        Even though this is not a task that would be too complex, it's not such a no-brainer as you seem to imply. It's not really "convert the internal notion of newlines (\n) to the Windows notion (CR LF)". It's "convert whatever newlines to the Windows newlines". So it should handle not only "\n", but also "\r\n" (windows already) and "\r" (old Mac). You do not want to end up with "CR CR LF", do you?

        I use

        $s =~ s/(?:\x0D\x0A?|\x0A)/\x0D\x0A/sg;
        within Mail::Sender, but if I did not want to waste my time and wanted to be sure I end up with the right line ends without having to study all posibilities, Text::FixEOL looks like a very good candidate.

Re: Top Seven (Bad) Reasons Not To Use Modules
by petdance (Parson) on Mar 12, 2009 at 22:33 UTC
Re: Top Seven (Bad) Reasons Not To Use Modules
by eyepopslikeamosquito (Canon) on Mar 13, 2009 at 02:17 UTC

    4. I want my script to have few dependencies
    In addition to Joel's "core competency" argument, there's another reason for CPAN authors to not go overboard with external dependencies: the relentless mathematical certainty that the more dependencies you have, the greater the probability that your users will be unable to install your module cleanly. For example, if you have 100 dependencies and the probability of each one failing its "make test" is 1 in 100, the probability of your module installing cleanly is around (99/100)**100 = 0.37; with only five dependencies, that improves to (99/100)**5 = 0.95.

    So, if it's a large, complex domain, such as DBI or XML parsing, I'm delighted to add the external dependency. But if it's just a "convenience" module, such as File::Slurp or Readonly, I'll normally make do without it. To illustrate, notice that both File::Slurp (see "get the tests passing" release by Dave Rolsky after two years of inaction by the module author) and Readonly (under perl 5.10.0) failed their "make test" for over a year.

    Update: see also Dependency hell (wikipedia).

Re: Top Seven (Bad) Reasons Not To Use Modules
by BrowserUk (Pope) on Mar 13, 2009 at 02:46 UTC
    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.

    All very well for scripts that only you use, but if you're a corporate hack and your tools have to be rolled out to production machines...they ain't gonna work there.

    And corporate shops have rules for a reason. And what you're advocating would in many places be seen as grounds for not just dismissal, but prosecution.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Great point. I've never been fortunate (unfortunate?) enough to work in a corporate environment with policies that create such liability problems. If you have no choice, then you have no choice, and all my thoughts on the subject are completely irrelevent.

        Since I've seen this post referred to too often in what could be rude responses, I've countered with my own reasoning for why I prefer not to rely on Modules in my Perl scripting. Like the original post here, these are my opinions, but coming from a secure, corporate environment.

        Top 11 (GOOD) reasons not to use someone else's Modules

        And corporate shops have rules for a reason. And what you're advocating would in many places be seen as grounds for not just dismissal, but prosecution.

      Exactly. If you're developing stuff for your own amusement, then deployment to a dozen systems running mission critical stuff is never going to be a problem.

      In my case it is -- which means I have to look closely at whether I absolutely need a module, or whether I can get by with something a little less 'jazzy'. This week's query was about using WWW::Mechanize -- that module isn't installed on the system I'm developing for, but LWP::UserAgent (which Mech uses) is present, so that decision is made for me.

      If you look at it from the IT guy's perspective, installing a module is no easy task: the latest version of X might mean you have to upgrade Y, which has always worked fine, and of course that means you need to also update Z and W .. and pretty soon, subtle problems start to turn up. And I ran into a 'version' problem recently, where an older version of Mech worked fine, but the newer one, on a different platform, didn't.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

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

      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.

      Quite the contrary. The cpan shell works out-of-the-box on Debian systems, and doesn't conflict with the package manager at all.

      And not only does Debian come with lots of perl modules as .deb packages, it also allows fairly easy generation of .deb packages from CPAN and custom perl modules via dh-make-perl or cpan2dist (distributed with CPANPLUS and thus with newer perl version in core).

      And there's nothing easier in Debian than installing a .deb module (especially if you set up a mirror on your own and put them up there).

      So if you want to solve the deployment problem on Debian based Linux distributions, you can get a clean solution pretty fast.

      (I guess the same holds true for many other distributions, but I just talk about Debian because I'm familiar with it).

        Installing debs with apt-get is easy-peasy and very reliable on any Debian system. No doubt.

        But as for CPAN, ease depends in part on how one has set up Debian. A C compiler and make isn't a given on Debian, for instance, and many CPAN builds will fail without one. Nor are various networking and system tools a given: ssh clients, sudo, and many others need to be explicitly downloaded if you do a minimal install. Debian has a huge variety of download options - from a minimal 40MB install to a 650MB CD image.

        I haven't noticed problems with CPAN and apt-get/dpkg conflicting. However, that doesn't mean that there aren't conflicts with CPAN build scripts and Debian itself. Debian uses Perl as part of its own system core. It has a rather complicated policy to keep modules needed by the system separate from site installed modules and to prevent version conflicts between site and system versions. (see Debian Perl Policy). There is a reason why Debian spends so much time testing stuff for integration issues. Debian also sometimes has special versions of binaries that hard code Debian system locations. As a result, in general, I have found the .deb's retrieved by apt-get more reliable than CPAN - but they also tend to be several versions old and not everything on CPAN has a well tested .deb

        There are also different tolerance levels for sysadmin problems and complications depending on whether *nix is running on a server managed by a professional system administrator or on the desktop machines of developers. Developers may know their programming language and design tools well but sometimes have only sketchy ideas of sysadmin issues, even when its their own development tools that are being installed by a deployment system. I rather doubt most monks fall in this category, but I've brought in team members for Java work who think I have horns when I tell them they *must* learn basic command line skills.

        Best, beth

      Corporate no-use policies often reflect concerns about open-source "contamination" (a la Stallman) or ownership of IP.

      And even if your company doesn't have a foolish and shortsighted "no-use" policy, it may still have a very reasonable requirement that all software imports go via some central body with the authority to approve licenses.

      This is actually quite important. Many CPAN modules are licensed under the same terms as Perl, but not all of them are. For example, Math::Random explicitly states that "commercial incorporation of these routines into products to be sold requires permission and perhaps payment to the ACM", while Net::SMS is actually a demo for a commercial product and is licensed for internal evaluation purposes only. There aren't many companies that would be overly pleased about people bringing that kind of potential liability in through the back door ...

Re: Top Seven (Bad) Reasons Not To Use Modules
by JavaFan (Canon) on Mar 13, 2009 at 10:45 UTC
    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.
      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.
Re: Top Seven (Bad) Reasons Not To Use Modules
by DrHyde (Prior) on Mar 13, 2009 at 11:41 UTC

    A legitimate reason to avoid modules is that for those not steeped in the perl way, installing stuff from the CPAN is difficult - "what are all these questions it's asking me? I'm confused!" - and that installing stuff from the CPAN locally in your own directory is Dark Magic for most people. You can disagree with that if you like - lots of perl people do disagree with it. That's fine. You're allowed to be wrong.

    That's why rsnapshot (which I used to maintain, I've handed over to someone else now) requires no non-core modules at all, at the expense of lots of wheel-reinvention. In a lot of cases, rsnapshot will be the first time perl has been used on a machine (aside from anything that the OS itself uses it for) and so CPAN.pm won't be configured.

    For stuff targetted more at a perly audience where familiarity with installing CPAN modules can be taken as given, I do of course use other peoples' modules. But even so, I don't bother if I only need a tiny trivial piece of functionality. use File::Slurp; ...read_file... is ridiculous overkill. I avoid pointless dependencies like that because I know that if I don't, my code will be made harder to install even for perl-heads. That's because if any of my pre-requisites fail, then CPAN.pm won't install them, and then it won't install my code because my code won't pass its tests without 'em.

Re: Top Seven (Bad) Reasons Not To Use Modules
by jettero (Monsignor) on Mar 13, 2009 at 12:46 UTC

    I am not allowed to install modules sitewide

    This can be valid in some environments. One of my friends works at a huge mega conglomerate spanning countries and continents. Frequently, he uses perl to make tape drives do things all over the world. The scripts must be deployed on literally thousands of machines and installing modules is a really big deal -- usually involving a committee and multiple sysadmins at each physical location. He tends to avoid them at all costs and I can't say I blame him.

    Is there a solution for that? I really don't think there is.

    -Paul

Re: Top Seven (Bad) Reasons Not To Use Modules
by ack (Deacon) on Mar 13, 2009 at 18:29 UTC

    I have to confess that #6 is near and dear to my heart. Because on many of our systems it is not a matter of "installing locally"...it's a matter of how to get it onto the system in the first place since our security policies are strictly enforced (both automatically and manually).

    It is not too problematic when the module is pure Perl. The IT folks have been accomodating with that.

    But any modules that have to be brought in and compiled or as binaries are not allowed...no matter where I'd like or try to put them. We actually have IT programs that crawl though every nook and cranny of our system looking for binaries or "executable" modules...no matter what the extensions...and will auto-delete them!

    They have allowed us to use Perl and the built-in modules all we want and to create and use pure Perl scripts...but nothing else.

    So I have had to abandon using many, many of the modules I'd love to have access to and stick to either the built-ins or the pure Perl modules.

    So #6 isn't as easy or as universal as you might suggest.

    But I still find your observations (including #6) to be good counter-points to the normal comments...even when I've sometimes thought about not using available modules outside of our controlled systems.

    Your summary was really very illuminating for me. Thanks.

    ack Albuquerque, NM
Re: Top Seven (Bad) Reasons Not To Use Modules
by Erez (Curate) on Mar 15, 2009 at 11:21 UTC

    WRT #4, I'm of two minds on the subject. On one hand, I tend to scoff at the "no installation needed" at a day and age where users have machines infested with Java and Flash installation (often 2 or 3 of them) as well as other runtime environments. Maintaining a solid CPAN installation is usually easy and simple, and getting easier and simpler each day.

    OTOH, I encountered several instances where what was supposed to be a simple module turned out to be a full blown framework with Moose on top (hello, Jifty). This immediately get a "to be removed/replaced" tag.

    In regards to the entire post, as much as I'm a supporter of Best Practices Preaching, it tends to be considered as gospel, to be followed blindly, rather than "general rules that you may benefit from following". There are cases where all the above reasons are not valid, and, as mentioned above, cases where those should not be followed at all. There is no One True Rule, despite the many claims here, and elsewhere.

    "A core tenant of the greater Perl philosophy is to trust that the developer knows enough to solve the problem" - Jay Shirley, A case for Catalyst.

      I tend to scoff at the "no installation needed" at a day and age where users have machines infested with Java and Flash installation (often 2 or 3 of them) as well as other runtime environments.
      But there's a large difference between a user machine (which, nowadays, typically gets used by a single person, can be easily replaced, and if down, only affects one person) and a server that is important or even critical for the operation of a business.

      Having said that, I've worked on servers that have multiple Java installations as well - and, IMO, that was good. An application that needs Java, and comes with everything needed to run Java is so much easier to install than one that doesn't. If the app comes with Java, it will always have the right version (and if it doesn't, I can blame the vendor of the app) and will not conflict with other apps needing Java. And, IMO, that's the way to deliver (large) Perl applications as well. Include everything. All modules you need. Consider including perl itself as well (because even if your target OS comes with perl, it may not be the right version or it may be compiled with the wrong options).

      There is no One True Rule, despite the many claims here, and elsewhere.
      That, I fully agree with.
      I agree that there's the danger of advice being taken as gospel, as you put it. FWIW, I don't ask that anyone substitute my judgment for theirs, and I don't by any means think there is One True Rule on how to go about things. The only One True Rule is: think about what you are doing and use your best judgment.

      I simply felt that if I'm going to take a position in the meditation, it should be consistent. I wanted to offer food for thought, and so I presented my reasoning as directly as possible. As I've mentioned elsewhere, I've mainly been in situations where these arguments make sense: my systems don't get pushed to more than a handful of servers and accounts, and my organization's policies give me wide latitude to choose what software I need to accomplish the task at hand.

      Someone else would be much better qualified to write the contrary meditation on Top N (Good) Reasons Not To Use Modules. Maybe JavaFan? :)
        I think that in general good meditations show both sides of the arguments. The way you wrote your meditation was to present the counter-argument to use a module, and then to be very dismissive about it, in a style of writing that suggests only inferior developers could have considered such arguments.

        That's a way of writing that suggests to me you yourself didn't think the arguments over. Articles that picture the world using more shades of gray than black and white are far more useful - and carry much more weight in my book.

Re: Top Seven (Bad) Reasons Not To Use Modules
by codeacrobat (Chaplain) on Mar 15, 2009 at 13:08 UTC
Re: Top Seven (Bad) Reasons Not To Use Modules
by sundialsvc4 (Monsignor) on Mar 16, 2009 at 17:01 UTC

    I will toss my vote to using CPAN everywhere you can ... even for little things that seem “obvious,” because in this way you leverage what that other person has done. In many commercial data-processing scenarios, reliable and efficient use of human ... not computer ... time is paramount. Hence, CPAN is to me “what all the fuss is about.”

    Getting the app to-market quickly, and making sure it does not fail there, is essential to the conditions by which I earn my daily bread. “The app,” of course, consists of “installed and working source-code,” along with a fair amount of XS-magic inherent in much of CPAN. So the question becomes:   how did that source-code get there, and who wrote it and tested it?

    The notion that “it all must have come from little-old-me” absolutely falls flat on my stone deaf ears. I need the best source-code on my team, from whatever most-reliable source, as quickly as possible.

    You can incorporate modules from CPAN (or from any external source) into your applications without making system-wide changes. All you need is use lib, and a few easy local CPAN-configuration settings. Having downloaded and built the modules once, you can subsequently package them so that the deployment process is automated.

    What is not economically justifiable, IM2CW, is “let's do it all over again from scratch.” Even if you could do it, and even if you could do it in some “superlative way,” you could also be doing something else. “So, as I am looking everywhere I can find to cut costs, why exactly am I paying you the big-bucks to do what has already been done? ...”   :-O   ... hey, especially these days, it's worth thinking about.

Re: Top Seven (Bad) Reasons Not To Use Modules
by girarde (Friar) on Oct 08, 2009 at 16:16 UTC
    There's a module that almost does what I want, but it's buggy/broken

    That is often an opportunity to fix or extend. There was a nice active directory module that painlessly searched the tree and returned object names, but to do something with object you had to use the name and bind to it. Trivial to add methods that returned an object reference for direct use.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://750190]
Approved by moritz
Front-paged by moritz
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (14)
As of 2014-07-24 18:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (165 votes), past polls