But those lower level programmers are not getting the experience that turns them into good programmers.
I assume you mean 'those new programmers'... lower-level programmers would be working with ASM, or even C in this context, not perl.
I disagree anyways -- there have always been bad programmers, and there always will be. The lower level languages have even more potential areas for insecure programming, and that fact will not stop people from writing bad code, nor will it make them understand the underworkings of the computer. Just because a good programmer must know more about the computer architecture, doesn't stop bad programmers from not caring and writing code anyways. In fact, the steeper learning curve of lower-level languages may even provide more of an incentive to copy-and-paste, rather than spending more effort to learn the underworkings than it would to learn the essentials for proper coding in higher-level languages.
I'm trusting the language designer to write a good _compiler_ to write small utilities, well written, rather than presenting every programmer with that stunning mass of debris I find coming out of places like CPAN.
CPAN is not the perl interpreter. You object to perl as a language or higher-level languages as a concept, because there are people who write poor code, there are people who decide to use prewritten poor code, and there are websites that provide easy access to all this prewritten poor code? I hope you realize that this has nothing to do with perl, and that a parallel exists with every language at every level of abstraction from the machine level. There are certainly many, many pieces of assembly and C/C++ which are poorly written and yet are copied-and-pasted by others... if anything, it's harder to become a good lower-level programmer since there are more issues and technicalities to consider. Those that don't become good lower-level programmers will not necessarily stop programming, they'll just continue writing bad code.
We should resist toolboxes that include that many slightly different hammers, many of which are liable to break and many of which have handles likely to slip in the grip of a normal user, sending a large and spinning object flying towards anyone working near them.
So then we shouldn't use nail guns, because they don't require the carpenter to repetitively practice the skill of hammering in a nail like a hammer would? Yes, it's a lot easier to hurt yourself with a nail gun... but it also makes building many houses a much more feasible task, and allows the carpenter to concentrate on the fact that they're building a house, rather than the fact that each nail must be driven properly. Under the pressures of common job timetables and the monotony of hammering each nail, they may even accidentally screw up the overall design without realizing it -- accidentally not seeing the whole picture as they are too concentrated on the tedious and repetitive details. There are invariably construction workers who will use the nail gun improperly and hurt themselves or others -- so you get out of the way and refuse to work with them or hire them, rather than not permitting anyone to use the nail guns.
I'm afraid I've been that person near them and struck with those handles too many times in the last five years, and from observation, far too many of the scripting language authors need to go back and be _mentored_ in how to do efficient or even safe code, because they certainly didn't learn it dealing with Perl.
If they can't, won't, or haven't learned efficient/safe coding practices in perl, what makes you think they'll learn them in C, which requires far more details and studying?
It sounds to me like you shouldn't have been using amateurs' code, regardless of language, for essential or business purposes... you can hardly blame the language for that. If anything, you or whoever made the decision to use the poor code are to blame.
For examples of the insanity, I'll point you directly to mod_perl itself and resolving which versions of mod_perl itself are compatible with your project.
mod_perl is an integration of perl into a different environment, which is not a trivial task. I don't really use it personally, so I can't comment much. I regularly use perl in professional programming tasks outside of the realm of web scripts, and it performs quite well. It can be very fast, albeit with twice the memory footprint of similar C code; however the efficiency of writing many things more than makes up for this, and as I mentioned you can selectively optimize the important parts with language features, embedded C/C++/ASM, or even interfacing with external C/C++/etc libraries. Many parts of a generic C project do not have code that requires hand-optimized performance.