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


in reply to Re^2: Perl Code Changes Behavior if Two Subroutine definitions are swapped
in thread Perl Code Changes Behavior if Two Subroutine definitions are swapped

Hi Abhishek,

Modules whose use is discouraged is often noted in the module's documentation itself (for example, the top of the Switch page says "do not use if you can use given/when"). Otherwise, by looking at a distribution's CPAN page (this is the one for Switch), there are other clues as to when a module might not be good to use: if it has bad reviews, if it only had one release and/or hasn't had releases for many years, if its test statistics show a lot of failures, and/or if it has a lot of unresolved bugs. None of these things by themselves make a module bad, they are only clues, but if a module has a lot of these issues then you may want to stay away from it. The same clues can of course be used to tell if a module is "good": good reviews, several releases over several years, a low bug count, and good test results are all signs of a module being "good quality".

Off the top of my head, some modules that are often used even though their use is nowadays discouraged: XML::Simple (is only useful for a very narrow range of tasks, there are better modules like XML::Twig, XML::Rules, or XML::LibXML), Switch (a few alternatives), and CGI (there are more modern web frameworks, such as Catalyst, Dancer/Dancer2, and Mojolicious). <update> File::Slurp has a lot of issues, better to slurp manually or use one of the other modules. </update>

On the other hand, you can get a lot of good module suggestions from this site itself by reading threads with questions that relate to your tasks, or there is also Task::Kensho, a list of recommended modules for various tasks.

Hope this helps,
-- Hauke D

Replies are listed 'Best First'.
Re^4: Perl Code Changes Behavior if Two Subroutine definitions are swapped
by rkabhi (Acolyte) on Jul 28, 2016 at 05:21 UTC
    Hi Hauke,

    I am out of words to thank you for your thorough explanation. Though for now I got the problem resolved by avoiding switch module. I will be referring to your response time and again before using any new module.

    Thanks a lot !!

    Best Regards,
    Abhishek
[reply]
Re^4: Perl Code Changes Behavior if Two Subroutine definitions are swapped
by Cow1337killr (Monk) on Aug 02, 2016 at 01:13 UTC

    Thank you, haukex, for this enlightening post.

    I doubt that I am alone in wondering why CPAN does not have a better method of finding and marking modules that may be, for lack of a better word, obsolete.

[reply]

      That process itself would produce obsolete results rather quickly unless it were actively maintained. It cannot be robustly automated. Additional process is rarely the answer. Dated, versioned reviews are a better way that is available now.

[reply]

        Thank you, Your Mother, for your informative reply. Not a day goes by where I do not learn something new from you and your fellow Perl Monks.

        I had not even thought about reviews. I looked at http://search.cpan.org/~chorny/Switch-2.17/Switch.pm, but I don't know how to find reviews on that webpage. I surfed over to https://metacpan.org/pod/Switch; I can see the hyperlink for reviews there. I read them and did not find anything particularly damaging; one review concerned Switch (2.16) and the previous one concerned Switch (2.10). My point is that no one in the Perl community has taken the time to write a (negative) review about Switch (2.17) that was released on March 18, 2014; the points made in this thread were much more valuable.

        Additionally, we are advised in the documentation: "...do not use if you can use given/when". If I wasn't a Perl Monks website frequenter, I probably would not be aware that given and when are experimental keywords, which is another way of saying don't go building systems around these keywords, because one fine day, the wonderful people that bring us Perl will tell us that the experiment is over and it was (very likely) a failure.

        So, in summary, you know this stuff and I know this stuff, but for the casual Perl user, it comes under the unfortunate heading of learning curve, which, as we all know, goes straight up.

        I don't have to tell you that somehow, someway, we have to attract new blood into our Perl community. (I know that Real Soon Now robots will be writing the code, but that isn't happening fast enough.) So, if there is someone out there that could devote some neurons to a project, even a small one, even an experimental one, even one in the Acme:: top-level namespace, that could keep beginning and intermediate Perl programmers from pursuing dead ends (like the one described in this thread), it would be one more item that Perl could include in the pro column of the list of pros and cons.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom