First, thanks for your comments and your questions.

Regarding the general thrust of your questioning, which I believe can be summarized, Why do all this crazy FP stuff when the equivalent "normal" Perl code is perfectly reasonable and probably easier for most Perl programmers to understand? I have a couple of answers.

First, don't take my examples as the poster children for functional programming. This is a meditation, and a tutorial-style one at that. The examples are slanted towards meditation – mind stretching calisthenics and all that monastic stuff – not practicality. The point of the examples is not to say, This is the way to do it, but rather, Meditate on this code. The journey is the reward. (Further, my code isn't truly functional. It's a Perl-functional hybrid that nobody ought to mistake for real functional programming. Consider it "functionally inspired.")

Second, after studying the code and understanding the thinking behind it, that's when you can see the benefits. The benefits aren't so much visible in my meditation's examples as they are upon reflection on the spectrum of problems that can be solved using the exact same techniques. Even though the shape of the problems may change, the solutions stay the same. The traditional approach, in contrast, is effectively hard-coded for one shape.

Consider the code snippets that you compared in your post. Both operate on two input arrays @site1 and @site2. That's the shape of this particular problem. But what if the problem isn't static? What if we're given a list of arrays to process? The shape changes. The code you wrote embodies the static structure of the 2-array problem. Add an array, and it breaks. The outer pair of for loops is a hard-coded solution for the 2-array case. The fp-inspired approach that I show is independent of the shape of the problem. Instead of passing in \(@site1,@site2) you can pass in any number of input arrays. And the same code works, as is.

Now, in real life, we usually know the shapes of our problems ahead of time. So what does the shape-flexing capability buy us? It buys the ability to code at a higher level and, more importantly, to think at a higher level, which gets to the heart of your question below:

The thing that struck me was that my perl version would be reasonably clear to most people with more than a passing familiarity with perl. Whereas your version...?

The reason you perceive the fp-inspired code as hard to follow is because your brain hasn't "internalized" the meaning of products and zips and the rest of our new vocabulary. To you, these words probably seem like gratuitous functional jargon.

But the words have meaning. When I saw the example problem as first posted by the Seeker of Perl Wisdom, I immediately thought, "Ah, he wants the count of each value from the zipped products." And the code immediately followed.

That's the reward. To have the right words to describe the problem. To have more ways of stringing together ideas. To reduce the gulfs between problem and understanding, understanding and code.

If this sounds like worthless babble, that's OK. I didn't appreciate functional programming until I had used it to solve real-world sized problems for over a year. Only then could I "feel" fp in my bones and appreciate its potential.

So far, FP is interesting, and in some ways quite elegant, but it is also way over sold in some aspects.

Have you read Why Functional Programming Matters? If not, read it.

I love Perl Monks, but don't look at the fp examples on Perl Monks as your window into the fp world. Take a look at the stuff going on in the Haskell Communities Report. Read some of the papers from the ICFP proceedings. That's where you'll find the good stuff.

... I don't quite get the idea of going further with FP in Perl?

Perl leaves much to be desired as a functional programming language. Not having currying, pattern matching, proper tail recursion, and real garbage collection are limiting, painful even. But Perl is much better for fp than most other mainstream languages. For that, I'm thankful.

Is it worth the effort to use functional-programming ideas with Perl? Part of my motivation for this meditation was to explore that question. I wanted to take some common fp ideas and run with them in Perl. How far can we go? What's painful? What's beautiful?

My belief is that fp is a useful and even powerful way to program in Perl. But Perl isn't Haskell or O'Caml, and some things are better off left to the old ways. I think the most practical approach, then, is a functionally inspired style for Perl.

Thanks again for your thoughtful response to my meditation.

Cheers,
Tom

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.