Indeed sometimes using a module is overkill. However in a lot more cases, _not_ using a module is dangerous. I'll take overkill over bugs any time.

Some tasks look deceiptively simple. Parsing CGI parameters, CSV data, or XML (of course!) for example are all tasks that might look simple, but really aren't, and you are much better of using a well tested module than rolling your own code. Using modules also cuts down on development (and question-answering!) time, so why shouldn't we advocate it?

Finally, if installing a module is a problem for a newcomer, in the long (and even short) term, then helping them overcome that fear is doing them an even better service than solving their immediate problem.

That said, feel free to spend the time answering questions qith just core modules if you feel like it ;--)

Some tasks look deceiptively simple. Parsing CGI parameters, CSV data, or XML (of course!) for example are all tasks that might look simple, but really aren't, and you are much better of using a well tested module than rolling your own code. Using modules also cuts down on development (and question-answering!) time, so why shouldn't we advocate it?

I think what pbeckingham is advocating is merely that people should give more thought to suggesting simple solutions using core modules, before recommending alternate, possibly simpler, approaches that require installing newer less standard modules.

Parsing CGI parameters is a great example. We should suggest using good modules that we think provide a benefit, but let's not put the cart before the horse. Suggest use CGI first, and then if you have a particular affinity to an non standard module that you think mkes things even easier (CGI::Simple for example) then by all means suggest it.

Another great example is when people post questions asking for "A regex that matches _______". I agree that suggesting they install Regex::Common and use it is a great idea, explaining how that way they are constantly getting tweaks, improvements, and additions from the rest of hte perl community -- but there's no reason we can't also post a particular regex from that module which meets their needs, and explain how it works so they can learn to write their own regexes.

There is a delicate balance between teaching someone how to solve their own problems, and showing them how to utilize the work of others so they don't have to solve every problem on their own. We should all try to remember to do both with equal fervor.

CPAN is what makes Perl worth using, plain and simple. If it weren't for CPAN, why not use Ruby or Python? Why not Guile or TCL? Sure, Perl is a nice language but there are lots of nice languages. But just try programming in one of them someday and the thing you'll miss first and last is the power and depth of CPAN.

Beginners should be taught to look for solutions on CPAN as soon as they learn to use modules. In my opinion Perl should come with just a handful of modules and CPAN.pm.

-sam

From the title I thought I was going to read a node about the absurd growth of the Perl Standard Library. The smile slid from my face when I realized this is actually a node about not preaching the power of CPAN every day.

Actually, maybe it's just me but I don't think the perl standard library is a) very standard, or b) very comprehensive.

Re: a) - please link me to the description of the Perl Standard Library. I'm not being flippant - it definitely seems like a good thing, I just don't know where it is. ActiveState for Windows is different from ActiveState for Solaris is different (obviously) from the Sun distribution which is different from the distribution you build yourself from source which, of course, is different from the Windows distribution that you could build yourself.

Re: b) - The Standard Library (which I concede must be out there somewhere) seems to be missing some basic internet functionality. I'm not talking about the ActiveState distribution. Seems like LWP::Simple ought to be standard but is not (from my solaris builds, anyhow). XMLRPC or SOAP ought to be. For crying out loud, even just XML::Simple or XML::Parser (which, again, in my experience has not been part of the "standard" distribution).

Finally, in general, a lot of the responses in this thread seem to apply to a local/single distribution. In a corporate environment, adding modules (even if the basic process of building the module is no problem) can be a challenge administratively, logistically, and networkily.

My mileage may vary, but that's what I've been getting recently!

-- Andy

The only real standard Perl library is what you get from the perl source releases.

a) if the module is sloppy or not cool enough, and I could do better (rare)
b) if the module takes more than one CPAN command with dependancy scanning to install (frequent! Tk::Zinc as of late)
c) if I think the module is changing interfaces too fast or is otherwise unstable (frequent)
d) if the module is really really heavy for what I want to do and may cause maintaince problems due to the amount of new stuff I need to grok and remember (aka PAR) (frequent)
e) if I need to redistribute the script to a bunch of folks with just perl installed by default, PAR isn't good enough or makes too large of a binary, and the audience isn't Perl-educated enough to use CPAN (very frequent) -- this happens a lot when I'm writing quicky scripts that are little more than shell scripts, module use causes problems for those I need to give the script too, but Perl is still better than shell.

For my own coding, I use (good) modules all of the time. But there are plenty of situations when I can't use them, just like I feel I can't use any random C library I find on the internet -- it has to be stable, good, and easy for other people to compile/use, with a decent user base. This isn't exclusively a perl problem.

I think that addresses the portability issue.

... does not require our new-comer to jump right in and start installing modules - a known difficulty for many at first.

What difficulties? What issues? This is an assertion which flies in the face of accepted knowledge without any supporting statements. On every Unix-like system, the following works quite nicely:

foo% perl -MCPAN -e shell
cpan> install X
cpan> exit
[download]

With ActivePerl, you have the following:

C:\Perl\bin> ppm
ppm> install X
ppm> exit
[download]

You are correct in one respect - there are often a multitude of solutions on CPAN for a given problem. Many are incomplete or tailored to a specific need. Many are buggy and/or no longer supported. Navigating that successfully is only done with experience - the experience that is found at the Monastery, among other places.

Remember - the goal of asking a question is not to get the answer. It's to learn how to get the answer. Sometimes, it's even to learn what question to ask. Focusing on the task at hand is a good way to never achieve independence. It can be dizzingly confusing at times, but it is the only way to true enlightenment.

Very rarely do modules fail to install.

Not true on my planet. I'm astonished at how often even simple modules fail to install (for me and for others). I'm staggered at how much effort and code has gone into addressing the installation of modules -- and yet most resulting systems that I've tried fail about as often as they succeed and even the most reliable (perl Makefile.PL + make) fails all too often. And I'm astounded at how quite a few complex modules can be nearly impossible to install.

Maybe your view on this is because you've been blessed with exceptionally "vanilla" systems (just a wild guess).

I avoid non-standard Perl modules much of the time, in part because even when I can get a module to install, I very often find that it is unsuitable. There's lots of great stuff on CPAN and even more good, useful stuff on CPAN, and tons more stuff further down that end of the quality scale.

A total refusal to use modules is an all-too-common situation and I find it unacceptable. But I often avoid non-standard modules and I appreciate it when others realize there is a price for using a non-standard module and that sometimes the benefit doesn't out-weight that price. Perhaps you've already downloaded and installed the module (and maybe didn't have any problems doing that) and have read the documentation and figured out its quirks and found that it works well the way you use it and remember enough, but for a non-standard module, most people will still have all of those hoops to jump through.

My initial reaction to the root node was about the same as mirod's. And it still is.

But I also now realize that I wish more people would pay attention to the 'cost' of using a module (especially a non-standard module or a module that won't work on slightly-old Perl versions). There are still plenty of cases where the cost/benefit is a no-brainer in favor of using the module (for me, sending e-mail from Perl would be such a case). And I consider "no modules" to be an unreasonable stance.

But, "just do use Date::Module; ConvertRoutine(...)" sure looks easy, and probably is really easy for the person who writes it. But I usually find that it isn't very easy. Perhaps because I must be convinced that it really does solve my problem before I'll use it, and one test doesn't convince me.

So let's have some balance on the scale of "use modules".

*shrug* All I really wanted to say was the first sentence. (:

- tye        

Very rarely do modules fail to install.

I see module installation issues occur as questions on this site, almost every day.

The authors do need to be notified, and the problem, if any, does need to be resolved. I'm not arguing that.

What I am arguing, is that sometimes a module is unnecessary, and a solution that is just as valid can be provided using core modules.

I would just like to point out that installing modules with ppm is easy IF active state has that module. Recently I tried to install PDL and to my amazment it can't be installed by ppm unless you goto pdl.perl.org and download a binary to run. This is a common case with modules when trying to install on windows. A lot of modules do not install using ppm. It is sad but true. Perhaps there is some tutorial or something about expanding ppm but I haven't seen it yet.


___________
Eric Hodges

I think your suggestion is really great for teaching programming with Perl, but it's not as good for teaching people how to use Perl effectively. Despite that statement, I do have mixed feelings about the whole thing, since I consider both to be very important. It is true, however, that it is impossible to master Perl per se without being able to use CPAN effectively.

You'll probably find that a lot of the monks disagree with you, but I think your post reflects some real thought. I also think that the nature of the Monastery, with its many opinions and opinionations will make sure that both the core language and CPAN are covered.

Don't forget that part of the reason the Monastery works so well is because people enjoy posting. Sometimes we get golf, but most of the time we get answers that really help. I suspect that requiring people to use the core language would be seen as unfun and discourage the plurality of paths to the same goal.

requiring people to use the core language ...

There is no talk of "requiring". I think pbeckingham is simply trying to raise our consciousness on this issue when we go to reply. E.g. if we see (as I did just today) a question that has gotten a slew of non-standard-module-based responses, consider offering a solution based on the standard library or core language. And vice versa.

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

You're right. He doesn't use the word "require". He does however say "I'd like to suggest that we provide answers using standard modules, when those solutions are adequate," which appears to suggest that he wants us to offer solutions based on something other than what we might have posted originally. That is what I meant with 'require".

You made me think of another thing, as well. I interpreted the OP as saying something like "instead of posting stuff with modules that are not well-known, post stuff written using the core language, or with modules that are part of the distribution." This second issue depends greatly on what we think "standard modules" means. For me those are the ones that come with the Perl distribution, and pbeckingham states here that this is what he meant.

But we first have to arrive at a consensus about which modules are standard (core, core plus DBI, etc.), which is a discussion onto itself. I wonder how many monks are posting stuff using modules they consider to be standard, but which others do not.

--
Damon Allen Davison
http://www.allolex.net