Let me point to the discussion at Operator Precedence and specifically my comments therein. I'm all for using the best tool for the job, but if you are writing code that others are going to see, you need to try to keep it as reasonably understandable as possible. What's 'reasonably'? Well, that definition's going to vary, particularly with perl.

In the Big 3 languages, C, C++, and Java, these are typically taught to CS students, and there's a few key textbooks that are used for this; in addition, these languages don't offer the richness that Perl or other scripting languages have in terms of builtin functions, syntax, etc. Thus, if I was in a shop that used the Big 3, I'd know where to expect the 'reasonably understood' level to be at. As an example, I'd expect someone to understand a massively deep inheritence structure in C++; however, I would expect that someone might have trouble with C++ templates, and would effort myself to write more comments in that area.

Perl, since it doesn't have a standard teaching path, is much different. (While we believe that at least one school does teach it, based on the massive duplication of the finite automata question, this is only one of thousands). Based on what I read on NGs, here, and elsewhere, the most common learning path of perl is what is in 'Learning Perl', and possibly what is out of 'Programming Perl'. I don't have the former book in front of me, but I don't recall a lot of advanced topics coming up in it, things like map and grep, for example; instead, my reading of the book was more focused on doing direct input and output from a script (actually using perl as the expanded acronym implies). Thus, if we assume a perl shop has, at *best* that common knowledge from 'Learning Perl', then we are drastically restricting what we can do with the language, unfortunately. This may be one reason why dc's shop highly discourages these idioms.

Now, if I were in charge of such a shop, would I stop at that point? Probably not; sure, I know those coming in would be at a disadvantage, but that's why you train employees. Teach them the advanced features of perl (IF NEEDED!!) by either an in-house trainer, or someone from outside. Get them immersed in existing code that may use the advanced features. This way, you don't have your hands tied by limiting yourself to a subset of features.

Of course, I would still discourage the use of advanced features that are not intuitively obvious. Map and grep , for example, are very simple to understand once you know they are there and seen them in use a few times. But Ovid's non-standard goto example, or using some of the code that pops up from Golf solutions, would be questionable because of it's readibility. If someone did determine that they just had to use an advanced feature to get the job done right, I wouldn't discourage it, but I would strongly encourage excessive commenting of the code around it. For example, in Ovid's case, if a comment such as 'In this form of goto (to a sub reference), the calling stack immediately switches to that code' preceded the questionable line, then I'd be more comfortable with that code (though as others have pointed out, the programming logic can be replaced by other code bits that are much more readable).

So to get back to the point at hand, I would never encourage dumbing down code to a very basic level; I'd determine where a reasonable level would be, and try to take all advantages of that level. However, commentings would be very important here, and I would strive to make my programs as readable as possible without the comments in the first place. The right combination of readable code and commenting will make even the most complex pieces of perl code understandable by all levels of programmers.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important