RE: Perl Module evaluation mechanism

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 :)

Comment on RE: Perl Module evaluation mechanism

Replies are listed 'Best First'.
RE: RE: Perl Module evaluation mechanism by mirod (Canon) on Aug 31, 2000 at 17:48 UTC
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]
RE: RE: RE: Perl Module evaluation mechanism by gaspodethewonderdog (Monk) on Aug 31, 2000 at 19:29 UTC
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]


Perl: the Markov chain saw
	PerlMonks