|
RE: Perl Module evaluation mechanism
by davorg (Chancellor) on Aug 31, 2000 at 18:40 UTC
|
This is a problem that I've seen discussed in many places
recently. Graham Barr's CPAN BOF at TPC4 seemed to be
almost all about ways to quality check CPAN modules.
More recently, there has been talk about this subject
on a number of the Perl 6 mailing lists - in particular on
the perl-qa and perl6-stdlib lists. See http://dev.perl.org/lists
for subscription details and archives.
--
<http://www.dave.org.uk>
European Perl Conference - Sept 22/24 2000, ICA, London
<http://www.yapc.org/Europe/>
| [reply] |
|
|
You are right, it looks like the Perl6 people (or at least
the kwalitee guy!) plan something like this:
CPANTS
Now will we have to wait until perl 6 to have such a system
or could we create something similar, maybe more informal,
for cheap, which will work tomorrow and not next year and which
might also give useful feedback to the real CPANTS developers?
| [reply] |
|
|
the perl-qa list doesn't have 6 in it for good reason, it is intended that work on this doesn't have to wait for perl6. I believe that work on CPANTS can start anytime. So hopefully we don't have to wait for Perl 6 at all :-)
Nuance
| [reply] |
RE: Perl Module evaluation mechanism
by ZZamboni (Curate) on Sep 01, 2000 at 04:25 UTC
|
I think that an area where people could indicate whether they use a module, how happy they are with it, put links to code
that use it and generally any kind of information...
That is the intended purpose of the Reviews section, but so
far it seems to contain only book reviews. I'm sure if enough
people start submitting module reviews, vroom would open a
new section.
--ZZamboni
| [reply] |
|
|
Looks like a good idea, so I posted reviews of a bunch
of XML modules. Of course they don't appear anywhere yet,
but you can see them
here.
Comments, corrections, different opinions welcome
| [reply] |
RE: Perl Module evaluation mechanism
by gaspodethewonderdog (Monk) on Aug 31, 2000 at 17:24 UTC
|
Well most of the <Module>::Simple are not industrial strength modules. They are the lite version that you can use... a lot of default assumptions are made to make your life easier.
On the other hand if you think you are going to be doing a lot of specific things or you need a high level of control then you want to look at the higher grade modules. Unfortunately when given a choice between two or more very similar looking modules it is hard to make a choice and there often isn't enough documentation provided to make a good decision.
Keeping that in mind I would suggest checking the news groups or see if the person who wrote the module has a website up so you can see what they have done, what state the code is in and such. Often looking at the logs of what has been fixed can give you a good idea if you want to use the module or not. If it looks like a lot of fixing is being done on fundamental routines you may want to stay away, if however fixes are being done that are mostly trivial then the code is probably about as ready as you need it.
Much beyond that yes it is very difficult to get up to speed on the different modules and really the only way to figure out what is best for you is to play aroud with them yourself, ask somebody you trust, or find a place where you can research it.
We've all got this problem, well except for maybe some of the Perl gurus, but even then there are just so many modules I'm not sure they know the state of "all" modules. Good luck in making an educated guess :) | [reply] |
|
|
Actually XML::Simple is pretty good, and powerful enough for
a wide category of problems.
Which shows that you would probably have been wrong here.
This is why I really think a place where users can report
on modules, link to similar modules, write why they choose the
module and so on would help tremendously.
Even indicating why you DIDN'T choose a module, or why, after
evaluating it you rejected it would help authors to improve
them.
Plus maintaining a module is quite a burden and if nobody uses
it or if there is a better one out there the author can
decide to give up on the module and notify users. I know
of more than a couple of modules on CPAN that are not maintained
and that will never be of much use for anybody. The problem
is that they take up 2 lines in the directory listing, just
like CGI.pm
| [reply] |
|
|
hehe... that's why I avoided commenting on XML in particular because I don't know ;).
But from experience LWP::Simple and others have been... well simplified versions of the other versions. You could certainly build web spiders/robots with LWP::Simple, but there are a lot of conventions that aren't taken into account and you would have to implement yourself.
A module 'accounting' repository would be great. It would be nice to know which modules are maintained and not... who used which for what reason... all that. Maybe the powers that be will decide to implement that feature some day :)
| [reply] |
RE: Perl Module evaluation mechanism
by gregorovius (Friar) on Sep 01, 2000 at 01:16 UTC
|
I had been wondering about the same problem for the past two days. Thinking about starting this at PerlMonks, could we maybe have a big module poll section, in which monks would mark the modules they've used, from the total of modules available at CPAN? This could be useful in many ways:
1. Would allow us to find out about popular modules we haven't used.
2. Would be a good aid for the people in charge of selecting modules for the standard distribution.
3. Could be a good indicator of the robustness of a given module, since more users usually mean more feeedback for developers and more bugs fixed.
On the downside number 3 could become a band wagon maker, discouraging use of new and potentially better modules.
We could also have a PerlMonks node for each CPAN module, for people to comment on their usage, much like in the Q&A section. What do you guys think?
Greg | [reply] |