The problem I have with your solution isn't so much the "cleanness", as well its inefficiency. You will be checking for direction for every comparison made by the sort - instead of checking it once.

In either case, you still have an O(n log n) sort. If you are really concerned about the difference in efficiency here, you might be better off programming in C or assembly. With perl, it's not even so easy to determine the efficiency with that level of granularity. For instance, how does your reverse() compare to the additional branches in the OP's code?

It seemed the OP was hoping to make his code cleaner and therefore easier to read and maintain. In terms of efficiency, he could be saving minutes to hours of programmer time over the lifetime of this program compared to the mere seconds of machine time your optimization may save. And when you compare costs, the difference is likely to be even more significant because developer time generally costs a lot more than machine time.

None of this is to say the solution you suggested is a bad one. It isn't. Regardless of efficiency questions, it is clearer. If he's going to use this same sort more often than once, though, sticking it in a sub might be a good idea (in which case, of course, it should be given a better name than the OP's original mysort().) Two separate subs for ascending and descending might be a good idea in that case too.

-sauoq
"My two cents aren't worth a dime.";

And when you compare costs, the difference is likely to be even more significant because developer time generally costs a lot more than machine time.

That's a red herring. Machine time is utterly unimportant. But what is important is the end user. Would you accept it that the movie you're watching on your PC freezes because developer time costs more than machine time? In general, it's very hard to say anything about developer time vs. running time. Many programs aren't designed to be run once, they will be run thousands, or millions of times.

In this specific case, lifting the descending/ascending switch outside of the sort (be it by using reverse, or two comparison functions) doesn't cost anything. It's the same amount of code, making the same decisions. I've a hard time imagining a coder that would take hours more time to do the same amount of things.

A good coder will always program with efficiency in mind - doing thinks like this (lifting code that will yield the same result out of a loop) should be automatic. And don't come with the mantra premature optimization is the root of all evil, because we're not sacrificing anything. The code doesn't become less flexible, harder to read or harder to maintain. It doesn't trade memory or some other resource for speed either.

Perl --((8:>*

That's a red herring. Machine time is utterly unimportant. But what is important is the end user.

You've just called something a red herring that wasn't and then offered something that was. Of course, context matters and in another case I might take your stance but we are discussing this case. It's unlikely that the micro-optimization you offered would ever be noticeable by an end user. And, as your optimization didn't change the time complexity of the algorithm, even if a user came along with orders of magnitude more data than the average, the change would still be just as insignificant.

Would you accept it that the movie you're watching on your PC freezes because developer time costs more than machine time?

Firstly, if I was writing a multimedia application, I probably wouldn't be doing it in Perl, and if I was doing it in Perl, you can be sure I'd be using XS for the important bits. Secondly, if we were talking about an optimization that meant the difference between a machine freezing or not, we wouldn't be having this discussion.

In general, it's very hard to say anything about developer time vs. running time. Many programs aren't designed to be run once, they will be run thousands, or millions of times.

Though it may be hard to be exact in what you say about developer vs. running times, it isn't hard to make useful generalizations and get a handle on the big picture. If this program actually were run millions of times, your micro-optimization might succeed in saving hours of run time. But, those hours would still be amortized over all those runs and all those users and would still amount to an imperceptible benefit.

I've a hard time imagining a coder that would take hours more time to do the same amount of things.

I said "minutes to hours" as a contrast to the "seconds to minutes" of machine time. A change like this is certainly unlikely to take even an hour, but if you can't imagine it taking a lot longer than it should, I'd have to guess that's inexperience talking. What I was getting at was that the machine time saved over all runs of this program is likely to be worth less than the developer time spent making this micro-optimization.

A good coder will always program with efficiency in mind - doing thinks like this (lifting code that will yield the same result out of a loop) should be automatic.

That's true. And yet, even experienced developers can make mistakes like these when fatigued or under pressure. But, that isn't the issue. The issue here, and the reason for my initial response was your claim that

"The problem I have with [the original poster's] solution isn't so much the "cleanness", as well its inefficiency."

An experienced developer doesn't look at that and see a glaring inefficiency; he sees a minor inefficiency. From there, it's a judgement call as to whether it should be changed immediately or just given a quick "FIXME" comment for the next review. But, in any case, he's certainly not going to start thinking about inserting a "GRT to avoid the sort block."

Again, it all comes down to context. It's true that, when you get a question like this, there's only so much of the context that you know or can discern. So, start with what you do know... things like "this is being written in Perl" for instance. That's usually enough to tell you whether a given micro-optimization is going to be important. In this case, it almost certainly isn't and the "cleanness" of the code is definitely the more important issue.

-sauoq
"My two cents aren't worth a dime.";