in reply to RE: Stock Quotes
in thread Stock Quotes

I'm hesitant to use too many non-standard modules.
This may be because I am new to this.

Is it common practice to use all the modules you
can? I worry about it's portability then - what if the
system doesn't have the module installed and the
admins are slow/reluctant to install it?

-scribe

plus I had fun ;)

Replies are listed 'Best First'.
RE: Modules
by KM (Priest) on May 24, 2000 at 23:30 UTC
    It is good to have fun and learn. And, have fun learning. One of the reasons I have done Perl all these years is that I always have fun with it, unlike other languages where I didn't find it fun to be using and writing.

    Anyways, don't be hesitant to use modules that aren't part of the distrobution. There is a lot of useful modules out there that will save you time and headaches. To learn, it is always good to read the modules POD and source to see what makes it tick.

    Unless you are using a module which is specific to Win32, or *nix specific, then don't worry about portability. Many modules work fine on many platforms. If you have a reluctant sysadmin, you can still install modules under your home directory. Then you can change @INC to look there, or PERL5LIB.

    In order to allow users to install their own modules I have sometimes aliased 'perl' with 'perl -I/path/to/their/modules' which has worked nicely.

    Hope this helps.

    Cheers,
    KM

[reply]
      KM says: If you have a reluctant sysadmin, you can still install modules under your home directory. Then you can change @INC to look there, or PERL5LIB.

      I am sorry this question is begging for an RTFM answer, but please be gentle with me! I have been looking for the right M to FR for many months!

      Pretty please, can someone explain what KM said in simpler words? Or tell me where to find a real newbie's guide to installing modules?

      Firstly, what does "home directory" mean? Is this cgi-bin or the directory which contains it?

      Secondly, what does "change @INC to look there" mean. What is @INC and how do I change it? And will I still be able to use the sysadmin's modules?

      I am using Perl remotely on my webhost's server.
[reply]
        Firstly, what does "home directory" mean? Is this cgi-bin or the directory which contains it?

        Read the Unix manual. It's the directory you start in when you log into your webhost.

        Secondly, what does "change @INC to look there" mean. What is @INC and how do I change it? And will I still be able to use the sysadmin's modules?

        @INC is the list of directories that Perl uses to find the modules you requested that it bring into your script, like CGI or IO::File or whatever. You modify it by doing a 

        use lib '/this/directory/has/neat/modules';

        [download]
        @INC lookups are done last added first. Thus, if you added a directory, but the module you're use-ing or require-ing isn't there, it looks in the next entry in @INC. You already have a number of entries that are default. use lib 'somedir'; simply says "Look here first. If it isn't here, then look where you would've looked if I hadn't done this."

        As for you installing your own modules ... Learn more about Unix first. It sounds like you're a newbie to Unix in general. You'll have more headaches installing modules than you know what to do with. Of course, if you don't mind that, you'll learn a heck of a lot about Unix installing modules...

        As for learning Unix, go to a local library and borrow some books. It's a big learning curve, so don't expect to be an expert in a week, month, or even a year. But, you can expect to become at least proficient in a week or two.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
[d/l]
RE: Modules
by ZZamboni (Curate) on May 25, 2000 at 01:51 UTC
    I wholeheartedly agree with KM. Just for the sake of completeness, I will mention some arguments against using non-standard modules:
    • Learning how to do something yourself may be a worthwhile learning experience.
    • The module that does what you need may include a lot of extra functionality that you are not going to use. In those cases, sometimes it's good to peek under the hood and only extract the functionality you need (giving proper credit, and ideally asking for permission from the author) and putting it directly in your program
    Of course, this only applies to modules that do relatively simple things. If you need to do database access or write a CGI script. By all means, please, use the modules. There's no need to reinvent the wheel, particularly when it's a complex wheel.

    --ZZamboni

[reply]
      I agree with the first part of your argument, you can learn some excellent stuff by looking at what has already been done in other modules.

      However for anything other than learning, and your own pet projects, I would certainly recommend using non-standard modules (non-standard meaning modules not distributed with perl). I am not saying this because you might reinvent the wheel, but there is a huge part of good programming that people here seem to never think about: maintenance! If you copy and paste code from a module into your own code then you are stuck maintaining that code forever. So not only do you have to maintain the code specific to your project, but also the code that is general in purpose. Say there were actual bugs in the code you copied over, then instead of fixing the bug your self, you just use the CPAN module and grab the latest release (letting someone else fix the bugs for you).

      But of course there are some problems using the module approach, if the author decides to change the API from one version to the next then you have to modify your code to use the new version. But that is why I would not recommend for production code using modules with lower version numbers or ones that in the documentation say they are 'alpha' or 'beta' modules. Other than that, include what ever you think might be handy.

      Of course I recognize there are exceptions to every rule, like critical speed performance. But for most large applications, I just wanted to mention that I think maintenance should be a significant consideration. We may leave a project, but our code lives on forever!
      Something to think about anyway.

      Update: Anyone what to bother telling me why this node is a negative reputation? If you have a counter argument let me hear it, otherwise I still think the advise is pretty sound.
[reply]

In Section Code Catacombs