http://www.perlmonks.org?node_id=494109


in reply to Re: How A Technique Becomes Over-rated
in thread How A Function Becomes Higher Order

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.

Cheers - L~R

  • Comment on Re^2: How A Technique Becomes Over-rated

Replies are listed 'Best First'.
Re^3: How A Technique Becomes Over-rated
by Ctrl-z (Friar) on Sep 22, 2005 at 15:55 UTC

    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.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

        If the class has a compare method that doesn't work for my current problem, do I subclass it and create my own maxstr?

        If you are referring to my original post, then yes. The Max class abstracts the algorithm of calculating a maximum of objects - the subclass implements the comparison in the appropriate context. Im not suggesting this is the best OO solution, just one that is like the Higher-Order equivalent.

        If you meant "Foo.compareTo() doesnt compare Foos like I want", then the solution depends on (among other things) how much internal access you need to compute the comparison. There are quite a few ways this could be approached but to bring it back to my original point, they are mostly structured and organized - not hidden un-garbage-collected variables and blind function dereferencing.

        What if each object needs a unique compare function?
        Then what are you comparing it to? I would have thought similarity was a prerequisite for comparison.
        What if these functions aren't known at compile time?
        Closures are compiled too. That is, whether you use gt or > (or whatever) is decided at compile time - there is no runtime dynamic there.
        What if there are so many functions that it's difficult to give them all unique and useful names?

        They are all called 'compare' - different classes do different things when it is invoked.

        update: clarification - Im not sure Im addressing your questions?




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