It seems there are plenty of criteria to balance. Speed, clarity, reliability, documentation, examples, tutorials, opportunities for outside help, compatibility/platform concerns, frequency of module updates, core/non-core, portability, similarity in calling style to the rest of a project, and conceptual integrity are surely an incomplete list.
In the specific example of SMTP mail sending modules using the SMTP protocol or piping through something like sendmail, there are several. I tend to use Net::SMTP or Net::SMTP::TLS for my outgoing mail, and I have no problems. Mail::Mailer might be a perfectly good module, but I, personally, have never seen much code using it nor much documentation on it outside what comes with it. Other modules seem to get many more mentions I haven't done a comprehensive survey nor gathered many statistics, but I do have some basic comparisons using basic tools for three mentioned in the inspiring thread.
| Net::SMTP | Mail::Mailer | MIME::Lite | |
|---|---|---|---|
| # results Google's Code Search 1 | 7000 | 2000 | 3000 |
| search of perlmonks.org using Google shows | 567 | 199 | 1040 |
| regular Google search for "<Namespace>/<Module>.pm" 2 | 3060 | 1760 | 2230 |
| Ratings on 3 | 5 | 2.5 | 4.5 |
| Has a Reviews entry on Perlmonks? | no | no | yes |
| core module? 4 | yes | no | no |
1 Yes, Google reports these overly round numbers for its code search feature
2 because colons in phrases and Google are apparently not on speaking terms
3 The voting samples are entirely too small for this to mean too much.
4 Checked against 5.8.8 and 5.9.5
A big difference in mentions could make a difference in getting up to speed with a module quickly, but it doesn't seem like Mail::Mailer is exactly hurting for examples or discussion. The other options just have even more.
I've always been able to kind of muddle through picking a module and weighing these things in a kind of ad-hoc fashion in my own mind. I often download more than one module and try them briefly. Sometimes I still end up porting a project from one module to another after some growth or specification changes.
I'm still left wondering if there's a better or more accepted way to determine which module to use up front. Choice is good, but is there some set of criteria people weigh and compare that can give someone a bit more confidence in their choices? Experience is good, but is there a good way to pass experience with module choices on to others?
The reviews and ratings systems would appear to help, but they aren't as complete as they could be. They could also overlook a specific detail about a project that calls for a less popular module that supports a certain project's needs better. Does the best advice really come down to reading the full docs of each module in question and asking the community which is best for a given task?
Is there a resource out there that has a checklist comparison for the major modules in any given application area? If there is, we could use it as a model to do so for more areas. That way when modules focus on different parts of a task, a programmer could see more quickly which module might meet the specific needs of a project. Some generic data could be core/non-core, stable/non, OO/procedural interface, depends on other modules?, depends on other applications?, actively developed?, uses XS?, and maybe more. Then, features important to the application area could be noted.
Are any of these ideas worthwhile, or should I just stick to muddling through ad-hoc comparisons?
In reply to How does one choose among modules? by mr_mischief
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |