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.