Or a complete lack of a grasp, in my boss's case! ;-)

Knowing when to use Perl's idioms, and when to avoid them is the real point, I think.

For example, assigning to a typeglob just to get rid of a single level of indirection is a Perl idiom that's non-obvious, and not a wonderful idea if done for no reason. If you need to play with the typeglob syntax, it's there, and it's on rare occasions quite useful, but there's no reason to dabble lightly.

My boss didn't think so. He would frequently write stuff like this:

sub foo {
     my $x = shift;
     *y = $x;
  
     # Quick, what's he just done? He's just added something
     # to our namespace via aliasing, (and stripped a level
     # of indirection thereby), but what, exactly, has been
     # added?

     # Is it %y, @y, $y or even &y? What's he
     # up to? Arrrgh!

     # hundreds of lines later (a separate annoyance)

     # Ah, he aliased %y!!! $x must have been a *hashref*
     # He could have just written %y = %$x, but that 
     # would be less efficient, and far less idiomatic
     
     foreach my $key ( keys %y) {
         bar($key);
     }
}
[download]

Me, I'd just explictly dereference %$x, and skip the whole typeglob idiom, unless there was a significant reason not to do so. If I really wanted an automatic conversion, I'd probably use signatures instead. And if I were for some reason going to use the idiom, I'd point out at least the types (scalar, hash, array, or coderef) that I expected to be aliased by the idiom.

Making a section of a hash "local" is another of my boss's abuses of Perl idioms, in my opinion. Yes, you can make things "local". Wow, you can even make sections of things local. What a cute, quirky little way to express yourself: idiomatic perl at it's finest! It's barely even a documented feature!

And with it, you can call a function on a hash, and then go back, and undo what parts of the function did, based on a poorly documented set of flag settings! What fun!

Me? I'm just bitter, I guess. ;-) Too much burnout. :-(
--
AC

Sounds like your boss is "clever" in about the same way that I'm "lazy". Which is to say, in exactly the opposite way to the global definition. I do a lot of work to maintain my laziness, and your boss is myopic in his cleverness.

Sort of like being "penny wise, pound foolish." Being clever in small spurts while being wholly unclever for the rest of the code is not clever in the global sense.

I think we're almost completely in agreement on the ideas, even though we'll disagree as to the semantics. That's neither clever nor idiomatic. At least not in "Tanktalus' dictionary." Just because it can be done in Perl, and just because it may be unique to Perl, does not idiomatic make. (In this case, using global references is not unique to perl - C++, for example, can use "int& reference = some_other_variable;".) There are lots of features to perl - your boss is just using the most obscure in the least intended ways. That's not idiomatic, that's idiotic. (Well, that may be harsh, but I like how I just removed the "ma" from "idiomatic"... ;-})

To me, more idiomatic is what you said: use %$x instead. Mixing sigils for dereferencing is perlish to me. And I can't think of another language that does this. And it's still readable, maintainable, and flexible.

Granted, convincing your boss of that is an entirely different story.

To me, more idiomatic is what you said

Hmm... I was using "idiomatic" in the sense of a rarely used word that's only used or understood in the right circles; just as more "advanced" perl features like typeglob tricks or XS code might be.

Granted, it can also be used to mean "the way people commonly talk"; and this usage is from the standpoint of the small group of idiomatic speakers.

Since I try to code using the simplest expressions that convey my meaning clearly and concisely, I tend to mentally associate myself as being outside the circle of "perl experts"; I really *don't* want to fall into the habit of (ab)using typeglobs for everything if I don't need to. My ex-boss is a cautionary example for me now, I guess...

One day, many years ago, while feeling "clever", I wrote a single regular expression that would reformat text paragraphs to any given line length. And then I gave it to my co-workers as an amusement. None of them could guess what it did at a glance. Then I carefully documented how the regular expression actually worked, and came back with a full fifteen lines of documentation for a single line of code.

And then I went back, and re-wrote it in the boring, obvious way, in ten lines of simple perl. All of my co-workers could understand it at a glance. It wasn't "clever", but it was better code, because it was easier to maintain.

That's the usage of clever I meant; cleverness for it's own sake, not for the sake of good code. Good code is often bland, just as good documentation is often bland. Both should quickly convey the intended information, with a minimum of fuss or wasted time.

Granted, convincing your boss of that is an entirely different story.

Fortunately, he's not my boss anymore! :-) Unfortunately, I have to maintain thousands of lines of incomprehensible code. :-( It's win/lose, I guess...