When you use a module you abstract the problem. If the module is well conceived and maintained then it is future proofed against changes in underlying standards/conventions and comes with bugfixes and support built-in. It is also almost always written by someone with a, sometimes drastically, better understanding of the problem space and its pitfalls.

I am paid to maintain legacy code and write new code. Most of my time gets sucked up in the legacy side because of this style of thinking: Why use CGI->param() when I can just parse them myself? While I’m happy to be employed, I’d rather be writing new stuff than fixing constant regressions and bad edge cases caused by the old stuff. You are preparing to perpetuate the old stuff on the next hacker. I’m encouraging you, as was daxim, to stretch and see what else is out there to make your work easier, more robust, and better for the dev who inherits it.

Thank you very much, for taking the time to elaborate your point(s), Your Mother. Greatly appreciated, as are your intentions.

Then the answer is simple; they can all eat shi...

print "content-type: stinky/poo; charset=bad":
[download]

Seriously tho; points well taken.

But I have to tell you, I really struggle with all the abstraction; "CGI->param()", for example. I'm not a fan of CGI.pm. I'm not sure it's as quick, nor do I think that not having to remember things, is necessarily a "good thing(tm)".

I say struggle, because I realize that using all these Modules really can speed up development. But I also recognize that they all add overhead. They can also make diagnosing strange issues that might crop up, harder to find.

I realize, it's all about balance. So I guess what I'm trying to say is; I'm still not sure where the perfect balance lies.

Best wishes Your Mother, and thank you again for your reply

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;