You have a point, but I think you're taking it a bit too far (and yes, I did stop and think).

First of all, "dumbing down" is an awfully harsh term here. The for loop and if statement solutions that LanX suggests are functionally equivalent to any other solution that has been proposed, and there is no meaningful performance penalty.

To me "dumbing down" would be avoiding powerful language features (such as regexes) because they are confusing. That would be dumb. But this is nothing more than a benign style preference.

Perl's allowable syntax is so vast that anyone who wants to write sane code will only use a subset of it. Maybe avoiding map and the ternary operator is going too far. But as much as I love map, I have to admit that I am usually using it "because I can" not because it is clearly advantageous in my code. And as much as I love the ternary operator, it has its pitfalls (such as the can-be-used-as-an-lvalue-making-assignments-have-unexpected-behavior pitfall).

Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

I have no problem with people choosing a particular style -- well, not too much anyway :).

I do have a problem with programmers "simplifying" their preferred style under the justifiction that those that come along after them may not understand it.

And I have even more problems with people advocating that everyone should dumb down their code in order to make it accessible to the lowest common denominator of programmer skill sets. Be that done under the auspices of 'best practices'; or 'modern Perl'; or Perl::Critic; or any other set of non-personal rules or guidelines.

And the reason I have a problem with it is because it demeans the dedication and perseverance that it requires for even half descent programmers to acquire the education and skills that make them such. It encourages (and even enshrines!) the viewpoint amongst those non-programmers and 'did a bit once many years ago' semi-skilled programmers (think:managers and personnel types), that all too often control the purse strings (think:recruitment and education budgets), in our industry, into believing that programming is easy and that any ol'post-grad that had sufficient attendance on a half-credit basic programming or CompSci course, is sufficiently skilled to design, write and maintain code.

Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

Sorry again, but that just doesn't make sense.

Anyone who needs to read your code with a view to understanding it well enough to base business decisions upon that understanding, is acting in a professional capacity. As such they should be sufficiently educated to understand the code, or willing to expend the effort to acquire that education.

And if they are not making business decisions based upon their understanding of the code, what do you care if they do not understand it?

I'm most offended by "Perl, because of the nature of the language,". The fact that Perl is an accessible language -- designed to be so -- should not prevent the recognition that is a fully capable professional language usable for the construction of highly complex software.

And just as with any other profession, the products of the programmer's skills require a certain level of education and/or aptitude to understand before you can hope to safely maintain, modify or extend them.

Nobody would deny the non-programmer sysadmin from learning just enough Perl to allow him to knock up a few scripts to simply his daily workload; or the hobbyist webmaster from learning enough to add a bit of dynamism to his website. But trying to use that ease-of-entry of the Perl language as reasoning that professional Perl programmers should code down to their level is just crazy. Wrong at every level.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

Funny, I can't envision that as a valid scenario -- if you can't read it, don't try to modify it ... educate yourself