I would stand by what I said about what the community views as cool bleeds into the communities practices at work.

It is (or was, I don't keep track of such things), 'cool', to wear trainers without laces, but I never saw a marathon runner, nor sprinter, nor footballer, nor even a local jogger adopt this form of cool. 'Cool' is doing the opposite of what our parents did or want us to do. Or the same as the celebrity we admire. Or doing different to that group of people we wish to distance ourselves from.

Cool is subjective, transient, divisive. Cool is undefinable beyond a small group of like minded people. Using it in a discussion to 'tar' a whole community with a single, personal perspective is emotive, irrational, oneupmanship. Ie. Seriously uncool.

With Perl, I always get the feeling that maintainability is seen as a bolt-on afterthought.

Maintainability cannot be "bolted on", just as it cannot be designed in. It has little or nothing to do with statement-level or block-level syntax or semantics.

It has everything to do with good algorithms and their clean and concise implementation; clear abstractions and clean interfaces; complexity management and the reduction of interdependencies. Good design at the application level, and formalised documentation and working practices at the project level, are always far more significant in the costs of ongoing maintainability than statement level syntactic choices of a given language, or of the language choice itself. Always.

... [Yet another smart quote from a smart person, quoted out of context to support an undefined opinion]

Quoting smart people does not make you smart.

And here we get to the crux. When you say so little and imply so much, you are most often concealing your own preferences, rather than conveying a supportable argument. The implication from all the things you are not saying, is that you consider Perl's permission of idiomatic construction to be clever and therefore unmaintainable.

That is akin to arguing that the componentisation of manufacturing, eg. large scale integration of transistors into ICs in the electronic industry, is unmaintainable when compared to say discrete component constructions from 30 years ago. And to some extent you are correct. A single failing transistor in an IC is impossible to replace, so maintainability is lessened. However, ICs are far, far more reliable than discrete circuits, so the need for maintenance is far, far less. Overall, we have a win.

A similar analogy can be drawn between 1970s, normally aspirated, mechanically-timed and ignited car engines when compared to todays fuel-injected, variably-timed, multi-valved, electronically ignited engines. In the 70's and early 80s, I (as an amateur) was perfectly happy to undertake rebuilding a car engine at home with simple tools. These days, I wouldn't know where to start. However, modern engines are far more reliable, require far less maintenance, and have much longer service periods than those old ones. Again, an overall win.

Perl's idiomatic constructs allow the concise representation of high level algorithms in a few short statements. Just as one statement of C represents many lines of assembler, so one line of perl can take the place of many, many lines of C. To argue that the use of idiomatic Perl is 'too clever' and therefore unmaintainable, is to argue that assembler is more maintainable than C.

I've seen people argue that

for my $thing ( @groupOfThings ) {
    if( $thing <= SOME_CONSTANT ) {
        $thing = $thing * SOME_CONSTANT;
    }
}
[download]

Is "more maintainable" than

$_ <= SOME_CONSTANT and $_ *= SOME_CONSTANT for @groupOfThings;
[download]

because, they argue, at some point in the future, it might be necessary to do something extra within the body of the loop, and then the maintenance programmer would have to reconstruct the loop to the second form. That would be a 'bigger change', therefore 'more' or 'harder' maintenance.

I say rubbish. If it becomes necessary to re-factor the latter concise form into the former, then the algorithm has changed significantly. And the issues of maintenance--what other effects that change of algorithm will require and what knock on effects that has on the wider code-base--are far more important that the small effort required in performing the refactoring.

One of the things that is conveyed by the concise form is: this is a single cohesive step in the algorithm. And that of itself is valuable information to the maintenance programmer. Spreading that single, cohesive step over several lines in order to accommodate future changes that may never happen, discards that information and potentially raises doubts in the maintenance programmers mind.

My favorite cookbook often starts the SAUCE section of recipes with: