But do I know whether the comparison function is supposed to return a 1 or -1 to sort to say that the left side is smaller than the right this time...? I could guess but I never remember that. If I really need to know it, I can look it up any time. All that I need to know the vast majority of the time is that whatever way it goes, sort and the comparison functions agree on how it is done. (And this tidbit is of a kind I find hard - for instance I still have to think about whether in a LEFT JOIN the table you want to fill in blanks for should be on the left or the right.)

EDIT AUG 2009 Somehow this node got badly messed up. I've filled in the end with what I think is my original thought, but it is unlikely to be right. :-(

(Indeed anyone who develops an understanding of obscure constructs by constantly experimenting with how many language constructs they can use is a hazard to your code base...)

Interesting viewpoint.

Do you have a feel for which (perl) language constructs you would deprecate from your codebase?

Would this be a single, hard & fast list or would it vary by codebase or project?

Is it just knowing the obscure constructs that constitutes the hazard? Or does the person have to use them before they are guilty?

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

It varies by codebase, project, and most importantly, who you expect to work with and then maintain it later.

The problem is that TIMTOWTDI is a maintainance headache. Anyone who wants to abuse it forces you to have all maintainance work done by someone who has more expertise than the regular programmer. Not the same, because someone who is merely the same may just know a different set of tricks, but better so that they are likely to know all of the tricks that the first show-off used.

The answer is to decide which ways to do it you will settle for based on other factors, and to stick to them so that someone else can pick up the code and be brought up to speed in a reasonable amount of time. Having people who know lots more ways to do it is fine and good and may be a good thing (knowing your choices in advance makes it easier to pick a good set of choices to stick to), but actually using them all all of the time is a bad thing to do unless you are trying to be hard to understand.

Similarly, in #5, I'd also ask for an explanation of $var = @array;, and for a comparison between the two.

Thanks Aristotle; you induced self doubt there given that i was also thinking of the value of a list being evaluted in scalar context.

So i suppose, OP could add/replace a question something like..

What are the values of $x and $y below?

  @odd = (1,3);
  $x = @odd;

  $y = (1,3);
[download]

...I feel much better now after consulting w/ perl.