http://qs321.pair.com?node_id=1231946

Vote on this poll

It has a recent release
[bar] 12/8%
The newest release passes all its tests
[bar] 5/3%
Its tests have good coverage
[bar] 0/0%
It is of high kwalitee
[bar] 1/1%
It has many MetaCPAN ++s
[bar] 7/5%
There are no long-standing open bugs
[bar] 6/4%
It is pure perl (ie. no XS)
[bar] 9/6%
It has no/few non-core dependencies
[bar] 9/6%
Many other modules use it
[bar] 8/6%
The author is prolific
[bar] 7/5%
It is as generic as possible
[bar] 3/2%
The licence is acceptable (Artistic/GPL/BSD - delete as appropriate)
[bar] 5/3%
It has good reviews*
[bar] 4/3%
It has extensive and clear documentation
[bar] 33/23%
It is recommended by a Monk
[bar] 36/25%
145 total votes
Replies are listed 'Best First'.
Re: I am most likely to install a new module from CPAN if:
by BrowserUk (Patriarch) on Apr 01, 2019 at 21:30 UTC

    Many of those reasons for; I consider to be reasons against:

    • It has a recent release

      Under active maintenance could be a plus; but it also means it needed maintenance.

      In other words, it completely depends on why a new release was required.

      If the release fixes a reported bug, that's good; but if it adds (unrequested and/or unnecessary) new functionality to an existing, working module with no reported bugs -- eg. non-Q functionality added to the Thread:Queue module by the new owner -- it's bad!

    • The newest release passes all its tests

      As stated, this is neither good nor bad.

      Did the last version also pass all tests? Were the changes required? Were new tests added to cover the changes?

      Basically, a nonsense criteria.

    • Its tests have good coverage

      A definite negative.

      Any author that has bought in to the fiction that automated coverage tools serve any useful purpose is suffering from cool-aid intoxication and thus delusional.

      The idea that adding tests to test stuff that doesn't warrant testing, simply to satisfy a dumb automated coverage tool that has simply no knowledge of what needs to be tested, is the very height of TDD arrogance.

    • It is of high kwalitee

      Definitely negative.

      If they can't even spell the word correctly, what chance that anything else they do is useful!

    • It has many MetaCPAN ++s

      "7 out of 10 cat owners said their cat's preferred it."

      Which 10 owners? (The ones who accepted your offer of a lifetime's free supply if they signed off on you quoting them?) And do they all have talking cat's that could inform them of their preferences?

    • There are no long-standing open bugs

      Depends if the long standing open bug affects my use of the module.

    • It is pure perl (ie. no XS)

      Non-issue.

    • It has no/few non-core dependencies

      Can be a recommendation; but the opposite (has many) is a much stronger negative for me. eg. Moose which seems to try to use every module on cpan even if it only requires a single 1-line function from it.

    • Many other modules use it

      Can be a recommendation; but only if all (or most) of those other modules are not by the same author.

      eg. less is (or was) included in dozens of modules despite that it does nothing and never will.

    • The author is prolific

      Usually a negative unless proven otherwise.

      Prolific module writer's often write modules purely for the sake of being prolific! They write modules in absence of having a real-world use; thus they do little real-world research or testing and define interfaces in terms of what is convenient to the internals of the module; not the convenience of real-world calling code. They also tend to fire-and-forget; write, passs the tests they thought of and upload; and never again maintain.

      There are exceptions. There are some prolific authors who produce exceptional modules; and provide exceptional support to them all.

    • It is as generic as possible

      Generality in a module is (nearly) always a bad thing.

      Jack of all trades, master of none; lowest common denominator; bloated and overcomplicated, slow and clumsy. the very antithesis of the Unix philosophy:"do one thing and do it well".

    • The licence is acceptable (Artistic/GPL/BSD - delete as appropriate)

      Utterly irrelevant!

      Firstly, there are so many of these meaningless licenses; and no one -- not even the lawyers -- know if any of them would stand up in court. The best anyone can say is that if you come up against someone with enough money to flush and the arrogance to keep going, your gonna loose. eg. Oracle .v. Google

    • It has good reviews

      Beware prolific review writers. Read all the reviews before taking the star rating at face value. Realise that there is no mechanism for indicating a negative review, so even a disastrous review (like: This module produces completely the wrong result.) can at worst give a 1-star rating. Add one review by someone who found it easy to use but hasn't realised it produces the wrong results with a 5-star rating and the module has a 3-star average!

    • It has extensive and clear documentation

      Extensive is the antithesis of clear!

      If a module requires extensive documentation, it should probably be more than one module.

    • It is recommended by a Monk

      Depends on the Monk.

      Sundial regularly recommended Parser::RecDescent, despite that it is bloody obvious he never used it.

    My criteria: 1) Do I need it. 2) Does it work. 3) Does it work efficiently. 4) Does it only do what I need to and not a whole raft of other things that I do not need. 5) Does it have none, or only a few necessary dependencies.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

      It is of high kwalitee

      Definitely negative.

      If they can't even spell the word correctly, what chance that anything else they do is useful!

      Tru dat... :-)

      Sorry, I couldn't resist a joke. I've worked with many people who wrote things for professional publication that had no business writing anything at all. They were all native English speakers too, supposedly, so at best they could plead not at fault on the grounds of having been put through the United States public education system. Subsequently, this Dilbert is permanently fixed to my wall.

      Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.
      And do they all have talking cat's that could inform them of their preferences?

      Just because they can't talk doesn't mean they can't communicate. My cats certainly communicate their preferences - "mrrrp", "meh" or "YEOOOW".

        A hungry cat will eat whatever it can get -- from fresh killed prey to rotting (human) corpses -- it is the owner's of pampered house cats that believe that gourmet pet food is a good thing.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
Re: I am most likely to install a new module from CPAN if:
by pryrt (Abbot) on Apr 01, 2019 at 17:14 UTC

    multiple + other -- most of those would influence whether or not I use it. And a few other influencing params:

    • it works for me
    • it's the only interface (or most-readily available interface) for an external library
    • using the approximate solution found in the CPAN module was easier than coding a whole exact solution by myself
    • using the premade solution had better edge-case coverage than what I came up with
    • which criteria was used depended on the exact specifications for the code being developed
    • it works on Windows with Strawberry Perl, not just on linux
      → aka "good cross-platform compatibility"
    • it works on an ancient machine with perl v5.8 (or preferably v5.6)

    and though this hasn't influenced me yet, I know it does some monks:

    • it's small enough to fit on (insert favorite small embedded system with a tiny perl here)
Re: I am most likely to install a new module from CPAN if:
by Tux (Canon) on Apr 02, 2019 at 14:00 UTC

    First of all: does it give me a/the solution to the problem I have.

    • It has a recent release
      Depends on the reason. A proven well-behaving module might not need a regular release.
      Way more important is a good ChangeLog with the release.
    • The newest release passes all its tests
      Depends on the coverage (sorry BrowserUK, this *does* matter). It is easy to make a module to pass all tests if there is only one test that tests nothing: ok (1, "Make it PASS!"); is a legal but useless test
      I certainly prefer the release to pass all tests, but if the only FAIL'ing test is an ill-written test that depends on floating points being rounded to 12 digits instead of 32 on a system with long long long doubles, I do not really care. Likewise fir 1 nanosecond differences in speedtests.
    • Its tests have good coverage
      Yes, but with well-defined tests. It is not hard to write a test suite that covers all of the code, without testing its functionality.
    • It is of high kwalitee
      Prefered, as that shows that the author is aware of possible issues, but in the end it doesn't say a thing about the functionality, the usability or the correctness of the code.
    • It has many MetaCPAN ++s
      Depends if the ++'s are recent. ++'s on version 0.12 from 2001 are not useful at all if the current version is 2.34 from 2019.
      And ++'s do not have to be for the part of the code I am interested in.
    • There are no long-standing open bugs
      Depends. If I am working on Linux and the open bugs only affect Windows or vice-versa, I do not care at all.
    • It is pure perl (ie. no XS)
      Preferably the other way around :) Most XS modules are way faster than the PP counterparts.
    • It has no/few non-core dependencies
      CORE deps are fine: they will be there. Period.
      Non-core deps depend. There is no use in writing a DBD module without using DBI.
      I *hate* authors depending on useless non-core modules (however useful for them) like Modern::Perl, sanity, and common::sense. Depending on those are a red flag to me.
    • Many other modules use it
      I agree here with BrowserUK: a useless metric if all those are from the same author. That would be an indication of reinventing a wheel.
    • The author is prolific
      That is a void option. Way more important is if the author is responsible and acts/reacts in a mannered way to bug reports and/or questions. Check (recent) issues and tickets for questions and answers to see if the level of support is meeting your needs.
    • It is as generic as possible
      Non-issue. Why would this be a reason to use/reject a module?
    • The licence is acceptable (Artistic/GPL/BSD - delete as appropriate)
      *I* don't care, as long as I am licensed top use it for free.
    • It has good reviews*
      Where? By whom? Do the reviews talk about the functionality I want to use or just about how well the GUI looks that I do not plan to use?
    • It has extensive and clear documentation
      Very important. It must be up-to-date, complete and easy to read (not full of typos or words that only someone with a native tongue will recognize).
    • It is recommended by a Monk
      That might help, though it of course depends on how well I trust that monk (agreeing with BrowserUK again).

    And additionally

    • A well defined minimum version of perl (with a reason)
    • A complete META file
    • A location for tickets (RT/GitHub)
    • A location for help (IRC/MailingList/GitHub)
    • An examples section in the docs or an examples folder in the dist with easy to understand code chunks
    • Consistent code style. At least in the documentation
    • A README and/or INSTALL doc if make install is not enough
    • Conforms to standards (when applicable)

    Enjoy, Have FUN! H.Merijn

      Only one bone of contention here:

      Depends on the coverage (sorry BrowserUK, this *does* matter). It is easy to make a module to pass all tests if there is only one test that tests nothing: ok (1, "Make it PASS!"); is a legal but useless test

      Coverage tools have there place; and that place is for authors, not users!

      An automated coverage tool can act as a sanity check; as a guide for the author to decide if s/he has written all the test s/he believes are necessary.

      But the moment the numerical summation produced by a dumb code evaluator becomes a tool for users to judge the quality of an author's work and decisions, software development goes to hell in a hand basket.

      Until code coverage tools get smart enough to actually write the tests for all the places they suggest need one; they should serve only as suggestions to the human being charged with writing them. And any user who believes that 100% coverage tells them anything about the quality of the testing is in for a very rude awakening.

      In the end, always run my own sanity check of the functionality I import from 3rd party modules, and if it appears to produce the correct results for my usage, all the gibberish numbers (supposedly good or bad) produced by the automated test/coverage/kwality/et al tools and processes are entirely meaningless.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
Re: I am most likely to install a new module from CPAN if:
by perldigious (Priest) on Apr 03, 2019 at 20:16 UTC

    Sadly, my honest answer to this is, "if I wasn't able to reinvent the wheel myself quick/well enough." It's a terrible practice, I know, but I'll usually bang away at my keyboard for a long time trying to solve a problem with core Perl or whatever module defaults came with my Strawberry Perl install (or additional modules I've already installed) before I go looking around in CPAN. :-/

    Assuming I have already started looking in CPAN, I'll use any module that I can find that will, or at least seems like it will, solve my problem. As long as it at least makes some sort of sense to me when I first glance at the documentation... or that was recommended by another Monk I trust for advice.

    Clever isn't the same thing as wise, but that's a moot point because I'm neither... I'm mostly just stubborn. :-)

    Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.
      "if I wasn't able to reinvent the wheel myself quick/well enough."

      Nothing wrong with that, imho.

      I learned Perl (and programming of at least four other languages besides Perl) by trying and doing. Whether re-inventing the wheel is for learning or practice, or even if one feels they can invent a better wheel, I say go for it! I know I've both invented wheels I didn't know existed, as well as re-invent wheels I felt were a more efficient design. Right or wrong in that regard, I digress.

      Think of it this way... some wheels are hammered out for so long, that we just accept that's the way the wheel should be. Sometimes however, someone comes up with a more sleek design of the wheel that makes it travel faster, with less effort. Only way that happens is if someone puts their foot forward to test a new wheel design.

      For larger things (a very complex set of instructions for example), sometimes it's better (and oftentimes far easier) to just run with what's out there, and focus on your cart instead of re-designing the wheels.

      For example, I've created mocking distributions, logging distributions, subroutine wrapper distributions etc, even though there are several available already. These were created because I wanted to learn. Things more complex that have a very, very good rapport (random eg. Getopt::Long) that have a spectacular history, there's no need to re-invent or try to make better that wheel (unless, of course, you become an open source contributor, and add/patch/fix the existing one).

        Back in the day, I was asked to take 2 weeks to learn Perl, before being assigned to work on some Perl based report scripts.

        Since I needed a goal, I grabbed a sample script that echoed back on a socket, downloaded some RFCs, and chiselled out myself a webserver that could facilitate posting offers and accepting resource trades for a forum game. (Naturally, it worked great for any browser except IE)

        I don't know if that counts as reinventing, as I certainly wouldn't want to offer it as an actual thing to use normally, but it rolled despite the primitiveness and I learned a lot making it on my own!

Re: I am most likely to install a new module from CPAN if:
by stevieb (Canon) on Apr 02, 2019 at 15:08 UTC

    Great feedback on this poll!

    A couple I haven't seen mentioned:

    • Track record of backwards compatibility: Does the author have a history of keeping existing things stable from release to release, or are previous pieces of functionality continuously changed for no seemingly apparent reason (and without a reasonable amount of time with notices of deprecation or mods that will definitely break stuff)? (ie. will I have to frequently update my distributions due to frequent changes to the dependency)
    • A good Changes file. Clear, concise (point-form, not overly verbose) information from version to version, possibly including references to tickets etc
    • A *quality* test suite. I can write a 50,000 test test-suite, but how many of those tests are of decent quality? Can I read through tests for example code snips if necessary? Is the suite well laid out with informative file names?
    • Test history... does the distribution have a poor failure rate across several releases?
    • Does the code unnecessarily piss all over my namespace(s)?
    • Does the code blatantly do ridiculous magic for no apparent reason that could cause me hard-to-identify bugs later on down the road?

    There are several more that I can't think of right now. Note that some of the above I'm going a bit overboard on... I don't read through every line of code before deciding to use a module. I do however have a reasonable glance to check for consistency, blatantly obvious weirdness, naming of various items (ie. names like sub_a(), sub_b(), my $var1, $var2 etc are red flags) etc

Re: I am most likely to install a new module from CPAN if:
by BillKSmith (Monsignor) on Apr 04, 2019 at 15:12 UTC
    There should be a choice for "It seems like the best solution to my immediate problem." It is another issue whether or not I keep it.
    Bill
Re: I am most likely to install a new module from CPAN if:
by duelafn (Parson) on Apr 01, 2019 at 19:54 UTC

    I'm lazy and use:

    • Is packaged for Debian

    Which generally means that someone else has checked that it meets at least a few of the above.

    Good Day,
        Dean

Re: I am most likely to install a new module from CPAN if:
by dsheroh (Monsignor) on Apr 07, 2019 at 08:55 UTC
    • It's a dependency of some other module that I actually want to install
    The large majority of the Perl modules I install/have installed are things that I don't even know are there and were just installed because something else used them.
Re: I am most likely to install a new module from CPAN if:
by syphilis (Archbishop) on Apr 07, 2019 at 13:17 UTC
    It is pure perl (ie. no XS)

    Where is the "It is XS (ie. not pure perl)" option ?

    As someone who views XS as perl's greatest feature, that's the option I'd be most likely to vote for.

    Cheers,
    Rob
Re: I am most likely to install a new module from CPAN if:
by Perl300 (Friar) on Apr 16, 2019 at 15:22 UTC

    This is the survey I liked most among all those I have seen until now. Thank you hippo

    I hope there should have been a way to select more than one option. In my case I do rely on multiple factors like:

    • It has a recent release
    • It has many MetaCPAN ++s
    • It is recommended by a Monk
    • It has clear documentation. Doesn't need to be extensive, if it shows me how to do something that meets my needs. I use it.
Re: I am most likely to install a new module from CPAN if:
by karlgoethebier (Abbot) on Apr 04, 2019 at 16:21 UTC

    Recommended by our beloved leader might be an option. But wait: He doesn’t use modules as they are for sissies 😎

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      He doesn�t use modules as they are for sissies

      Two issues:

      1. I do use modules; but only the good ones.
      2. How do you know I'm not a sissy?

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
        "...How do you know I'm not a sissy?..."

        I'm sure you aren't as i'm a hang-around since 2012 or so. BTW: Did you finally buy a Mac? Best regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

View List Of Past Polls