Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

w/Modules and w/o Modules

by Jeri (Scribe)
on Sep 20, 2011 at 18:53 UTC ( [id://927000]=perlquestion: print w/replies, xml ) Need Help??

Jeri has asked for the wisdom of the Perl Monks concerning the following question:

Hi! I've been programming in Perl not even a year now. I've used modules in BioPerl and I've used Twig. However, (maybe because I'm new at this, can't seem to find the perfect opportunity to use a module. They seem cumbersome and slow. I tend to program/parse better then resorting to putting them in my code. Could someone please explain to me when using a module is most beneficial? (maybe I just like programming too much)

Replies are listed 'Best First'.
Re: w/Modules and w/o Modules
by davido (Cardinal) on Sep 21, 2011 at 05:57 UTC

    One point that I'd like to make is that the use of modules can enable you to leverage the work of an expert in some topic that you don't need to take the time to become an expert in. For example, just because you could learn everything there is to know about implementing a database interface doesn't mean that you necessarily would want to spend years learning all the ins and outs so that you could write your own DBI. In the meantime, you would be missing out on a lot of opportunities to actually "get something done." And then when you do finish your home-brewed version of DBI, your next client will ask if you could handle an XML stream, and might have no use for your shiny new database interface.

    Then there's the point of testing. And not just unit tests, but the tests-bed of thousands of real-world users. Look at DBI again. It would be one thing if a single author wrote it, and then he was the only one to use it. Hopefully he developed thorough tests along the way. But the reality is that thousands of people use it, and are able to find and report issues that the original author may never have considered when writing a test suite. The module has become mature, trusted, tested, used. It has years of embodied work in it that have brought it to the level of quality we enjoy today. There may still be imperfections, but its current condition is years ahead of any database interface you might cook up in a week or two.

    Do you have years to invest in every niche that you may run across when developing solutions?


    Dave

Re: w/Modules and w/o Modules
by eyepopslikeamosquito (Archbishop) on Sep 20, 2011 at 22:11 UTC

    This is a classic "buy versus build" decision.

    Whether or not to use a third-party CPAN module depends on your environment and on the quality and trust you place in the third party code. Notice that this is broader than just Perl and CPAN. In our case at work, for example, we commit to maintaining a large amount of code by many different programmers over many years that runs on many different platforms and is sold to thousands of customers. Accordingly, we consider any third-party dependency very carefully. Does the license allow us to freely redistribute it? What if there is a bug in the third-party code? How quickly can we troubleshoot it (often remotely at a customer site) and fix it? If you don't understand the third-party code or don't have good third-party support for the third-party code, you will be in trouble. That is a significantly different environment to someone writing Linux-only software for their PhD thesis. Or a company that writes single platform inhouse application software.

    You should also consider how much the third party software gives you, how hard is it to write it yourself. To give a specific example, we don't use File::Slurp because we don't feel the third party dependency is worth what the module provides; after all, it's easy to write your own file slurper. OTOH, we do use XML::Parser because it's a significant effort to write your own XML parser. To give another example, we wrote our own C++ unit test framework (because that is a simple job and we didn't want a third-party multi-platform dependency) while we did not write our own C++ compiler (which is a lot more effort). Unlike C++, there is a rock-solid de facto standard testing framework for Perl (Test::More) so we used that and did not roll our own.

Re: w/Modules and w/o Modules
by chromatic (Archbishop) on Sep 20, 2011 at 19:14 UTC

    How good is the test coverage of the code you've written?

    Have you read in copious detail the documentation of the file formats you're handling?

    How long have you been programming in any language?

    How do you know your code works?


    Improve your skills with Modern Perl: the free book.

      ...not to mention: How many more octagonal wheels does the world need?

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

      These questions are reasons as to why I should use a module? Maybe the better question would be, when should I not use a module?

        when should I not use a module?

        When your own code is better than the module, and when it's not worth your time to create and maintain your own code instead of using the module.


        Improve your skills with Modern Perl: the free book.

Re: w/Modules and w/o Modules
by wfsp (Abbot) on Sep 21, 2011 at 11:00 UTC
    …please explain to me when using a module is most beneficial?
    When it’s beneficial. :)

    A lot of my work with Perl revolves around web applications. My list of beneficial modules is almost always along the lines of

    I wouldn’t be seen out without them. Obviously there are many different approaches, these are the ones I use.

    One module I’d like to draw attention to is the marvellous Data::Page “help when paging through sets of results”. And that is exactly what it does, no more, no less. The author includes a note in the docs

    It has been said before that this code is "too simple" for CPAN, but I must disagree. I have seen people write this kind of code over and over again and they always get it wrong. Perhaps now they will spend more time getting the rest of their code right...
    “…always get it wrong.” Done that! :) I’ve never had so many off by one errors in so few lines of code. It even gives you the numbers for your MySQL limit clause. This for me is an excellent example of a beneficial module.

    But…

    I’m not a fan of all modules. Although frequently recommended by senior monks I have never gotten on with File::Find and its relatives. My use case is almost always “give me a list of all files under this dir”. I’ll grep for what files I want myself. So I’ve hand rolled a sub that does just that and everything got better, no more battling with, imo, quite difficult docs. I’m not advocating anyone else adopt this approach.

    I find modules extremely beneficial. There are times when I find them a nuisance and avoid them but that is very rare indeed.

      I’m not a fan of all modules

      A fellow discriminator, eh :)

      never gotten on with File::Find ... give me a list of all files under this dir

      You're using glob right?

Re: w/Modules and w/o Modules
by Marshall (Canon) on Sep 21, 2011 at 14:58 UTC
    You should be aware that lots of modules are "standard" and come with Perl. These are called "core" modules. See core.

    They seem cumbersome and slow.
    That's not true for all of them. I frequently use the core module: List::Util. In the distribution of Perl that I use, this comes compiled as an XS version, meaning that the code is implemented in C and runs like a rocket. The functions are all "short", but somebody took the trouble to implement them in a more efficient way than just native Perl.

    As you gain more programming experience and start writing larger applications, you will want to build modules of your own! The current project that I'm working on today has about 12 modules that I developed.

    Some of these modules are used in a number of my projects. One example: I've got some special functions for dealing with one particular time format that I use a lot. I wrote some of this stuff years ago, but I keep recycling this code easily by using my module. I test and maintain this code separately from the applications which use it. It is very reusable for the type of projects that I do - maybe in the future I'll make it more general purpose so that it can apply to more types of projects. Many CPAN modules evolve this way.

    Some modules are only used by one application and are modules because they represent a clearly defined "thought unit". One such example I have is about 800 lines of Perl and what it does is darn complicated, but my interface to it is only about 5 things even though it might run for 5 hours. It has its own version numbering, revision history and tests. So even though only one application uses this module, I created it to help me manage the complexity of the overall project.

    Anyway, at some point you will find yourself doing a lot of copy and pasting code from previous projects into current projects and the idea that this is a hassle will occur to you. Maybe once you see why you'd write your own module, you will more fully understand why you might want to use a module written by somebody else?

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2024-03-29 11:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found