My question isn't which module to choose. It's about the process of choosing modules. Notice this was a Meditation and not a SoPW. That's on purpose. It's kind of a "meta" thing. It's a question about asking and answering questions about modules. Primarily, it's a question about how to answer more clearly and sooner in the module selection process.

I'm not at all sure that reading the complete documentation for every module that could possibly fit is the best way to get started. That's the whole point of my question. Is there a better, less time-consuming way?

Furthermore, is there some way that won't make CPAN so intimidating to new Perl programmers? Sure, most of us are used to the amount of choices, but do you ever notice people being turned off on Perl early because TIMTOWTDI runs a bit rampant? I've seen lots of frustration when people want to know how to do something -- anything, forget mail sending for a second -- and the response is more or less, "read the docs for these 5 modules and come back with questions about the one you choose".

Indeed, I think people who have been programming with Perl for several years don't generally take the sheer number of overlapping modules on CPAN into account. Certainly not the same way newcomers do. If you've been programming with Perl for a while, you tend to know which modules might fit and which ones are complete wastes of disk space. You recognize at least some of the names of module authors. A quicker glance at the docs or even at a CPAN search results page does much more for you because of your experience. For tasks you've already done, you probably already have experience with one or more modules and have your favorites for many classes of tasks. We'll never eliminate the advantages of experience, but we shouldn't take for granted that everyone will have it, either.

As for narrowing down the choices to the ones that fit someone's needs, that's exactly what I'm asking. I'm not asking for advice on which module to use. I'm asking how we, as a community, improve the experience of that process. Do we continue to just recommend modules based on lots of research by the people asking and interaction with them? Can we make a more accessible resource for people than "Ask the experts over there"?

Yes, MIME::Lite can use Net::SMTP. It can also pipe to sendmail. The point is that using MIME::Lite makes the mechanics of SMTP irrelevant, whereas you must understand those mechanics to use Net::SMTP directly. That makes them very different. The difference is akin to that between using mutt to read and write your mail, and using telnet to ports 110 and 25 and just talking POP and SMTP yourself like a Real Programmer would.

To answer your meditation - if you want to figure out which of those modules to use you *must* have some understanding of what you're trying to do, and what the modules do. The best way to do that is to consult something more knowledgeable than yourself. That something is generally the modules' documentation.

The answer you're probably not looking for to the question of "how on earth do I even find out which modules I should consider to do task FOO" is "ask other people".

I can type SMTP and POP3 into the ports. That's not even so much of a programmer's skill as a sysadmin's skill AFAICT. I'm not so good at decoding Base64-encoded MIME attachments in my head and visualizing the data as a picture or hearing it as a sound. An actual client helps with that.

As far as your problems with the hypothetical example, it's entirely possible instead of using MIME::Lite to use another MIME module and to use Net::SMTP. Someone who's using MIME in a project for more than just sending mail but also has to have it send mail would probably not end up using a specialized MIME email sending module and other specialized MIME modules. They'd probably use a more general MIME module and a general mail-sending module.

Just because someone is looking for modules to do something and hasn't settled on one doesn't mean they have issues with the concepts they are trying to use. Throwing around phrases like "real programmer", saying they'd do this low-level thing and by extension that if you do something a bit higher-level you're not really a "real programmer" just lowers the tone of the conversation, IMO. If your precise need is to send MIME-encoded email, MIME::Lite is probably the quickest way to write you application. A "real programmer" should be able to use that. If you're sending email that's not MIME-encoded, it'd be silly to overlook the core Net::SMTP and download a MIME-encoding wrapper around it.

BTW, MIME::Lite doesn't really make the mechanics of SMTP irrelevant. It just hides them until something breaks, like not having sendmail installed or having a port blocked. If you don't understand the system outside your program, you're not likely to be able to get any program that interacts with the system to work properly.

Actually, the best way I've found to get a list of modules to consider is CPAN. In fact, if someone asks on here the general question of which to consider, the monks invariably mention the person could have made a short list from a CPAN search and asked more specific questions about the modules on that list. Usually this is along with more direct advice, but I think the search really is a good place to start.

For understanding what the modules do, would it be unhelpful to have a list of what modules in a certain application area do side by side for comparison? Sure, reading the docs is usually necessary to use the module. Why wouldn't it be nice to only read the docs of the modules that have the features you need?