I think the bold part is something which for someone like myself is very important. Perl is a language that is relatively easy to start with. Using nothing more than perlintro and perlfunc a novice can start typing away and produce his/her first scripts. They may not look pretty or be the most efficient, but with a bit of effort they'll get the job done. When compared to the amount of basic knowledge one needs to even produce "hello world" in C or Java this is a huge asset.

As for a more rigid dialect, I can't help but feel this highly depends on the circumstances. When seen in the context of a large organization I think it is this very organization itself that needs to manage which dialect is spoken throughout the project. Besides, Perl isn't the only language one can write horrible code in :-) In any case, long story short, any project involving more than 1 person needs to have some ground rules on how to work. My personal approach would be to create something like perlstyle, albeit more specific, and simply make sure everyone adheres to those rules. It's a lot easier to demand that people adapt their own styles to "the greater good" once there's paychecks backing up the arguments.

I'm very much of the opinion that code should be written in the same structure as English: code should read much like prose. We learned English since birth, code is a relatively new development. Changing the rules just leads to confusion.

We read left to right, to to bottom, in a single pass, and we parse sentences for meaning as we read. Unless there's a good reason to the contrary, program structures should follow the same patterns.

This is why, for example, I consider foreach() clearer than map(). Linguisticly, foreach() is simpler.

foreach() says, basically: set pronoun $_ to each of these nouns in turns, and then read the following sentences in the appropriate context. Children deal with pronoun substitution all the time. No problem.

map() does the job backwards. We have first to read each of the sentences, abstract away the meaning of the pronoun $_ without knowing what it means, remember the meaning of the sentences, and then, at the end of the statement, take the memorized meaning of the abstracted sentences we've read, and substitute in each noun for the abstracted sentence. That's harder: we seldom do all that in English.

Why is map() less clear? Well, because it breaks the familair linguistic rules of English. Specifically, it breaks the rule that says I can expect to know what a pronoun means before it's used. When that rule is broken in conversation, many people get confused. For me, the same trait carries over into coding; I'm more likely to get lost if I'm missing expected context.

That distracts me from what I really want to understand: the hows and whys of what's been written, and specifically, why it's right, or what's gone wrong.

As I've argued before, programming (in a professional context) should be considered akin to technical writing: a formally correct document that's transparently understandable to as wide an audience as possible. Writing obscure, beautiful poetry should not be the goal of a technical writer, nor of a professional coder: clarity, correctness, and simplicity should be the order of the day.

Good coding, like good technical writing, is hard work. And like technical writing, it's easy to spot bad code, but harder to identify good code, except by contrast. I don't see the creation of ANSI Perl; Perl's strength as well as it's weakness is the richness of it's feature set. I see the creation of a myriad of fragmented in-house coding standards, and a lot of conflicting style guides.
--
Ytrew Q Uiop