Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Standard Perl Modules ~ Overkill

by pbeckingham (Parson)
on Apr 19, 2004 at 17:35 UTC ( #346360=perlmeditation: print w/ replies, xml ) Need Help??

I see many questions being asked on this site, many by relative new-comers to the language. Sometimes the questions require involved answers that make use of non-standard modules. This is good - complex problems are being solved by readily available, tested code.

But...

There are many other occasions, today being one, where the answers could take many, many forms, and given that TIMTOWTDI - no, wait - TIMTOWTDI in Perl, but algorithmically we have geometrically more ways. Ahem. Given that there are many, many ways to do it, sometimes we do not favor an answer that may be just as good, but does not require our new-comer to jump right in and start installing modules - a known difficulty for many at first.

I'd like to suggest that we provide answers using standard modules, when those solutions are adequate. New-comers just don't like installing modules to solve something that can be done with the standard distribution itself. Sometimes, the portability or the encoding just doesn't matter to the OP.

Update: Wow. It looks like people read that as "use core modules over CPAN", which I most definitely did not say. I do not advocate using core over CPAN, unless the result is just as good.

Are people really denying the quantity of module-installation issues that are reported here by new-comers?

Comment on Standard Perl Modules ~ Overkill
Re: Standard Perl Modules ~ Overkill
by mirod (Canon) on Apr 19, 2004 at 17:49 UTC

    Indeed sometimes using a module is overkill. However in a lot more cases, _not_ using a module is dangerous. I'll take overkill over bugs any time.

    Some tasks look deceiptively simple. Parsing CGI parameters, CSV data, or XML (of course!) for example are all tasks that might look simple, but really aren't, and you are much better of using a well tested module than rolling your own code. Using modules also cuts down on development (and question-answering!) time, so why shouldn't we advocate it?

    Finally, if installing a module is a problem for a newcomer, in the long (and even short) term, then helping them overcome that fear is doing them an even better service than solving their immediate problem.

    That said, feel free to spend the time answering questions qith just core modules if you feel like it ;--)

      Some tasks look deceiptively simple. Parsing CGI parameters, CSV data, or XML (of course!) for example are all tasks that might look simple, but really aren't, and you are much better of using a well tested module than rolling your own code. Using modules also cuts down on development (and question-answering!) time, so why shouldn't we advocate it?

      I think what pbeckingham is advocating is merely that people should give more thought to suggesting simple solutions using core modules, before recommending alternate, possibly simpler, approaches that require installing newer less standard modules.

      Parsing CGI parameters is a great example. We should suggest using good modules that we think provide a benefit, but let's not put the cart before the horse. Suggest use CGI first, and then if you have a particular affinity to an non standard module that you think mkes things even easier (CGI::Simple for example) then by all means suggest it.

      Another great example is when people post questions asking for "A regex that matches _______". I agree that suggesting they install Regex::Common and use it is a great idea, explaining how that way they are constantly getting tweaks, improvements, and additions from the rest of hte perl community -- but there's no reason we can't also post a particular regex from that module which meets their needs, and explain how it works so they can learn to write their own regexes.

      There is a delicate balance between teaching someone how to solve their own problems, and showing them how to utilize the work of others so they don't have to solve every problem on their own. We should all try to remember to do both with equal fervor.

Re: Standard Perl Modules ~ Overkill
by samtregar (Abbot) on Apr 19, 2004 at 18:24 UTC
    From the title I thought I was going to read a node about the absurd growth of the Perl Standard Library. The smile slid from my face when I realized this is actually a node about not preaching the power of CPAN every day.

    CPAN is what makes Perl worth using, plain and simple. If it weren't for CPAN, why not use Ruby or Python? Why not Guile or TCL? Sure, Perl is a nice language but there are lots of nice languages. But just try programming in one of them someday and the thing you'll miss first and last is the power and depth of CPAN.

    Beginners should be taught to look for solutions on CPAN as soon as they learn to use modules. In my opinion Perl should come with just a handful of modules and CPAN.pm.

    -sam

      From the title I thought I was going to read a node about the absurd growth of the Perl Standard Library. The smile slid from my face when I realized this is actually a node about not preaching the power of CPAN every day.

      Actually, maybe it's just me but I don't think the perl standard library is a) very standard, or b) very comprehensive.

      Re: a) - please link me to the description of the Perl Standard Library. I'm not being flippant - it definitely seems like a good thing, I just don't know where it is. ActiveState for Windows is different from ActiveState for Solaris is different (obviously) from the Sun distribution which is different from the distribution you build yourself from source which, of course, is different from the Windows distribution that you could build yourself.

      Re: b) - The Standard Library (which I concede must be out there somewhere) seems to be missing some basic internet functionality. I'm not talking about the ActiveState distribution. Seems like LWP::Simple ought to be standard but is not (from my solaris builds, anyhow). XMLRPC or SOAP ought to be. For crying out loud, even just XML::Simple or XML::Parser (which, again, in my experience has not been part of the "standard" distribution).

      Finally, in general, a lot of the responses in this thread seem to apply to a local/single distribution. In a corporate environment, adding modules (even if the basic process of building the module is no problem) can be a challenge administratively, logistically, and networkily.

      My mileage may vary, but that's what I've been getting recently!

      -- Andy

        The only real standard Perl library is what you get from the perl source releases.
Re: Standard Perl Modules ~ Overkill
by dragonchild (Archbishop) on Apr 19, 2004 at 18:39 UTC
    There was a meditation recently titled something like I never thought I'd have to do this on that OS. The more a PHB realizes how quickly solutions are created in Perl for OS foo, they automatically (and rightly!) think that it should be doable on OS bar. And, it is ... if you use the modules.

    I think that addresses the portability issue.

    ... does not require our new-comer to jump right in and start installing modules - a known difficulty for many at first.

    What difficulties? What issues? This is an assertion which flies in the face of accepted knowledge without any supporting statements. On every Unix-like system, the following works quite nicely:

    foo% perl -MCPAN -e shell cpan> install X cpan> exit

    With ActivePerl, you have the following:

    C:\Perl\bin> ppm ppm> install X ppm> exit
    Very rarely do modules fail to install. When they do, you email the module's author and they fix it. Or, you post here and we not only fix it, but provide a work-around, and explain why it failed. All of which is a good education for our newbie.

    You are correct in one respect - there are often a multitude of solutions on CPAN for a given problem. Many are incomplete or tailored to a specific need. Many are buggy and/or no longer supported. Navigating that successfully is only done with experience - the experience that is found at the Monastery, among other places.

    Remember - the goal of asking a question is not to get the answer. It's to learn how to get the answer. Sometimes, it's even to learn what question to ask. Focusing on the task at hand is a good way to never achieve independence. It can be dizzingly confusing at times, but it is the only way to true enlightenment.

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

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      Very rarely do modules fail to install.

      I see module installation issues occur as questions on this site, almost every day.

      The authors do need to be notified, and the problem, if any, does need to be resolved. I'm not arguing that.

      What I am arguing, is that sometimes a module is unnecessary, and a solution that is just as valid can be provided using core modules.

      Very rarely do modules fail to install.

      Not true on my planet. I'm astonished at how often even simple modules fail to install (for me and for others). I'm staggered at how much effort and code has gone into addressing the installation of modules -- and yet most resulting systems that I've tried fail about as often as they succeed and even the most reliable (perl Makefile.PL + make) fails all too often. And I'm astounded at how quite a few complex modules can be nearly impossible to install.

      Maybe your view on this is because you've been blessed with exceptionally "vanilla" systems (just a wild guess).

      I avoid non-standard Perl modules much of the time, in part because even when I can get a module to install, I very often find that it is unsuitable. There's lots of great stuff on CPAN and even more good, useful stuff on CPAN, and tons more stuff further down that end of the quality scale.

      A total refusal to use modules is an all-too-common situation and I find it unacceptable. But I often avoid non-standard modules and I appreciate it when others realize there is a price for using a non-standard module and that sometimes the benefit doesn't out-weight that price. Perhaps you've already downloaded and installed the module (and maybe didn't have any problems doing that) and have read the documentation and figured out its quirks and found that it works well the way you use it and remember enough, but for a non-standard module, most people will still have all of those hoops to jump through.

      My initial reaction to the root node was about the same as mirod's. And it still is.

      But I also now realize that I wish more people would pay attention to the 'cost' of using a module (especially a non-standard module or a module that won't work on slightly-old Perl versions). There are still plenty of cases where the cost/benefit is a no-brainer in favor of using the module (for me, sending e-mail from Perl would be such a case). And I consider "no modules" to be an unreasonable stance.

      But, "just do use Date::Module; ConvertRoutine(...)" sure looks easy, and probably is really easy for the person who writes it. But I usually find that it isn't very easy. Perhaps because I must be convinced that it really does solve my problem before I'll use it, and one test doesn't convince me.

      So let's have some balance on the scale of "use modules".

      *shrug* All I really wanted to say was the first sentence. (:

      - tye        

      I would just like to point out that installing modules with ppm is easy IF active state has that module. Recently I tried to install PDL and to my amazment it can't be installed by ppm unless you goto pdl.perl.org and download a binary to run. This is a common case with modules when trying to install on windows. A lot of modules do not install using ppm. It is sad but true. Perhaps there is some tutorial or something about expanding ppm but I haven't seen it yet.


      ___________
      Eric Hodges
Re: Standard Perl Modules ~ Overkill
by allolex (Curate) on Apr 19, 2004 at 18:49 UTC

    I think your suggestion is really great for teaching programming with Perl, but it's not as good for teaching people how to use Perl effectively. Despite that statement, I do have mixed feelings about the whole thing, since I consider both to be very important. It is true, however, that it is impossible to master Perl per se without being able to use CPAN effectively.

    You'll probably find that a lot of the monks disagree with you, but I think your post reflects some real thought. I also think that the nature of the Monastery, with its many opinions and opinionations will make sure that both the core language and CPAN are covered.

    Don't forget that part of the reason the Monastery works so well is because people enjoy posting. Sometimes we get golf, but most of the time we get answers that really help. I suspect that requiring people to use the core language would be seen as unfun and discourage the plurality of paths to the same goal.

    --
    Damon Allen Davison
    http://www.allolex.net

      requiring people to use the core language ...
      There is no talk of "requiring". I think pbeckingham is simply trying to raise our consciousness on this issue when we go to reply. E.g. if we see (as I did just today) a question that has gotten a slew of non-standard-module-based responses, consider offering a solution based on the standard library or core language. And vice versa.

      jdporter
      The 6th Rule of Perl Club is -- There is no Rule #6.

        You're right. He doesn't use the word "require". He does however say "I'd like to suggest that we provide answers using standard modules, when those solutions are adequate," which appears to suggest that he wants us to offer solutions based on something other than what we might have posted originally. That is what I meant with 'require".

        You made me think of another thing, as well. I interpreted the OP as saying something like "instead of posting stuff with modules that are not well-known, post stuff written using the core language, or with modules that are part of the distribution." This second issue depends greatly on what we think "standard modules" means. For me those are the ones that come with the Perl distribution, and pbeckingham states here that this is what he meant.

        But we first have to arrive at a consensus about which modules are standard (core, core plus DBI, etc.), which is a discussion onto itself. I wonder how many monks are posting stuff using modules they consider to be standard, but which others do not.

        --
        Damon Allen Davison
        http://www.allolex.net

Re: Standard Perl Modules ~ Overkill
by Anonymous Monk on Apr 19, 2004 at 20:11 UTC
    Are people really denying the quantity of module-installation issues that are reported here by new-comers?
    Are you really denying the quantity of new-comer stupidity?

      New-comers are not stupid. They have - by definition - limited experience with Perl, and even less with module installation. This is an ideal site for them to get their questions answered and needs met. They should ask those questions - all it takes is a little exposure to the way Perl works, before they get hooked on Perl the same way you and I did.

      It's a good thing that you chose anonymity to hide behind, with your naive assumption that because someone is less experienced than you they are stupid. Shame on you.

Re: Standard Perl Modules ~ Overkill
by flyingmoose (Priest) on Apr 20, 2004 at 02:14 UTC
    The reasons for me not to use CPAN modules are, as I'm sure most folks will agree


    a) if the module is sloppy or not cool enough, and I could do better (rare)
    b) if the module takes more than one CPAN command with dependancy scanning to install (frequent! Tk::Zinc as of late)
    c) if I think the module is changing interfaces too fast or is otherwise unstable (frequent)
    d) if the module is really really heavy for what I want to do and may cause maintaince problems due to the amount of new stuff I need to grok and remember (aka PAR) (frequent)
    e) if I need to redistribute the script to a bunch of folks with just perl installed by default, PAR isn't good enough or makes too large of a binary, and the audience isn't Perl-educated enough to use CPAN (very frequent) -- this happens a lot when I'm writing quicky scripts that are little more than shell scripts, module use causes problems for those I need to give the script too, but Perl is still better than shell.

    For my own coding, I use (good) modules all of the time. But there are plenty of situations when I can't use them, just like I feel I can't use any random C library I find on the internet -- it has to be stable, good, and easy for other people to compile/use, with a decent user base. This isn't exclusively a perl problem.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (15)
As of 2014-07-29 09:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (213 votes), past polls