FWIW, Why I like functional programming is not really about functional programming (see tillys new disclaimer at the top of the node). If you are looking to learn functional programming I would recommend ANSI Common Lisp by Paul Graham, its more about lisp, but it will give you the basic concepts.

Pardon me if this is offtopic here, but you seem to be much on track with functional programming, so I ask here: do you think that developing macros in Emacs LISP for mostly text-processing kind of problems (like: count the words in a paragraph, capitalize the first letter of all words of the selected region, etc.) is a good way to get on with functional programming? What other problems do you recommend to solve for a newbie? LISP is a must: Pugs just does not seem to be their yet...

I want to add functional programming to my heavy artillery very badly...:-)

rg0now

rg0now

To be honest, I have never written a program of an signifagance in any purely functional language. I have however read a number of books on a number of functional languages, which has helped me in my day-to-day perl programming. But much of my motivation to learn functional programming was purely curiosity driven (actually boredom driven, I was doing a lot of javascript at the time). My suggestion is not to worry so much about the language you choose to read about/experiment with, but to concentrate on the concepts behind those languages, and let them inform your day to day programming (in perl or whatever). So much of what makes functional programming so cool is not language specific, and a lot of it can be done in perl (5 and 6).

-stvn

Once again I'll plug MJD's upcoming book on how to use all the best things about functional programming and Lisp and show you how to do them in Perl. I signed up to the mailing list and read the draft chapters, cool stuff.

Higher Order Perl

I'd suggest not worrying too much about what is "real functional programming". Instead try to pick up a couple of specific functional techniques that you find useful, get comfortable with them, and see where that leads. Even if it isn't "really" functional, if it is useful and not something you would have tried earlier, that's good enough.

My motto is, "objects make good nouns, functions make good verbs". A common situation is to do something like this:

$handler{$case}->(@arguments);
[download]

where %handler is a hash mapping specific cases to anonymous functions saying what to do for each case. (Some of those anonymous functions may be very similar to each other, and you factor those out into closures...) Look for opportunities to use that, and try it a few times. See how it looks. See whether the construct stands up under normal maintainance.

After a period of becoming comfortable with that, then you can try another technique. Such as setting up a mess of related functions to fill out a template. (I find myself doing that more often in JavaScript than Perl. I write a function that takes a group of related form elements and gives them closely related event handlers.)

Once it is comfortable, it will probably become useful. And vice versa.