Acme-CPANModules-Import-CPANRatings-User-stevenharyanto

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        <br>

    Locale::Maketext
        Author: TODDR <https://metacpan.org/author/TODDR>

        Users might want to check out this article on why one should perhaps
        use Locale::TextDomain instead of Locale::Maketext: <a
        href="http://www.perladvent.org/2013/2013-12-09.html"
        rel="nofollow">www.perladvent.org/2013/2013-12-09.html</a>

    Curses::Toolkit
        Nice effort, but one might also want to look at Tickit, which is not
        curses-based and looks more promising. Being based on Curses, this
        module still suffers from the many bugs and limitations of curses.
        The lack of Shift-Tab support, for one. <br><br>See also: <a
        href="http://www.perlmonks.org/?node_id=1059926"
        rel="nofollow">www.perlmonks.org/?node_id=1059926</a> <br><br>As I
        explore doing TUI more, I will update the reviews. <br>

    Moo::Lax
        Author: DAMS <https://metacpan.org/author/DAMS>

        Great idea! I've been bitten and annoyed by strictures on more than
        one occasion. It has its uses, but users should have a choice on how
        to react to warnings. <br>

    App::YTDL
        This module is based on WWW::YouTube::Download but its documentation
        does not yet explain how it differs from WWW::YouTube::Download.
        From what I see at a glance, App::YTDL supports downloading a video
        from a playlist and setting download speed limit, but perhaps the
        author should do the mode detailed explaining to help users when to
        choose between the two. <br>

    Data::CompactDump
        Author: MILSO <https://metacpan.org/author/MILSO>

        At the current form, simply too simplistic to be an alternative to
        Data::Dump or Data::Dumper. No support for blessed refs,
        filehandle/globs, circular references, and so on. Changes numbers to
        stringy numbers or vice versa. <br><br>Currently also contains some
        bugs like for -1 (changes it to string), &quot;\&quot; (produces
        invalid dump, does not handle backslash yet currently), <br><br>And
        Data::Dump's dump of {} and [] are currently more compact ;-)
        <br><br>Need to be improved significantly first. But keep up the
        effort.

    P   Author: LAWALSH <https://metacpan.org/author/LAWALSH>

        I personally don't mind the namespace choice. There are other
        single-letter CPAN modules too like B, L, U, V. If you have a beef
        with regard to namespace, don't single out P and perhaps downvote
        the other modules too. <br><br>Having said that, I would like to
        comment on the design and implementation of this module. <br><br>1)
        The choice of Unicode character U+2204 as representation of undef.
        Unless one does something like 'binmode STDOUT, &quot;:utf8&quot;',
        with 'say P undef' I am just trading one warning (&quot;Use of
        uninitialized value&quot;) with another (&quot;Wide character in
        say/print&quot;). The wide character warning is avoided if you do 'P
        &quot;%s&quot;, undef' though, which means... <br><br>2) P loads
        utf8 by default. For ultra-lightweight cases, this is sometimes not
        desirable. There is currently no way to turn this off. <br><br>3)
        The arbitrary choice of three levels deep when printing references.
        This can be customized but with an unusual syntax. But again, the
        arbitrary choice of three. <br><br>4) The &quot;complex&quot; rules
        of newline printing. p() is like puts, it can optionally add a
        newline. But unlike puts, the doc says it can also remove newlines.
        The behavior can also change if the string to be printed ends with
        0x83. <br><br>I might use P for a sprintf/printf replacement, but
        for debugging values, I'd prefer something &quot;dumber&quot; like
        Data::Dump::Color (or Data::Printer, if that's your thing).

    Xporter
        Author: LAWALSH <https://metacpan.org/author/LAWALSH>

        A couple of comments. First, if you want to import the default
        exports *as well as* some additional others, you can use Exporter's
        feature (the :DEFAULT tag): <br><br>use SomeModule qw(:DEFAULT a b
        c); <br><br>or you can also &quot;use&quot; twice: <br><br>use
        SomeModule; # imports default exports <br><br>use SomeModule qw(a b
        c); # import a, b, c <br><br>Second, if you use Xporter, your module
        will behave unlike most CPAN modules out there, because a majority
        of modules use Exporter. When people see this Perl code: <br><br>use
        SomeModule qw(a b c); <br><br>normally they will expect only a, b,
        and c are exported. If SomeModule uses Xporter, it will also by
        default export the default exports. <br><br>Basically Xporter is
        just Exporter with a different default (not arguably better or more
        user-friendly). For the sake of minimizing surprise to my users, I
        would avoid the use of Xporter. <br><br>UPDATE 2014-01-24: some
        edits. I appreciate the effort of the author to defend her module,
        though I am not convinced by her arguments.

    Dist::Zilla::Shell
        Author: DOLMEN <https://metacpan.org/author/DOLMEN>

        Nice tool that lets you type dzil commands like 'build', 'test', etc
        while sending all the other unknown commands like 'ls -l', 'man Foo'
        to the underlying shell. Also lets you avoid multiple startup
        overhead of dzil :-)

    CPANPLUS::Shell::Curses
        Author: MARCUS <https://metacpan.org/author/MARCUS>

        Unmaintained. Installs but no longer runs.

        Rating: 2/10

    Task::Mechanistic
        If you peek into its Makefile.PL, you'll see a seemingly
        random/heterogenous collection of modules to install (instead of
        just WWW::Mechanize). This is probably a Task::BeLike::$AUTHOR in
        disguise. <br><br>

    Sereal
        Author: YVES <https://metacpan.org/author/YVES>

        So far the best of the bunch. <br><br>FAST: much faster than
        Storable, roughly the same speed as (sometimes slightly faster than)
        Data::Clone for cloning. <br><br>FEATUREFUL: Can handle circular
        references, Regexp objects (trips out-of-the-box Storable),
        JSON::{PP,XS}::Boolean objects (trips Data::Clone). <br><br>COMPACT:
        definitely more compact (up to several times) than Storable.
        <br><br>I'm sold. What more do you want? Le Storable est mort, vive
        le Sereal!

    Test::Tester
        Author: EXODIST <https://metacpan.org/author/EXODIST>

        If you write test functions, you need this. It's like the
        &quot;Test::More&quot; for &quot;Test::More&quot;. However, it
        currently does not work out of the box with subtests (submitted as
        wishlist to RT). <br><br>PS: Thanks to Toby Inkster for pointing
        this module out. <br><br>

    Text::CharWidth
        Author: KUBOTA <https://metacpan.org/author/KUBOTA>

        It's faster than Unicode::GCString-&gt;new($str)-&gt;columns, but it
        gives wrong answers to lots of characters, e.g. control characters
        like &quot;\n&quot;, &quot;\t&quot;, etc are currently assumed to
        have width of -1 character. You're better off with
        Unicode::GCString.

        Rating: 2/10

    App::Options
        Author: SPADKINS <https://metacpan.org/author/SPADKINS>

README  view on Meta::CPAN

        Regexp::Common does gets removed).

    HTTP::Headers::Patch::DontUseStorable
        Author: PERLANCAR <https://metacpan.org/author/PERLANCAR>

        @zaxon: I'm not sure if it's a bug with HTTP::Headers, more like a
        workaround for Storable. See the FAQ in the updated v0.03 for more
        details. <br>

    Storable
        Author: NWCLARK <https://metacpan.org/author/NWCLARK>

        Balancing previous glowing reviews. Storable has it faults, for
        example historically its track record for file format backwards
        compatibility is poor, making programs fail when loading Storable
        files after the module is upgraded. <br><br>Also, more importantly,
        add builtin support for Regexp object already! It's almost 2013,
        Regexp object has been around for, what, more than a decade? I can
        understand not supporting serializing filehandle or coderef, but
        Regexp object?

        Rating: 2/10

    WWW::YouTube::Download
        Author: OALDERS <https://metacpan.org/author/OALDERS>

        Works for me too ATM. I've tried several command-line scripts (most
        of them Python-based, like youtube-dl, tubenick, etc). Sometimes
        they work, sometimes they broke. It's the nature of this kind of
        script. The quality comes from persistence. This module has been
        maintained since 2009, through several YouTube's changes. I commend
        the author, good job, and thanks!

    Number::Zero
        From the module's POD: &quot;The number zero and undef are difficult
        to determine in Perl.&quot; <br><br>Are they? <br><br>say
        !defined($data) ? &quot;undef&quot; : &quot;not undef&quot;;
        <br><br>say defined($data) &amp;&amp; $data==0 ? &quot;zero&quot; :
        &quot;not zero&quot;; # yes, warn if non-numeric <br><br>use
        Scalar::Util 'looks_like_number'; <br> say looks_like_number($data)
        &amp;&amp; $data==0 ? &quot;zero&quot; : &quot;not zero&quot;;
        <br><br>Though I understand the need for a convenient
        &quot;is_zero&quot; function if you need to test for zero in a
        program a lot.

    Syntax::SourceHighlight
        Author: MATLIB <https://metacpan.org/author/MATLIB>

        IMO, currently the only usable (read: non-crap) code syntax
        highlighting library on CPAN. Cons: you'll need to install GNU
        Source-highlight (and its development library/header) which pulls
        over 100MB of packages on my Debian. <br>

        Rating: 8/10

    Syntax::Highlight::Engine::Kate
        Author: MANWAR <https://metacpan.org/author/MANWAR>

        Highlighter engine doesn't seem updated (for example, defined-or is
        not yet interpreted correctly by this module but already correctly
        by Kate itself). Does not provide default theme (must specify all
        colors). Seem to be very slow (takes 1.5s for a 18K Perl .pm file
        while Pygments only takes 0.2s). <br><br>

        Rating: 2/10

    Syntax::Highlight::JSON
        Author: MART <https://metacpan.org/author/MART>

        No documentation. Combines formatting and syntax-highlighting, so
        you cannot preserve original formatting. Only outputs to HTML and no
        default &quot;theme&quot; (CSS) provided. <br>

        Rating: 2/10

    Syntax::Highlight::Engine::Simple
        Author: AKHUETTEL <https://metacpan.org/author/AKHUETTEL>

        Output looks decent. However, it currently only formats to HTML/CSS
        (no ANSI, LaTeX, etc). Also, it needs more languages support. <br>

        Rating: 6/10

    Syntax::Highlight::Universal
        Author: PALANT <https://metacpan.org/author/PALANT>

        Only targets (X)HTML (i.e. no alternative output like ANSI or
        LaTeX). Supposedly slow. But it doesn't matter because code no
        longer builds (last updated in 2005).

        Rating: 2/10

    text::highlight
        Outdated (no longer updated), poor capability (even for some simple
        Perl code, the output is atrocious), few languages supported. A far
        cry from Pygments or coderay.

        Rating: 2/10

    SemVer
        Author: DWHEELER <https://metacpan.org/author/DWHEELER>

        Good for semantic versioning scheme like 1.2.3 vs 1.2.3alpha vs
        1.2.3rc (1.2.3 should be the latest, not the alpha or rc). However,
        does not accept e.g. 1.0beta (at least three components are needed).
        Perhaps relax this requirement? <br><br>Also take a look at
        Debian::Dpkg::Version. <br>

    Sort::Versions
        Author: NEILB <https://metacpan.org/author/NEILB>

        Good for Perl-style versioning scheme (1.2.3) but does not work as
        people expect for semantic versioning scheme like 1.2.3 vs
        1.2.3alpha vs 1.2.3rc (1.2.3 should be the latest, not the alpha or
        rc). For handling the latter case, use SemVer. Also take a look at
        Debian::Dpkg::Version.

    App::Countdown
        Author: SHLOMIF <https://metacpan.org/author/SHLOMIF>

        Nice idea, though I'd probably just write a shell function for this.
        <br>

        Rating: 8/10

    Data::Compare
        Author: DCANTRELL <https://metacpan.org/author/DCANTRELL>

        Pros: handle hashes as well as arrays, handle nested and cyclic
        structure, plugins. <br><br>Cons: No cmp-like functionality
        (returning -1, 0, 1), slow (even slower than Array::Compare).
        <br><br>See also: Array::Compare, JSON/YAML/Storable. <br>

README  view on Meta::CPAN


    Locale::SubCountry
        Author: KIMRYAN <https://metacpan.org/author/KIMRYAN>

        UPDATE 2012-08-30: I am not sure if the module is now fully
        compliant to the new ISO 2007, but bug reports are certainly being
        responded and resolved now. Updating rating from 1-star to 4-star.
        Thanks, Kim. <br><br>2012-02-17: Review to version 1.47:
        <br><br>Sorry to have to rate with 1 star. I don't have problem with
        the interface/documentation. The 1-star rating is just to warn
        people that the data used by this module is not up to date. And that
        months-old bugs are not being fixed. <br><br>At the time of this
        writing, this module still uses ISO 3166-2:1998 (first edition) when
        it should be updated to ISO 3166-2:2007 (second edition) + all the
        newsletters (minor updates). For example, this module does not
        report 3 newer provinces in Indonesia. <br><br>Sadly we live in a
        world where countries and subcountries change all the time.
        <br><br>EDIT: Ok, so I was not being clear that I was not talking
        about my own bug report (posted at about the same time of this
        review). And bugs were certainly being resolved up to about 7 months
        ago. <br>

        Rating: 8/10

    Data::Rmap
        Author: BOWMANBS <https://metacpan.org/author/BOWMANBS>

        A very handy utility, sort of like s/// on your nested data
        structure instead of just strings. One nitpick: no coderef support.
        I needed to replace all coderefs inside a data structure into a
        string, since I want to pass it to JSON encoder. None of the
        rmap_*() functions seem to let me get to the coderefs. (RT wishlist
        ticket added.) <br><br>UPDATE 2011-12-30: The author (Brad) quickly
        responded to my RT ticket and added rmap_code. Upgrading from 4- to
        5-star :) Regexp support is not there yet though, and I have
        suggested the ability to get all kinds of Perl-specific and weird
        objects, because one of the main uses of Data::Rmap for me is to
        &quot;clean&quot; a data structure to pass to non-Perl systems. <br>

    Data::Properties::JSON
        Author: JOHND <https://metacpan.org/author/JOHND>

        The abstract for this module is a bit strange. What does this have
        to do with 'test fixtures'? Also the documentation doesn't say much,
        e.g. What will happen if a hash key contains funny characters (or
        arrays, etc)? <br><br>A similar module in spirit is Data::Hive. I
        think &quot;providing convenient chained method access to
        hierarchical data&quot; should be refactored out. So perhaps
        Data::Properties::{JSON,YAML,...} should just be a convenient
        shortcut for {JSON,YAML,...} parser + Data::Hive.

    Exporter::Auto
        Author: NEILB <https://metacpan.org/author/NEILB>

        I discourage module authors from exporting like this because it's
        simply too impolite/intrusive for module users. If the module author
        is lazy, there is already Exporter::NoWork which offers a few
        options for module users. This module, on the other hand, gives no
        control at all for users (so they'll have to resort to 'use Module
        ();'). <br><br>Let me remind all again by quoting from Exporter's
        POD: &quot;Do *not* export anything else by default without a good
        reason! Exports pollute the namespace of the module user.&quot;

    Net::Douban
        Interface to web services should be put under WWW::*, not Net::*

    HTML::Form::XSS
        Author: DUMB <https://metacpan.org/author/DUMB>

        Should probably be put under Test::*?

    Thread::IID
        Author: WROG <https://metacpan.org/author/WROG>

        When I saw the perlmonks thread yesterday, I thought &quot;well,
        someone should package it and put it on CPAN&quot;. And then someone
        did :) Thanks. <br>

    Test::Lite
        Author: BRADH <https://metacpan.org/author/BRADH>

        This is just a reimplementation of Test::More. But I thank the
        author for writing a short description of why this module is
        written, how it is different from others, and suggestion of what
        modules users should use. There are a lot of wheels being reinvented
        on CPAN, and that's okay, I just wish more people would document the
        reason.

    Sub::Mage
        Author: BRADH <https://metacpan.org/author/BRADH>

        Since the first release, there are 13 subsequent releases in total.
        What are the changes between releases? No idea, the author doesn't
        bother to update Changes (and no public repo is listed). Apparently
        all his other modules are also like this. Not very user-friendly.
        <br><br>UPDATE 2011-11-22: I see that this has been rectified by the
        author, there is now Changes entry for each new release. Cool,
        thanks. <br>

    relative_lib
        Documentation is placed in README.md, so it's inaccessible from
        perldoc et al. Why? This is not a Python library.

    CPAN::Mini::Webserver
        Author: MITHALDU <https://metacpan.org/author/MITHALDU>

        Just found out about it, despite having used CPAN::Mini for over a
        year. Helps *a lot*. More people should know this (e.g. mention from
        CPAN::Mini POD).

    Win32::App::which
        Author: DOLMEN <https://metacpan.org/author/DOLMEN>

        I don't use this module since I'm not on Windows. But why another
        module? File::Which also handles Win32 (probably not the &quot;the
        current directory is explored before PATH&quot; thing, but you
        should consider submitting a patch). <br><br>At least the
        documentation should state why this module is necessary. It
        complicates scripts by having to select between two 'which'
        implementations.

README  view on Meta::CPAN

        depend on Algorithm::Diff (or use the name 'diff', for that matter).
        <br>

    DZ1 Why do we need this uploaded to CPAN?

        Rating: 2/10

    Passwd::Unix
        Author: STRZELEC <https://metacpan.org/author/STRZELEC>

        No tests. No detailed error status, only true/false (yes, there is a
        'warnings' parameter on constructor, but this doesn't give out
        warnings on all operations, only some). No locking (although there
        is backup, but still). <br><br>Also, some weird choices, why use
        bzip2 when creating backup? Or, why still require running as root
        (checking $() if we are allowing custom database file location?
        <br><br>Between this and Unix::ConfigFile, I'm seriously considering
        using Unix commands instead (useradd, userdel, gpasswd, et al).
        <br><br>UPDATE 2011-04-21: I created a fork of Passwd::Unix 0.52
        called Passwd::Unix::Alt instead, which add some tests and
        modifications. Try it out if your needs are also not met by
        Passwd::Unix. <br><br>UPDATE 2012-08-30: I created a new module
        called Unix::Passwd::File. Try it out if your needs are also not met
        by Passwd::Unix.

        Rating: 2/10

    Unix::ConfigFile
        Author: SSNODGRA <https://metacpan.org/author/SSNODGRA>

        Outdated module that doesn't handle /etc/shadow and /etc/gshadow.

        Rating: 2/10

    lib::xi
        Author: GFUJI <https://metacpan.org/author/GFUJI>

        Handy module for installing dependencies. There are previous
        efforts, but the arrival of cpanm makes autoinstall process less
        tedious, so hats off also to the creator of cpanm. <br>

    Capture::Tiny::Extended
        Author: MITHALDU <https://metacpan.org/author/MITHALDU>

        Indispensable. Provides nice enhancement to Capture::Tiny
        (particularly the real-time teeing). <br>

    google_talk_bot
        Improperly packaged, improper POD formatting, bot messages hardcoded
        in script, and yes... idiotic license. Basically a &quot;trial&quot;
        script to bait users into consultation gig. CPAN is not a place for
        this kind of thing. Please try again. <br>

        Rating: 2/10

    Clone::Any
        Author: EVO <https://metacpan.org/author/EVO>

        Using Clone::Any nowadays is more trouble than it's worth.
        <br><br>First, there are annoying incompatibilities between cloning
        modules. Most notably Storable, which is the default cloning module
        if Clone is not available, *still* doesn't support storing Regexp
        objects out-of-the-box after all these years. <br><br>Second, this
        module has not been updated for a long time and newer alternatives
        like the fast Data::Clone is not recognized. <br><br>Right now I'm
        replacing all code from using Clone::Any code to Data::Clone.
        <br><br>

        Rating: 4/10

    Array::OrdHash
        Author: WOWASURIN <https://metacpan.org/author/WOWASURIN>

        Fun module to play with, especially for those among us infected with
        a bit of PHP envy (me, never!). <br>

    Bash::Completion
        Author: MELO <https://metacpan.org/author/MELO>

        Clean code, plugin interface simple to use, but implementation needs
        to be improved. For example, parsing $ENV{COMP_LINE} &amp;
        $ENV{COMP_POINT} into @argv is done simplistically using
        split(/\h+/), without regard to shell's quotes/escapes.
        (Getopt::Complete's way is somewhat better by invoking shell, but it
        also has its problems. I guess in this regard external programs are
        second-class citizens to shell functions because they don't get the
        equivalents of COMP_WORDS/COMP_CWORD). <br>

        Rating: 6/10

    Bash::Completion::Plugins::cpanm
        Author: PERLER <https://metacpan.org/author/PERLER>

        Cool, except that with cpanm I often install local distribution
        (cpanm Foo-Bar-1.23.tar.gz). Perhaps the completion can look in the
        filesystem first before firing API request. Also, might be nice if
        there is some caching because it seems to be slow (at least from
        where I am). <br>

        Rating: 8/10

    Switch
        Author: CHORNY <https://metacpan.org/author/CHORNY>

        With all due respect to the author, Switch is no longer necessary in
        5.10+ as 5.10+ already introduced smart matching and given().
        given() is superior because it doesn't introduce compile-time
        overhead, doesn't mess line numbers, and should be faster (simply
        because smart match is fast, and Switch is not utilizing it).
        <br><br>You have been using 5.10+, right? (Since 5.8 is no longer
        officially supported) <br>

    Moo Author: HAARG <https://metacpan.org/author/HAARG>

        Last week I ported an application from Mouse (Any::Moose) to Moo.
        Went without a hitch (well I did replace &quot;with 'X', 'Y',
        'Z';&quot; to &quot;with 'X'; with 'Y'; with 'Z';&quot; as
        instructed in the Moo documentation). Startup time decreased
        significantly. Planning to move every Moose apps to Moo. Splendid!
        <br>

README  view on Meta::CPAN

        along with that. It should also be in core to accompany File::Spec.

        Rating: 8/10

    File::Slurp
        Author: CAPOEIRAB <https://metacpan.org/author/CAPOEIRAB>

        I've been using File::Slurp for years and is generally satisfied
        with it. However reading the negative reviews today and looking at
        its RT queue, I realize that this module is broken for many and is
        effectively abandoned by the maintainer (no new releases for almost
        3 years now despite several RT items labeled as critical). So I
        suggest others checking out the alternatives.

        Rating: 2/10

    Log::Log4perl
        Author: ETJ <https://metacpan.org/author/ETJ>

        It's a very mature and an excellent logging framework. However, some
        of the common minor complaints are: 1) It's too complex. I agree: it
        should not be this hard to get started. 2) Configuration is too
        verbose. Agreed: but well, what can you do, most things from Java is
        a bit overengineered and verbose anyway. At least you can do almost
        anything with the configuration. 3) It's not very Perlish. Also
        agreed. 4) Performance. My note: speed is not an issue in majority
        of the cases and Log4perl's performance is adequate for most of the
        rest of the cases. For faster/leaner alternatives you might want to
        take a look at Log::Fast, but a lot of Log4perl's features are
        missing. <br><br>One of the main strengths of Log4perl is its
        sublogger/subcategory feature, which few other frameworks seem to
        have. <br><br>For other alternatives, also take a look at:
        Log::Handler, Log::Any. And of course Log::Message too. <br>

    Log::Handler
        Author: BLOONIX <https://metacpan.org/author/BLOONIX>

        This review mostly compares Log::Handler with Log4perl, which is a
        mature and one of the most popular logging frameworks. <br><br>I
        think Log::Handler's interface is much simpler, nicer, more Perlish
        than Log4perl. It's a bit similar to Log::Any::App, which I created
        just because I hate Log4perl configuration. <br><br>There is a
        unique concept of maxlevel not normally found in other frameworks,
        though it can be emulated in other frameworks using filters.
        <br><br>At a quick glance, the speed is around twice that of
        Log::Log4perl, so I'll say it's on the low-end side (there are other
        much faster logging modules, but anyway speed is not an issue to
        most people). <br><br>It currently lacks sublogger (hierarchical
        categorization and adjustable/automatic appending of subcategory to
        its parent), so it cannot be used to replace Log4perl in most cases
        as that's one of the main feature of Log4perl. Which is a pity
        because I would otherwise switch.

        Rating: 8/10

    Log::Fast
        Author: POWERMAN <https://metacpan.org/author/POWERMAN>

        This logging framework is also minimalistic: no
        categories/hierarchiecal loggers, no custom levels, no config file,
        or other whistles and bells. And the interface &amp; default levels
        are rather syslog-oriented. But it's fast alright. The POD doesn't
        mention a comparison to Log::Log4perl, but a casual benchmark shows
        that it's at least 10x faster. <br><br>So this module will certainly
        come handy if you have a performance critical application.
        <br><br>Btw, note that the benchmarks are done for actual logging to
        output. For log statements that do not actually get logged (e.g.
        because the level is below the desired output level), I don't find
        that extreme differences in overhead between logging frameworks. For
        example, on my Athlon64 X2 5600+ PC, Log::Fast's overhead is roughly
        around 3mils/sec, while Log::Log4perl is around 1,5mils/sec.

    Log::Minimal
        Author: KAZEBURO <https://metacpan.org/author/KAZEBURO>

        Log::Minimal's slogan is &quot;minimal but customizable&quot;. It's
        minimal alright, probably only suitable for simple scripts as the
        moment you organize your application/library into separate modules,
        you'll want/need categories instead of just level, which is not
        provided by Log::Minimal. <br><br>Also, only formats is
        customizable, there is currently no way to customize level. And the
        levels are &quot;not standard&quot; (not that there is an official
        authoritative standard, but the popular convention is
        TRACE/DEBUG/INFO/WARN/ERROR/FATAL and NONE). Log::Minimal's levels
        are <br> DEBUG/INFO/WARN/CRITICAL and NONE). Surely most people
        would expect another level between WARN and CRITICAL, for
        non-critical errors? But that is actually just a matter of taste.
        <br>

        Rating: 4/10

    Log::Fine
        Author: CFUHRMAN <https://metacpan.org/author/CFUHRMAN>

        Log::Fine is touted as a framework for those who &quot;need a
        fine-grained logging mechanism in their program(s)&quot;. But apart
        from the emphasis on custom levels, to me there is nothing extra
        fine-grained about it. The other thing it provides is
        categories/namespace, which is also supported by a lot of other
        frameworks. So I fail to see the benefit/uniqueness of Log::Fine.
        <br><br>Btw regarding custom levels, this practice is long
        deprecated by log4j (and thus also by Log4perl, although Log4perl
        can do custom levels). I can understand this decision as I sometimes
        already have trouble managing the popular convention of 6 levels
        (FATAL/ERROR/WARN/INFO/DEBUG/TRACE) as it is, much less with custom
        levels!

        Rating: 6/10

    Config::IniFiles
        Author: SHLOMIF <https://metacpan.org/author/SHLOMIF>

        This module has been developed for more than a decade and seen
        different maintainers over the years. The codebase is indeed showing
        these, with different capitalization and indentation styles, among
        other things. <br><br>However, among more than a dozen or so of INI
        modules in CPAN, ironically there seems to be few other choices if
        you go beyond the most basic feature set. Some INI modules can only
        simplistically rewrite/dump the whole INI structure and thus lose
        comments/orders, while others can't even write INI files.
        <br><br>Config::IniFiles by far offers the most options and
        features, like dealing with line continuation, case sensitivity,
        default section, multiline/array, deltas, etc. So for now, despite
        all of its quirks, this module is still hard to beat.
        <br><br>There's another nice little INI module that can do
        read/set/delete/unset (instead of just read/dump): Prima::IniFile,
        but it is included in a totally unrelated distribution.

        Rating: 8/10

    DateTime
        Author: DROLSKY <https://metacpan.org/author/DROLSKY>

        Amidst all the glowing reviews may I add a reminder that, as with
        everything, there's a catch: runtime performance. On my PC, the
        speed of creating a DateTime object is just around 6000/sec. If you
        use DateTime intensively, it can quickly add up. <br><br>Imagine
        serving a web page that fetches 50 rows from database, where for
        convenience you convert each date column to a DateTime object, and
        you have 120 requests/sec coming in... That's already 6000 objects
        (an extra second!). <br><br>Which is unfortunate because DateTime is
        so wonderful, convenient, correct, complete and all that. So one
        approach you can use might be to delay converting to DateTime object
        until necessary.

    Date::Manip
        Author: SBECK <https://metacpan.org/author/SBECK>

        Wow, there are surely a lot of negative reviews ... <br><br>First of
        all, Date::Manip has a long history. I used this module back in
        2001-2002, IIRC. Back then it was *the* swiss army of date/time
        manipulation, something you use when you want the most
        flexible/complete thing in Perl. True, it's slow, but it works.
        <br><br>But then things change. DateTime project was started, and
        now it is somewhat the de facto standard. It's more modern and far
        more modular than the monolithic Date::Manip (every timezone and
        language support and parsing/formatting modules shipped in one
        single distribution). <br><br>And then there's the 5.x -&gt; 6.x
        debacle. As someone who also sprinkle Perl 5.10 requirements to his
        CPAN modules, I can feel for the author. But the difference is, most
        of my modules are not that widely used/known, and also many start
        its life already requiring 5.10 right from its first released
        version. While in Date::Manip's case, this happens to a very widely
        used module. Surely backwards compatibility should be considered
        more. <br><br>All in all, you are free to use or not use
        Date::Manip. There are other alternatives. Pick wisely. <br>

        Rating: 6/10

    App::pmuninstall
        Author: XAICRON <https://metacpan.org/author/XAICRON>

        One would wonder why CPAN clients still don't have this crucial
        feature Though you see Miyagawa listed in the Credits so maybe
        cpanminus or its sister will end up having this functionality? One
        can only hope. At 0.06, some things are not working flawlessly
        (submitted in RT). Keep up the good work! <br><br>

    App::lntree
        Author: ROKR <https://metacpan.org/author/ROKR>

        I guess this app is still useful, since &quot;cp -sR&quot; still
        doesn't work as many would expect, and there are Windows users out



( run in 0.428 second using v1.01-cache-2.11-cpan-140bd7fdf52 )