Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re: How A Technique Becomes Over-rated

by Ctrl-z (Friar)
on Sep 22, 2005 at 13:13 UTC ( [id://494098] : note . print w/replies, xml ) Need Help??

in reply to How A Function Becomes Higher Order

Closures are cool, but I dont really see any practical or theoretical benefit to what you are tutoring:
package Max; sub new { my $class = shift; my $max = undef; return bless \$max, $class; } sub compare{ return $_[1] > $_[2]; } sub max{ my $self = shift; for ( @_ ) { $$self = $_ if $$self == undef || $self->compare($_, $$self); } return $$self; } package StringMax; our @ISA = ('Max'); sub compare { return length($_[1]) > length($_[2]); } package main; my $max= new StringMax(); while ( <FH> ) { chomp; $max->max($_); } my $long_str = $max->max();
The same functions, the same number of lines - better organized for applying to real problems.

time was, I could move my arms like a bird and...

Replies are listed 'Best First'.
Re^2: How A Technique Becomes Over-rated
by Limbic~Region (Chancellor) on Sep 22, 2005 at 13:40 UTC
    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.

    Cheers - L~R

      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...
        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.

        Quantum Mechanics: The dreams stuff is made of