in reply to TMTOWTDI... and most of them are wrong
Now, there's two ways of approaching this need to trust the programmer. Languages like Java say "I'm only going to trust you as far as I have to, but no further." This may be perfectly valid in some situations. I know that if I'm coding with a bunch of people I don't know, I'd prefer to do it in Java instead of Perl.
On the other hand, languages like Perl and C say "Since I have to trust you, I might as well TRUST you." And, so, they leave as much as possible up to the programmer. The major difference between Perl and C (which is what BrowserUk alluded to) is that Perl provides a lot of scaffolding for you. Little things like automatic memory management, useful types, and dynamic recompilation.
My reasons for this prediction were that corporations and other large organizations have less use for brilliant code that only to a small number of Perl wizards can grok, than for mundanely-written code that even the non-wizard can follow.
This point deserves a special response. There is "brilliant code" in every language that only the wizards can grok. When was the last time you read the Perl source?
Remember this - reading code is hard. If it was easy, then no-one would pay use the big bucks. It's not supposed to be commotitizable. If it was, then outsourcing would actually work in the average case.