Ctrl-z,
Perhaps you mistook my tutelage for advocacy.
Did you realize that your StringMax doesn't produce the largest string (gt) but the longest string (length)? The function in the tutorial got renamed at the end because it became an all-purpose reduce function. 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.
There are of course more ways to do it. The point of the tutorial was to take some scary magic from Functional Programming Land (Higher Order Functions) and demystify it. Jargon aside, the majority of Perl programmers I have seen only know 1 or 2 paradigms (imperative & OO). They try to fit everything they see into one of them. By providing an introductory lesson, I hoped to expose some people to a new way of doing things which they could determine for themselves if it was a good fit.
This isn't about OOP vs FP vs IP. This is about having a big toolbox and knowing how to use the tools inside.
| [reply] |
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(...){
....
}
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){....}
}
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.
time was, I could move my arms like a bird and...
| [reply]
[d/l]
[select] |
Sticking my nose in where it doesn't belong...
If I understand it right, one of the points of L~R's original post was that the comparison function can be defined by the user, and passed in as a coderef. If I understand your post, you seem to be saying that the same end result can be achieved through OO and classes.
But I'm fuzzy on what you suggest should happen in OO. If the class has a compare method that doesn't work for my current problem, do I subclass it and create my own maxstr? Do I append to the class my own method?
...
package SomeClass;
sub my_compare {...}
...
What if each object needs a unique compare function? What if these functions aren't known at compile time? What if there are so many functions that it's difficult to give them all unique and useful names?
I'm not sure that any of these questions are easier or harder to answer in OO vs. closures.
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply]
[d/l]
[select] |
