in reply to Re^2: How A Technique Becomes Over-rated
in thread How A Function Becomes Higher Order
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:
or more likely, just assume types need to be compared in general// not as useful as closures, not even 'close'... Max max = new Max(){ boolean compare(Object a,Object b){ ... } }; while(...){ .... }
class Whatever implements Comparable { // used by generic sort (or max) routines public int compareTo(Object o){....} }
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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: How A Technique Becomes Over-rated
by QM (Parson) on Sep 22, 2005 at 19:17 UTC | |
by Ctrl-z (Friar) on Sep 23, 2005 at 11:58 UTC | |
by QM (Parson) on Sep 23, 2005 at 14:48 UTC | |
by Ctrl-z (Friar) on Sep 23, 2005 at 17:56 UTC | |
by Anonymous Monk on Sep 23, 2005 at 18:14 UTC | |
by Anonymous Monk on Sep 23, 2005 at 14:59 UTC |