The overall fear of using non-core modules by Perl novices doesn't completely surprise me, after all, it can be intimidating learning to install one for the first time, and figuring out its interface. And those people who haven't tried just don't know how easy it often is, what they're missing and how much of a time savings it can be, not to mention the benefit in robustness brought by using one of the more popular modules that has withstood the refining fires of common use and frequent update.
But what really baffles me is how one can scoff at the use of a core module. A C programmer almost instinctively puts
#include stdio.h
#include stdlib.h
...at the top of his program (except where he doesn't need them). Sure, one can write a custom made standard input/output library for C, but the one that comes with C is ubiquitously used, and seldom shunned just on the basis of "not wanting to use any libraries".
Perl handles standard input and output internally, without the inclusion of a separate module. But there are many modules included with Perl that help to make a programmer's life easier, just as stdio and stdlib save C programmers from having to re-write their own input/output and common-tools libraries over and over again, possibly in non-standard ways, for no good reason. Text::Balanced, CGI.pm (for CGI, unrelated to this question), and many other of the Core modules come to mind as being fantastic resources included with every complete distribution of Perl.
My personal feeling is that if you choose to not use those modules, you should do so only if you know that the module doesn't contribute what you need. In that case, you would do as a C programmer might do who needs a different behavior than stdio provides; reinvent a wheel. Or more appropriately, you might at that point scan CPAN to see if someone else has already tackled that project and invented a good solution for you.
Dave
"If I had my life to live over again, I'd be a plumber." -- Albert Einstein
| [reply] [Watch: Dir/Any] [d/l] |