I didnt, and apologies if i came across as an OOP-advocate on the defense. My point was that eventually, you get the computer to execute some machine instructions - everything else is organization. Higher-Order functions just dont seem that organized.

In your re-write, you would have to create a new kind of compare package/function combo for every single type of comparison you wanted before you could use it.

Of course, but the functional approach still requires creating the function. In Perl, if you are using closures to do this, then they too are static comparisons created before you use them. If your using eval, then all bets are off...
The package is a limit in Perl's implementation. In Java you might approach this by defining the subclasses algorithm during its instanciation, eg:

    // not as useful as closures, not even 'close'...
    Max max = new Max(){ boolean compare(Object a,Object b){ ... } };
    while(...){
        ....
    }
[download]

or more likely, just assume types need to be compared in general

   class Whatever implements Comparable
   {
       // used by generic sort (or max) routines
       public int compareTo(Object o){....}
   }
[download]

All of these do a similar thing - accomodate abstracting the 'flavour' of an algorithm while allowing the programmer to customize the relevent parts. The Object Oriented ones do so in an explicit, structured way, requiring very little additional documentation or conceptual leaps.

Really, Im no OOP advocate. But I am inclined to accept the 50 years of engineering experience that has passed since LISP was invented.