But it pays back in spades when you are considering what you can do with different sets of tools. And it is indispensable when you're trying to design a tool.

In Perl 5 it practically isn't worth the bother to think, "Oh, I could do this with currying" - you just do it with a closure and avoid the extra step. But if you know how to think about what you're doing as currying, then when you use a language with good support for currying, you will have some notions on when to reach for that rather than writing it in Perl 5. Alternately if you are working in a language that without support for closures, but you understand that all you really want is currying, then you can figure out ways to simulate the simpler concept rather than trying to do full-blown closures.

Furthermore when it comes to designing tools, well have you read Perl 6 : Not Just For Damians? Take a look at the example of currying offered there. If Larry and Damian et al did not have language to discuss the idea of currying, would they ever have thought up such a nice way to do it?

So yes, learning about currying is completely useless to you in day to day Perl 5 programming. But concluding that it is therefore a useless concept is a fast way to fall into the "Blub Paradox". See Beating The Averages if you don't know what that is.

This is to both you and adrianh.

I have apparently misinterpreted this as thoughts on perl5 practice and constrained myself to that universe. Implicltly, I've thought that if I were in some other language where currying was standard I'd think along those lines. In this language (perl5), I don't and so I didn't and I objected with my initial request for a terminology change.

I do however, take to heart your bringing up that issue of language power and the perspective limiting aspect of being proficient in a language. In fact, I've often read all these functions returning other functions composed of other functions, wrapping other functions and felt really quite swimmy. Very lost. Suddenly I'm reminded of E and their Promises and the "So when does something *happen*?" and it makes more sense.

Thanks. This was useful to me. I just gained a new way to think about this stuff.

I don't see the utility in going out of the way to inject extra obfuscatory language just to describe it

It's only obfuscatory if you don't know what the terms mean :-) If you do then the utility is more information on the intent.

If somebody refers to a curried function then I know that they're going to be taking a function and specialising it by freezing one of its arguments. This tells me more than if they had referred to it as a closure.