|Pathologically Eclectic Rubbish Lister|
I will second the remark on CPAN modules being hard to discover. Another issue is that sometimes the documentation leaves quite a bit to be desired.
And then there are us poor losers who haven't really gotten the perl OO model. Yeah, it's great, blah, blah... But I find in some cases it is more efficient to simply write the function myself. Using Win32::Process may save you some headaches later on down the road, but if all you need is a "rsh" to get the DF output from the Unix boxen, you have used the backticks about halfway through the module docs.
One final note, modules are essentially code I don't write and maintain. That just plain makes me nervous. Maybe I'm just paranoid, but I know the code I write, and I can read the code I write. Saves me from posting "Segfault using Storable" posts all of the time.
From the tone of your post, it sounds as though you have some specific beef with your companies use of Perl, and have extended it to the larger world of Perl outside of that enclave.
Perhaps an application should be a collection of generically useful modules. Perhaps you should rephrase "modules" as "objects" and we can get down to making Perl work like VB.
The trurth of it is my friend, Perl is a reporting language, not a RAD tool. It does an admirable job of being a RAD tool, future versions of Perl seem to be working to position Perl as a RAD tool, but at it's heart it is still a pathologically eclectic rubbish lister.
Does your boss not allow you to use modules?? Or is your programming team not up on module usage and you have to maintain their code? Then it is an issue of training and education either for your boss or your programmers.
Getting what you want generally does not involve saying, "You are an idiot! Now meet my demands." Inform him why a module might be better. "Hey boss, did you notice that the Bubble::Yum module can simulate chewing at three different speeds?? Our program only does one speed. Maybe we should check out that module."
So rewrite 2-3 programs that you think would benefit most from modules. Test for speed, etc. Since writing with modules is so trivial, it should take you hardly no time.
If you cannot find where the module is an improvement, then there should be no need for the module. Simple. Once you have shown him 2-3 programs that could be drastically improved by modules, he'll probably have you rewriting all of the code to use modules and you'll just complain about that.
Some people rage at the darknes, I carry a lantern.