Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

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

by ELISHEVA (Prior)
on Mar 13, 2009 at 04:42 UTC ( [id://750311]=note: print w/replies, xml ) Need Help??


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

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

Replies are listed 'Best First'.
Re^2: Top Seven (Bad) Reasons Not To Use Modules
by moritz (Cardinal) on Mar 13, 2009 at 07:51 UTC
    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

Re^2: Top Seven (Bad) Reasons Not To Use Modules
by Porculus (Hermit) on Mar 14, 2009 at 00:21 UTC
    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 ...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://750311]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2024-03-28 15:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found