Perl 5 (and probably Perl 6) *can* be used to write scripts. That doesn't necessarily mean that it's a scripting language (implying that it can only be used for that purpose).

I define a script as something that looks like a script for a play. That is, it has a list of instructions which should be executed in order. There may be the odd sub-routine, but these are mostly in the same file (of course, with Perl, there may be various calls to CPAN modules, but the code specific to this operation is more or less all in once place). Of course there are no hard and fast rules (i.e. you *could* push some of it into a module), but we're talking about a matter of style here.

One way of writing bad Perl (and there are many, TIMTOWDI applies even here) is to attempt to extend this style for use in applications. I'm sure we've all seen this first hand: huge if/elsif/else structures, requires all over the place, global variables used without regard for the future maintainer's sanity. Some of us (myself included) may have even written code like this.

The scripting style is certain useful for small, fairly self contained pieces of code. Or for one-shot jobs that are again fairly simple. Any other use is probably a bad idea.

I think one reason why people who don't know Perl well have difficulty in understanding the difference between a language that can be used for scripting, and a language that can *only* be used for scripting, is that many languages only allow one style. Perl, of course, allows many.

Additionally, many junior programmers don't really understand the concept of coding style. They just use whatever works. That's why, when you ask them to write a more complex application, they may use the scripting style they've always used.

These things can contribute to a bad (but undeserved) reputation for Perl.