Re^5: seeds...

[Tanktalus]

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.

[Anonymous Monk]

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...