In the end, any form of certification just consists of a bunch of people who say that a module is worthwhile. You then must consider on what grounds you trust these people. Are they from the hypothetical CPANTS effort (which doesn't seem to have developed much recently)? Are they Perl Monks? Are there a whole bunch of them that use their numbers to suggest that bad ideas have limited acceptance? What is the compelling reason to trust this sanctifier as a second for the module author whose motives you question? The sanctifier becomes as tainted (in the -T sense) as the module author s/he's covering for, unless either the sanctifying process or the new person generates greater trust than the author alone (the process is a good regex, or else the person is? the example falls apart a little).

I suspect that for the paranoid, this exercise will offer little reassurance, and for those inclined to trust, the word of someone trustworthy (be it the Monk who recommends the module, the respected book author who promotes it, or a friend who uses it) will suffice. It was established in other threads that neccessity requires us to use technologies we don't fully comprehend.

I consider keeping track of the modules that work to be a bit akin to a bugtraq list of the exploits that were attempted and failed. Your idea of noting modules to be wary of, on the other hand, is far more interesting...

Well my idea is mostly a response to what I've seen here and once before on Usenet. People walking in and saying "Well how do you know that module is any good? I know _my_ CGI stuff does what I want..." Or they say, "For all you know it might have a `rm -rf` in it some where...."

I really just wanted to mark down the modules we all generally agree are above suspicion and put them some place fairly easy to link to. That way the next time some one asks why we all trust CGI you can send em to a page that lists 8 of us that have dug through it and asked Lincoln questions about it in person.

The last thing I want to do is present these bozos with a list of excuses why not to use modules when they want my help rewriting ReadParse to handle multiple selects.

In the end, any form of certification just consists of a bunch of people who say that a module is worthwhile. You then must consider on what grounds you trust these people.
Exactly correct. Now that they have come to us for advice, they are extending SOME trust to us so we offer them a list of the modules we trust.

I see presenting a list of the best that the perl community has to offer as a positive step. I see building a list of the bad ones as divisive and mean-spirited. In no way did I wish to be associated with that. I'd rather we stay at no lists at all than have an official "icky" list floating around.

--
$you = new YOU;
honk() if $you->love(perl)

From what I've noticed about such posts, the authors usually don't want to take our advice. Those who won't be swayed by a list of reasons to use a given module are probably unlikely to be swayed by the fact that monks J, K and L have given it the quality seal of approval. I, on the other hand, might well be swayed if I've developed some respect for those monks. For that reason I viewed this more as a resource for those who have already used the site to some degree and established feelings about how trustworthy the reviewer is.

What type of list is more useful depends on the prospective user's starting point. The person you described does need to be approached with reasons to use a particular module; I think there are certainly far worse things you could do with your time than to compile a list of reasons from all the replies on previous instances of the subject, which would give a convient place for us to point to the next time the topic came up.

If, on the other hand, your desired audience is people who already frequent the site and who are inclined not to re-invent wheels (without good reason), then a list of poorly-written modules is more valuable than a list of good ones. When I have to do something I've never attempted to do before, I tend to look to see if there are any modules which might help me. If I find them, I am inclined to assume they work and initially believe that any problems I have are caused by my own lack of understanding. I expect the module to work as advertised, so I am unhappy to discover when one does not.

To me it is not mean-spirited but helpful to be warned about potential problems. If we lack the ability to say anything bad about something that truely is bad, then we appear either blind or corrupt, and either way we do users a disservice by keeping knowledge from them.

After further thought, I suppose the idea I want to question is the list itself more than the good or bad list. Unless the list is a summary of a discussion of the module, I think its use is limited. If lots of people are saying a module is bad, I want to know why. Likewise, I imagine the person who has just hand-rolled some code wants reasons why the standard module is better, not a list of 8 people (whom s/he doesn't know) who say so. The question you mention ('...how do you know that module is any good') is perhaps better answered with 'this is why' than 'this is who says so'.

I don't mean to discourage some sort of rating system. I think the idea of maintaining some standard evaluation is very important. I just think that only a list, just like only a mention of benefits, shortchanges those who would benefit from the review.

Maybe you could add links from each module you list to the appropriate module review where approving or disapproving monks could state their feelings in more detail?

I would definitely add a few. In particular Inline, File::Temp, URI::Find, Memoize, Tk and so on. (I am not sure that I dare give a complete list of the ones I am familiar with - there are so many that I am not.)

Also I would recommend that while the Math::BigInt and so on are fun, if you really need the functionality it is probably worthwhile to go looking for things like Math::BigIntFast.

Here is my list:

• I would recommend Roman.pm, although it has no Makefile.PL, no tests and does not run under strict. I wrote all of those and I am sending them to the author. But the fact is that he module is simple, works fine and probably does not need test or strict.
• XML::PYX: a simple XML module written by Matt Sergeant It is simple enough that I don't think there are too many bugs in the code.
• I haven't reviewed the code of Text::Template but I kinda trust Dominus not to release crappy stuff, and I have been using the module for years without a problem (except for the Perl bug that produces a warning on older versions of Perl).
• and of course you can add a '!' after XML::Twig, although it does not give any indication about the quality of the module, apart from indicating that the author is still alive and active in the Perl community.

I would also remove XML::Parser::Expat from the list as it should not be called directly but rather through XML::Parser.

While on the subject of XML don't forget Enno Dirksen's XML::DOM. The XML's Document Object Model (DOM) is a standard way of interfacing with XML. It varies little from Perl to Java to C++.

XML::Twig is a simplified and more efficient way of interfacing with the XML::Parser, and is written by our own mirod. It is better than XML::DOM for many uses. However, an advantage of learning to use XML::DOM is that one's knowledge of the DOM is transferable to other languages which also use XML's DOM.

I cannot really recommend XML::DOM at this time.

It might be standard, robust and widely used, but it is not supported anymore (Enno seems to have disappeared from the surface of the Earth) and it is difficult to install, as the latest version is hidden in a bundle (libxml-enno), and has not been updated to be compatible with XML::Parser.

This could improve in the near future as it looks like someone has volonteered to take over its maintenance (although destroying compatibility with older versions of XML::Parser in the process).

Beyond the hopefully temporary lack of support, XML::DOM is not only ugly, I also think it is dangerous. The level of the API is so low that using the DOM directly results in code that can be broken really easily.

A good example is that you cannot go simply from an element node to the next one. If there is a comment before the element you want the getNextSibling method will happily return it to you. Of course it is easy to write a getNextElement method, and even to add an extra parameter so you can specify the tag of the element you want, but then you end up using a non-standard API and, from the examples I see floating around the web, I don't think too many people go through that trouble. I am fairly sure that most DOM code that does not use an extra (non-standard) layer of methods on top of the standard ones are vulnerable to inserting (legal) XML comments in the documents.

The fact that the only practical way to access elements is the getElementsByTagName also means that it is used everywhere in a DOM program, despite being really inefficient.

I have not used XML::XPath but I would think that it is better designed than the DOM, better supported than XML::DOM, and more efficient as it now uses a C library for managing nodes.