Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Negative module recommendations

by zby (Vicar)
on Dec 10, 2005 at 14:51 UTC ( [id://515728]=perlmeditation: print w/replies, xml ) Need Help??

There are a few module recommendations, one of the most prominent is the The Perl Advent Calendar. And it is really usefull from time to time to find out new interesting modules. But still for most of the tasks I can find what I need using CPAN Search. With only one caveat, sometimes the modules I find are not the best quality, sometimes they have better replacements, but I just happened to find the worse alternative first. I would spare lots of time if I was warned about them. So here is my proposal for listing the modules that dissapointed you with reasons why.

I start with:

By the way for all that start to use Class::DBI it might be usefull to consider DBIx::Class instead. It is still a bit experimental, but it tries to be more general and cleaner replacement for Class::DBI.

2005-12-10 jdporter retitled

Replies are listed 'Best First'.
Re: Negative module recommendations
by valdez (Monsignor) on Dec 10, 2005 at 15:10 UTC
Re: Negative module recommendations
by hossman (Prior) on Dec 10, 2005 at 23:07 UTC
    But still for most of the tasks I can find what I need using CPAN Search. With only one caveat, sometimes the modules I find are not the best quality, sometimes they have better replacements, but I just happened to find the worse alternative first. I would spare lots of time if I was warned about them.

    If you really want to warn people using search.cpan.org away from using modules you are not fond, why don't you post your comments on http://cpanratings.perl.org/ ? ... the aggregate scores show up on http://search.cpan.org when viewing a distribtion.

      I have to agree that cpanratings is a better place for those negative recommendations. I just wanted to start here a bit more relaxed discussion about the problem and lead people to start giving such negative recommendations.
Re: Negative module recommendations
by Ovid (Cardinal) on Dec 10, 2005 at 23:59 UTC

    zby wrote:

    Data::Dumper::Simple - this is a nice module, but it uses source filters so it's correctness is much less sure than more traditional modules.

    You are absolutely correct that it uses a source filter. However, I not only state this clearly in the documentation, I also note that this module is for debugging. For that purpose, it's well-suited to its task. I have never recommended it for any other purpose.

    As an alternative, you can try my Data::Dumper::Names. This module does not use a source filter, it's much more limited and sometimes does not provide correct output. However, I've never received any clear bug reports which isolates the problem and since there's not much interest in it, I haven't really pursued it.

    Cheers,
    Ovid

    New address of my CGI Course.

      for the same goal, letting Data::Dumper dump out with the variable name, i wrote a little vi mapping:

      :imap dumper <ESC>^iwarn Data::Dumper->Dump([\<ESC>llyw$a], ['<ESC>pa']);<ESC>

      type in

      my @array = function(); @arraydumper
      and get
      my @array = function(); warn Data::Dumper->Dump([\@array], ['array']);

      i use this regularly, it's a real help for debugging.

      I did use Data::Dumper::Simple for debugging and it was breaking on my code. That consumed no less time than if I used it for other purposes. When you look for bugs in your code you'd rather rely on your debugging tools otherwise the whole operation becomes too chaotic. With due respect to all of your other CPAN modules I would not recommend this one.

        I guess it would have been nice if you'd have posted a bug report. I realise that sometimes time constraints don't allow for writing up a sensible bug report with all necessary information, but if you really like the module that would have been the way to go IMO.

        That's also my reaction to your OP, there are two good ways of constructively criticising a module. If you think it's irredeemably broken or ill conceived you can say so on cpanratings and give detailed reasons. Otherwise, if you think the module is good in principle but is lacking a feature or has a bug you can file a bug report/wishlist on RT and help the author improve it. Your notion of helping users pick the right module is a good one (and the wish of a more reliable quality rating for CPAN modules is often expressed), but ultimately it's more worthwhile to worry about the code rather than the "marketing" (used here in the loosest possible sense).


        Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
Re: Negative module recommendations
by chromatic (Archbishop) on Dec 10, 2005 at 21:37 UTC
    this is a nice module, but it uses source filters so it's correctness is much less sure than more traditional modules

    Why do you say that? Can you break it?

    I can think of cases where I can break the other two modules you mentioned (or they can break my code), but "It uses source filters" doesn't automatically indicate "low quality" or "not useful" or "don't use this in serious code" to me. I'm curious why it does to you.

      It did breake on my code. I cannot quote that code here, because I removed it after finding where the problem was, so you have only my word for that.
Re: Negative module recommendations
by sfink (Deacon) on Dec 11, 2005 at 23:49 UTC
    A simple "negative module recommendation" would be too simplistic to be useful, I think. It would be much more valuable to know why you don't care for a module.

    The problem is that nontrivial modules often need to balance multiple competing objectives: speed, scalability, robustness, battle hardening, simplicity of API, debuggability, flexibility, etc. (I'm intentionally only listing dimensions that have caused me to reject a module.) As a result, it's not always about good vs bad; sometimes, it's a matter of matching a module to your situation.

    So, for example, I write code for a variety of situations:

    • production code that I and others will be re-reading and maintaining for some time, some of which is for occasional tasks and some of which will be run repeatedly with huge amounts of aggregate data
    • support code that somebody else might read but mostly will be behind the scenes and maintained only by me
    • one-off programs to do simple maintenance or analysis operations on some short-lived input
    • experimental programs just to see if some idea or other will pan out
    That is certainly not an exhaustive list of scenarios, but it's still representative enough to demonstrate that a module that is perfect for one situation might be completely unsuitable for another. For example, there's nothing wrong with using regular expressions to parse HTML or XML if you're only using it on files with known formatting, or if you'll be able to figure out immediately if it gets it wrong. If another module uses a more robust parsing mechanism, then of course you would use that module instead -- unless it were slower, more complicated to use, or worse in some other way that mattered to you more for the task at hand.

    Which is not to say that I disagree with the whole idea of negative ratings, just that a blanket "this module sucks" is not likely to be as helpful as some additional information. Alternatives would be:

    • Rate the module on a whole range of dimensions
    • Record negative ratings, but require the rater to submit the reason or reasons
    • Restrict negative ratings to suggestions of alternatives, preferably with reasons why each alternative is superior
    In some cases, a blanket negative rating is appropriate, if there are better modules out there in all dimensions, or if the module has some fundamental flaw (eg incorrect behavior on common input) that would cause you to recommend never using the module in any circumstance.

    I work for Reactrix Systems, and am willing to admit it.
Re: Negative module recommendations
by belg4mit (Prior) on Dec 13, 2005 at 01:51 UTC
    While vetting things to write up for the calendar I often come across multiple symmetric objects which can allow an object riding on an axle mounted to the item to glide forward at a constant height (a wheel). And I often think about a giant matrix of related modules comparing feature sets, bugs etc. As potentially useful as it might be it'd be no easy task I tell you what. Consider a matrix of template modules, and how many toes you'd step on. *shudder*

    Of course I don't totally buy the "cream always floats to the top" argument either. If I did it'd be hard to work on the calendar. Somebody (or more likely many somebodys) has to "discover" the module in the first place.

    I would like to see more considered/extensive evaluations, heck more evaluations period, on ratings, anno etc. However I think this will continue to be difficult for many reasons, not the least of which is the disjointedness of search, anno ratings, rt and cpanforum (completely and totally seperate for no apparent reason). It'd be great to have a single master cookie for everything but PAUSE (and for RT, only allowing new ticket/comment operations, not full editing abilities) in *.cpan.org...

    UPDATE: I have it on good authority that the powers that be are in fact working on unifying the auth systems at this very moment.

    --
    In Bob We Trust, All Others Bring Data.

Re: Negative module recommendations
by simon.proctor (Vicar) on Dec 12, 2005 at 12:48 UTC
    While you may have a point your arguments do show why it is often difficult to have negative reps on modules. There are ratings, bug reports and documentation for a reason. After reading the docs and (where necessary) experimenting with the module you are in a position to decide whether it meets your needs.

    For example, your initial point:
    # Class::DBI::Pager - that module does not use 'LIMIT' clauses in the + database, there are better alternatives.
    I use SQL server. Additionally, a brief (very brief) scan of the alternatives - well one doesn't support Oracle or DB2. So I have to write my own limit syntax/code anyway. As my workplace uses those three DBs exclusively. No postgres and no mysql. Period.

    I'm not saying your criticism is not unfounded, but it doesn't help me as the syntax you complain about is not available to me regardless.

    Would it not be better to offer solutions to problems?

    Finally, you recommend an experimental module as part of your "review". Where I work, experimental code cannot go on a production system. Period.

    Just my 2p so please take in the same vein :).

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2024-03-28 14:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found