I disagree with the general idea behind the request, however. If someone asked "How do I use a variable as a variable name?", I would not shy away from saying "You really don't want to do that." Likewise for questions like "How do I parse multipart/form-data without using a module?" or "How do I access my database without using a module?"

Some solutions are worth the trouble of trying a slightly different approach. Likewise, some problems are difficult enough to do the right way, without having to code with your hands tied behind your back (metaphorically speaking).

You're absolutely correct that modules that need a C compiler are much more difficult to install than Pure Perl modules, and that's a definite drawback.

But it doesn't change my opinion that in certain domains, certain modules are the reasonable choice. I'll just never beat you with Camel 3 if you don't agree.

Chromatic, I would be a fool if I said that that modules weren't wonderful, and there are modules that will do what you want to do, better, faster and more robustly then any home-grown way.

I would like to add though that if a monk specifically has a request for no modules, in addition to whatever module advice you may dispense, realize that they may have no control over the limitation, and try to add something on the no module topic also. Even if it's just "BTW, module XYZ does this really well - if you are forced not to use it, you might want to take a gander at the way it does it so you can avoid a couple of common pitfalls".

My request was not to say no modules, that's foolish. It was just to ask politeness if sometimes the world outside our monestary does not match our ideal.

Thanks,
=Blue
...you might be eaten by a grue...

6 of one, a half-dozen of the other.

Sometimes someone will say "No modules" and there is a very good reason for it that they have no control over. But usually there isn't. What I think is particularly bad are the people who say that they don't want to use a module because they think that modules are slow. If getting the program ready quickly and making it robust is less important to you than raw performance, well that is a battle that has been fought from assembler to C to Perl, to Perl with modules - guess which side always wins in the end?

So someone shows up and says "no modules". Should we not make sure that the person really does understand what they are giving up?

OTOH we should - even while checking that - be sure not to be impolite because they really might be unable to do anything about the restriction.

While I agree that some times a requirement against Perl modules can be a valid thing, most of the time it isn't. They just say that because they don't want to be bothered with learning how to install a Perl module, don't understand how they work and don't want to be bothered to learn, are just afraid of aspects of the language that they don't know yet, or they think it will take longer to learn how and to actually install a module than it would take them to re-invent the solution on their own. When it is prohibited by management, similarly, it's because the managers don't understand Perl modules, what's involved in getting them installed, and don't want to bother learning. They'd rather have their programmer spend 10x more time re-inventing a poor solution to a common problem than have them spend an unknown amount of time learning how to install a proven and robust module (perhaps on a large number of client systems) that would shave their development time down to nothing.

"No non-core Perl modules"

I can see several 'sensical' reasons to avoid them, beside want of basic instruction in the area of module installation, etc.

Most of them have to do with maintenance - this being a particularly acute problem for people stuck on Wintel machines where CPAN does not really shine, 'make' and a compiler are often unavailable, and PPM is sometimes broken. In general,if you are contemplating a solution that has to be deployed on more than 2 machines, the repeated installation of the same module is something you'd really like to avoid. The argument is only stronger if you want to package and distribute your code to third parties, and you cannot expect to have a perl wizard at the receiving end.

Some things with CPAN's behavior also do not help: carrying a module configuration over from a Perl upgrade is not as transparent as one would hope, and am I the only person dismayed by the fact that modules using IO::Sockets now try to perform an install of the entire 5.6? (I run 5.00503 on my production machines) I must have ^C'ed out of that at least 5 times. (On the 6th, the build ran unattended, & I had to uninstall it by hand - methinks that upgrading perl should be regarded as an operation on which the user has some say)

So I can see several situations where I would want to avoid non core modules. OTOH, not using DBI for rdbms chores is out of the question, just to quote a "can't do without" non core module. So 'no non-core' can be unachievable after all.

Cheers, alf

"No non-core Perl modules"

WHAT?

No *way*, man. These modules are made to be used, even if they are not installed as standard.

OK, let's see the arguments:

• "this being a particularly acute problem for people stuck on Wintel machines"
  • "where CPAN does not really shine" - for me, it has worked out nearly all the time. The main problem for CPAN are firewalls, but even most firewalls are easily handled by an entry for the http_proxy environment variable.
  • 'make' and a compiler are often unavailable - make: go for nmake (available for free from Microsoft website), compiler: yes, this can be a problem. But most common modules will be somewhere on the net as binary, compiled by a friendly soul. Or are already available as PPM files from ActiveState.
  • "and PPM is sometimes broken." - for me, it nearly always worked out till now. The firewall problem is there, of course, but then you can download any PPM by hand from the ActiveState site with your favorite browser.
• "In general,if you are contemplating a solution that has to be deployed on more than 2 machines, the repeated installation of the same module is something you'd really like to avoid. The argument is only stronger if you want to package and distribute your code to third parties, and you cannot expect to have a perl wizard at the receiving end." - No, no, no. Read the documentation on the CPAN module Bundle features (e.g., the autobundle command). Just build a bundle for the things you want to distribute, and distribute that then. There is a problem here with conflicting versions of modules, but you have this problem with any library use, and there are solutions to that (see also this discussion).
• "am I the only person dismayed by the fact that modules using IO::Sockets now try to perform an install of the entire 5.6?" - No, you're not. That is annoying, for sure.

Reinventing the wheel for something else than educational purposes or big money is a Bad Thing.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

I should perhaps stress that I am thinking of InstallShield-like type of delivery.

I've always wondered this: What's to stop a Perl developer from wrapping his application in an InstallShield-like installation program? Modules are just additional required files (a la DLL's and the like). I'm not 100% sure how this works, but if you can install stuff in a directory of the user's choosing plus $WINDOWS, why can't you extend that and install things into $PERL_LIB/site_perl (or however you need to go about determining that destination)?

If you're installing a module once on a single machine, it pays to use stuff like CPAN or PPM. Nevermind that it seems to be buggy for you (I've never had problems). If there's a problem with the tool, report it and/or help to get it fixed.

If you're going from there and mass-distributing an application between different systems, just extend your process to include the modules that your application needs. Go from this:

c:\myapp\myapp.pl
c:\myapp\myapp.conf
c:\myapp\MyModule.pm
[download]

to this:

c:\myapp\myapp.pl
c:\myapp\myapp.conf
c:\myapp\MyModule.pm
$PERL\lib\site_perl\Some\Module.pm
$PERL\lib\site_perl\Another\Module.pm
[download]

Or just 'use lib' in your code, and install Some::Module and Another::Module straight into c:\myapp\!

I really don't understand what the big deal is. If you're already going to have to invent a mechanism to mass-distribute your Perl application, why can't you just take it a trivial step further and include the modules in that? Am I missing something?

It is my opinion that people just don't want to even think about figuring out how to do this extra step, so they invent a "no non-core Perl modules" restriction in their development. It just doesn't make any sense to me. What we need is someone with experience with some of the various installation program toolkits that can tell us how to bundle Perl modules with it in a reliable way (either placing them straight away in the Perl's lib directory (maybe watching for versioning even), or just a simple installation with bundled modules placed in the application's directory).