I have programmed in perl for some time (~4 years). It has never been my primary language for significant period of time and I would by no means consider myself to be an expert on perl. However I believe I have written and read enough perl code to make some comments on the language.
As a programmer I have been strongly influenced by the work of Steve McConnell, particularly his book Code Complete. The core thesis of the book is that code should be written first for maintainability, with other concerns following (security, performance). This is not to say that security and performance should not be considered while programming, just that the primary consideration should be maintainability. There are several reasons for this:
I don't think perl is a language that is designed for maintainability largely because it isn't designed for legibility and legibility is the major factor in maintainability. There is certainly plenty of anecdotal evidence that suggests that perl is harder to read than many other languages, but is its reputation justified? I believe it is.
Perl has an extremely broad syntax. This means that you can choose to do one thing multiple ways (TIMTOWTDI). This is a major disadvantage when it comes to reading software. Computer programmers, in my opinion, read code by pattern matching. That is, with a particular language (and even across languages), they see and recognise patterns which enables them to read and understand the code more quickly. Each time the programmer reaches an unrecognised pattern, they must slow down to understand what is being done. When you introduce multiple ways to do things, you slow reading speed and decrease comprehension because you are dramatically increasing the number of available patterns, and most programmers may not be able to remember all of the patterns. Equally many programmers will not remember all of the syntax of the language, which means they need to reach for a reference more often.
A classic case of this for perl is the string delimiters. Most programming languages use either single or double quotes as string delimiters. Some (eg Javascript) use both and other languages use both with some slight differences (eg php). perl does its own thing and allows you to define custom delimiters for strings. This is done to make life easier for programmers, so that they don't need to escape string delimiters when they define the string (eg when generating HTML with double quotes as string delimiters, you would spend a lot of time escaping the double quotes for properties on HTML elements). While this makes it easier in specific cases, for general maintainability it reduces legibility. When you run across someone's new pet string quoting style, there is a slowdown in reading speed and comprehension.
On top of its broad syntax, perl also has unusual syntax elements. Not only is there are heavy reliance on symbols (which admittedly are concise if opaque), there is also the use of unusual "words". This includes the use of elsif (probably the most illogically named conditional, either go for elif or go right out there with elseif. Please, no some half way non-standard abbreviation). Another example would be the eq operator. Perl defines a special operator for comparing strings, eq. Most other weakly typed languages get by just fine with using == (or in some =), comparing strings the same way that they compare any other variables. This continues with using ne or neq for string not equal to.
There is also a feature of perl that is just plain evil. What makes this feature so bad is that it is temptingly evil. In perl you can add values to a class at runtime. The problem with the feature is that it is very easy to use, and without programmer discipline it will be used ("I'll just add this property here rather than going back to the class definition..."). The effect is that when you have an instance of a class, you don't know what properties the class and you can't find out by looking at the class definition, you need to track the specific instance from birth to death. From an OO perspective this is plain evil: the class diverged from its definition.
The issues with perl are not transient issues, they relate to the core philosophy of the language: TIMTOWTDI. This philosophy results an overly broad syntax, which in turn makes the code less legible. It would be far better to have one or two good ways to do it. Having 5 or more ways is never a good thing, even if all of those are good because it just promotes confusion.
Perl is a deeply flawed language. Despite that it is possible to write perl code is both clean and maintainable, but only be exercising discipline and limiting the syntax you use to a small subset of the available syntax. This requires discipline on the part of the programmer. This does not solve the problem of programmers outside your company/development group, examples provided in books and online. I'm sure that are stellar programmers out there who can quickly scan perl programs and understand they because they know the syntax and all its variants, but perl makes life more difficult that it strictly needs to be.
Comments and suggestions are welcome. Email me on david@-nospam-uberconcept.com (remove the -nospam-)