At the time I lacked the programming background to know that "functional programming" was already used to refer to a specific style of side-effect free programming. People who use that style also use a lot of the same techniques that I was using. But they consider those techniques to be basic building blocks, and not at all the point of what they are trying to do.

To this date I don't know of a good name for the techniques that I was explaining. You could call it, "How to use closures." MJD came out with a book about such techniques called Higher Order Perl. That name fits fairly well since using higher order functions (ie functions that apply to functions) is the key characteristic. But I don't know how people would react to your using that name. (I use higher order Perl and you don't - you suck!)

In any case I'm not particularly bothered by the lack of an accepted name. The techniques work, and I use them where appropriate. I think that it is good that more people in the Perl world use them than used to. But if someone proposes a good name that is unused, I'll gladly use it.

To this date I don't know of a good name for the techniques that I was explaining.

If they are techniques that are often used by functional programmers, in functional programming, then I think it makes sense to call them "functional techniques." That's the term I usually use to describe them. I think it implies that some of the ideas are used, but not necessarily the "purely functional" model.

I was writing about Perl programming techniques that I learned from a Lisp programmer. Since they were techniques that used anonymous functions a lot, I thought that "functional programming" was a good description.

At the time I lacked the programming background to know that "functional programming" was already used to refer to a specific style of side-effect free programming. People who use that style also use a lot of the same techniques that I was using. But they consider those techniques to be basic building blocks, and not at all the point of what they are trying to do.

Really? I thought it was the other way around: side-effect-free programming makes it possible program in a fully functional way, because side-effect-free functions live "outside of time" just like numbers. So it seems to me that what you call "functional techniques" is very much the point of Haskell.

I'm just learning about Haskell, but it is already clear to me that Haskell invests a lot of effort on making functions really first class: it lets you not only pass them to and from other functions (just like Perl does), but also provides built-in operators and other syntactic constructs for easily creating new functions and operators from existing ones.

Read more... (836 Bytes)

Most of these operations on functions can be mimicked in Perl, but my point is that with Haskell one gets the message that these function-oriented facilities are really central to the goals of the language.

the lowliest monk

If you read my node carefully, you'll find that the functions I'm passing around maintain state, communicate with each other through side-effects, and in general are not very "functional". I find such functions useful, but they are not exemplars of what the functional programming folks want people to do.

Maybe tilly can enlighten us?

*) If you want pure, don't use perl.

**) I am not at all a FP expect.

I suppose he's referring to the top paragraph:

"When I wrote the node I didn't realize that the term functional programming was already in use for something different than what I describe below."

"What should it profit a man, if he should win a flame war, yet lose his cool?"

The best line in that interview is:

TPR: Are you surprised that after a couple of years of working on a book about functional programming in Perl, Autrijus Tang has lit a fire under the community by using Haskell to write a Perl 6 compiler?

MJD: Everything Autrijus says and does astonishes me.

That made me laugh out loud at work.

---

My wife's blog