Re: How to choose the right module
by BioLion (Curate) on Oct 20, 2009 at 12:07 UTC
|
Obviously it depends on what the application is but in general :
- Choose modules that are highly rated on cpan ( http://search.cpan.org/~mjd/Memoize-1.01/ )
- Choose ones that have been recently updated, or are in higher versions, as they generally are better maintained and more developed ( http://search.cpan.org/~gfuji/Data-Util-0.53/ )
- If you can use modules which have been assimilated into the core release, this is often good too, because they are stable and well tested ( File::Basename )
- Look around - are people here using them ( Super search )? What do they say?
(If you have a more specific request, and a particular module doesn't rock your world, tell us why, ask us of there is a solution, maybe someone will know a better module...)
- Mainly though, play around!
- find what suits your style
- what gets the job done ( Test )?
- What gets it done fastest ( Benchmark ) ?
Just a something something...
| [reply] |
|
Choose ones that have been recently updated, or are in higher versions, as they generally are better maintained and more developed
That's quite a bold statement. Lots of activity may also be a sign of a high bug rate, or creature feep. "High" versions numbers are an even less useful indication. Is PHP an on par choice to Perl because both have (major) version number 5? Will PHP become a better choice if they declare their 6.0 to be ready before Perl does?
If you can use modules which have been assimilated into the core release, this is often good too, because they are stable and well tested
So you hope. That's only true for part of the modules in the core. Many "core" modules are "dual released" - the modules are found on CPAN, maintained (or not...) by someone other than p5p, and are just synced with the latest CPAN version before a Perl release. Inclusion in the core doesn't mean more than that someone in the past thought it was a good idea. And once there, it'll be there forever. Witness modules like CGI and Text::Soundex.
| [reply] |
|
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
As others have said, the version numbers or age of last release can be misleading. I'd suggest you look at the RT via search.cpan.com and see whether there are long unattended bug reports (bad) and whether there are any closed bug reports. If there are no, either it had always been so good that there was no need or no one uses the module. Hard to say which.
I would also place the "Look around" quite a bit higher in the list. The ratings are not used enough to actually be a good indicator of module quality.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
Re: How to choose the right module
by ww (Archbishop) on Oct 20, 2009 at 12:15 UTC
|
- Read the documentation for each candidate module using perldoc or by browsing CPAN.
- Decide which have the minimum capabilities you need
- Select the one which fits your needs and which you find easiest to grok
| [reply] [d/l] |
Re: How to choose the right module
by jethro (Monsignor) on Oct 20, 2009 at 12:16 UTC
|
There is no rating service that I know of, but there are lots of deciding factors you can use:
Is it still maintained? Good indicator is if there was a new version in the last year (don't depend on it, some old modules are so "finished" that there is no need for a new version)
Is there talk about it? Search perlmonks if it is mentioned in any threads. Often the thread tells you of alternatives and which is the best mod to use in most cases
Which one has the features and interface you want? Often modules are all of high quality, just for slighty different needs or tastes
If that still doesn't decide it, look at the source package. Does it use warnings and strict? Has it lots of tests? The number of tests and whether they fail on lots of platforms can also be looked up at http://static.cpantesters.org/
| [reply] |
|
| [reply] |
Re: How to choose the right module
by Bloodnok (Vicar) on Oct 20, 2009 at 12:11 UTC
|
To ask which CPAN module is best (for a particular use) is not unlike asking which car/TV/<insert consumable(s) here> is best ... since it is, IMO, a very subjective decision.
I would submit that all we monks can do is point out the pitfalls &/or benefits of using particular modules in order to allow you to arrive at a/the decision for yourself - that being said, ultimately the decision should be based on whichever module you feel most comfortable with from the POV of usage, feature(s)/functionality & documentation.
A user level that continues to overstate my experience :-))
| [reply] |
Re: How to choose the right module
by biohisham (Priest) on Oct 20, 2009 at 13:35 UTC
|
Added to all of that, I think a module that has enough examples in it, that projects different scenarios for these examples and one that has an active mailing list, IRC channels or any other mode interactivity can be better to work with judged by the accessibility to these examples and how they can be employed to fit your need and also for the fact that an interaction is taking place between you and the maintainers.
I am relatively new to modules myself so what I do is I identify my situational requirements, zero-in two or more modules potentially capable of doing the same and I ask the more experienced monks about the pros and cons for each one of these modules then make an informed decision on which one to pick for the job at hand. Crucial to tell you "Make sure you've an overview of the modules you intend to ask about - as stated by replies to your post - and that you understand what you are asking in case you needed a consultation on the best track to follow".
Wishing you a nice Perl Journey..
update: embodied the advice from stvn too, ++stvn :)
Excellence is an Endeavor of Persistence.
Chance Favors a Prepared Mind.
| [reply] [d/l] |
|
Excellent advice, I would like to just add/clarify one point.
... and one that has an active mailing list ...
Not all active modules have mailing lists, many module communities are more active on IRC and less so on the mailing list (Moose is a perfect example of this, the mailing list is pretty low traffic but we have 200+ people in the IRC channel at any given time).
And of course there are several active authors who don't like mailing lists or IRC and prefer that people just contact them directly.
| [reply] |
|
I adore you, stvn, and this isn't directed at Moose in particular. Just a good example and timing. I want to go on the record (probably should have saved this for a meditation) with this idea: IRC Considered Harmful.
IRCs are knowledge holes even when they are archived and searchable which many (most?) are not. The signal to noise ratio is too high to make them fun or effective to search even when you can; bad answers mixed with good; hacks mixed with best practice; sigils and stopwords galore. Too much intrinsic context; not stateful.
Excellent or important answers and clarifications happen in them all the time without being recorded or refined into a form which would be valuable to more than the two or three users paying attention. IRCs are anti-DRY.
IRCs also nurture clique behavior which can be discouraging to outsiders and would-be contributors even when genial and when it's not friendly it's easy to get away with being a jerk in a chat; it's familiar to the regulars and ephemeral. It's very difficult to get away with it on a mailing list; you often get dogpiled when you try.
I know I'd love to hang around with you personally. I am sad for all the things about MOP or Kioku or DBIC or ... which have zipped through the IRCs without landing in the right™ and "permanent" places: the documentation and tutorials (personal, community, or distributed with the code).
(Sidebar: I will buy you drinks if you're ever in my town. Then we can plumb some real knowledge holes.)
| [reply] |
|
|