Polemic: anyone who believes that any specific general purpose programming language is inherently unmaintainable has opinions on software development worth ignoring.
Many people claim that the design of Perl 5 has such significant flaws that render it far too difficult to write and maintain useful programs. Many of the supporting arguments are syntactic preferences. "I don't like sigils!" "Context make no senses to my!" "Real men don't need your sissy curly braces to accompany our manly indentation!" "Isn't bless a little bit cutesy for our Serious Enterprise Business Application?"
Other arguments... well, you've heard them.
Perl 5 has some design flaws, but I believe that syntax is such a small part of maintainability that only the most facile discussions focus on syntax to the exclusion of more important concerns. The next time you have trouble maintaining a Perl 5 program, ask yourself:
- Have I learned the language by reading documentation and working through tutorials, or am I fiddling with changing things by trial and error and guesswork and intuition based on experience in other languages?
- Do I know how to use
perldocto look up builtins and language features? - Have I skimmed the Perl FAQ included in every Perl 5 distribution?
- Have I used Perl::Tidy to unify the formatting into a consistent style?
- Do I know the difference between void, scalar, and list context? Can I identify them?
- Do I know how to use B::Deparse to explain the evaluation plan of complex constructs?
- Does this program have a set of automated tests I can trust?
- Did the original programmer understand the problem domain? Do I?
- Did the original programmer "borrow" this code from elsewhere, change a few lines, and add a modified copyright statement?
- Did this program grow from a throwaway idea into a critical business component without planning, design, or refactoring?
- Is the original author available to answer questions, whether in person or through some sort of design notes?
- Is the program well-factored?
- Does the program include appropriate documentation for its purpose, its major systems, its APIs, and any surprising design decisions?
- Do I have a clear understanding of what the program does and why?
- Does the program have a modular design, with well-enforced encapsulation boundaries between components?
- Can I configure and build the program on my local system?
- Can I deploy it?
- Does the code show examples of idiomatic programming from authors fluent in the language, or is it a pastiche of styles cribbed from documentation and witch-doctor expermentation?
- Did the original author know how to program in any language?
- Did the original author take advantage of obvious strengths of the host language in appropriate ways (or did he distrust arrays and continually write to and read from a temporary file instead—I have seen this with my own eyes, and the host language was not Perl)?
- Does the program take advantage of well-known and trustworthy external libraries?
- Does the build process spew compiler errors and warnings? Does the program spew warnings and errors when deployed?
- Does the program contain obvious repetition and near repetition?
- Would you be proud of writing the program in six months?
Note how few of these concerns have anything to do with Perl—and, of those that do, trivial rewording would make them appropriate for other languages.
I would include "does the code come with any documentation". And I am not sure that B::Deparse is a standard tool to figure out what he code does. If you need it, then something is definitely wrong with your code.
It's a funny list though.
It may not be "my code" that I am looking at and having to figure out. It may be "yours", in which case B::Deparse could help in certain situation.
As you say, you can write maintainable or unmaintainable code in (almost) any language. But Perl's design goals of DWIM, rapid prototyping, and freedom join together to make the bell curve of Perl programs shift towards unmaintainability, compared to many other languages.
If you're working in a big project, I guess you can require people to use Perl::Critic and other tools. But you can't force the entire Perl community to use these tools unless you codify them in the language itself. (You seem to be trying to shame people into writing good code, using cultural force rather than coding shackles; I wish you luck in the endeavor, but clearly lots of busy people haven't taken the time to read your blog.)
To bring an example from the biology world I work in, Perl makes it possible for scientists without much coding experience (or without much time) to do some pretty amazing things. But it also allows them to do it very messily. And if that's the only code that does what I want, I just have to grit my teeth and dive into it.
Too much code that I download has unreadable regexes, action at a distance with undeclared variables, breaking into object hashes, and other maintainability sins that just aren't possible in other languages. And while I firmly believe that the pluses of Perl outweigh this minus, I won't deny that the minus is there.