http://qs321.pair.com?node_id=492713


in reply to Re: How A Function Becomes Higher Order
in thread How A Function Becomes Higher Order

jdporter,
I agree that good judgement needs to be employed when deciding how to use this technique to solve a problem or if to use it at all. Perl does a great job of providing us many tools so that we can choose the right tool for the job. This basic tutorial was intended to introduce the concept and illustrate a basic example of the steps taken to transform a basic function into a Higher Order one.

With regards to extensibility and named parameters, the advantage is clear when you consider optional parameters using the positional approach. Imagine your function starts out accepting 3 parameters. You then add an optional parameter which you stick on the end. Now if you want to add a 5th parameter you need to change the ordering of the parameters which will break backwards compatability. The issue gets even more complicated if you have more than one optional parameter.

If this doesn't make my position clear, let me know and I will provide a concrete example using Tie::SortHash and Tie::Hash::Sorted.

Cheers - L~R

  • Comment on Re^2: How A Function Becomes Higher Order

Replies are listed 'Best First'.
Re^3: How A Function Becomes Higher Order
by jdporter (Paladin) on Sep 16, 2005 at 18:51 UTC

    O.k., you're talking about extending the one function in situ, not the kind of extension that subclassing or aggregation gives.

    And that's essentially my complaint about this technique: it's nearly impossible to build large, extensible frameworks with. In my experience, functional programming works great at small levels of granularity; for anything larger, OO is far more useful. (Of course, the FP purists will disagree, and I'm not saying they're wrong.)

      And that's essentially my complaint about this technique: it's nearly impossible to build large, extensible frameworks with. In my experience, functional programming works great at small levels of granularity; for anything larger, OO is far more useful. (Of course, the FP purists will disagree, and I'm not saying they're wrong.)

      I certainly wouldn't describe myself as an FP purist, and I spend most of my time with OO languages these days, but I've found both FP and OO equally useful "in the large". Different techniques certainly, but both equally useful.

      In my experience, functional programming works great at small levels of granularity; for anything larger, OO is far more useful. (Of course, the FP purists will disagree, and I'm not saying they're wrong.)
      Indeed there are languages that support both paradigms. Most notably in this context, Perl itself. However to support is one thing and to enforce is another one; I'm curious about Objective Caml. Whatever the language, I wonder if there's any project that uses extensively both OO and FP techniques...