I think it is a little more complicated than that.

I once worked at a major online retailer where C++ was king and found that many developers sneered at Perl as a 'scripting language'. The essence of the criticism is in line with some of Grandfather's observations in that Perl is perceived as 'quick and dirty' with respect to results but not as a language to use in coding high-performance, scalable and mission-critical software. While I haven't done a lot of benchmarking, it seems believable that for many tasks, a compiled program may out-perform an interpreted 'script'.

I think there is a more subtle criticism of Perl as a language and against Perl developers, which goes something like this:

• Perl allows a developer to 'slap something together' to get quick results for even very complex problems.
• For most real-world problems, quick results are rewarded.
• Over time, Perl developers can become conditioned by the quick-results philosophy and begin to abandon more rigorous software practices, resulting in permanent software that is 'slapped together'.
• When a Perl developer comes up against a serious programming problem which requires extensive algorithm analysis, high performance, high scalability, and high reliability, they can be too impatient to 'do it right the first time' because of the quick-results conditioning.

I know I'm painting with a broad brush, and I suspect this may ruffle some feathers. Although I have resented this criticism from C++ developers, I have to admit that I am often very impatient in addressing problems, and I sometimes neglect to go back and refactor some of the quick-fixes that have become part of my permanent code base.