Point-free style

There's a lot of argument about point-free style. I think it's a red herring -- the style is not good or bad per se. The problem is with a conflation of two different aspects of abstraction:

1. generalization -- a function is an abstraction in the sense that it's a generalization of an algorithm; n + 1 will give you the successor of n when n is 17, but it will in fact give you the successor of n for any value of n (under certain restrictions, of course). So λ is a universal quantifier, meaning &lambda n → n + 1 is a successor function for all integers.
2. setting the level of detail -- abstraction is also about forgetting irrelevant details and focusing on important details. In terms of engineering, we eliminate the irrelevant details so that they can be changed without having any observable effect on the parts that depend on them, and we keep in the important details so that all the configuration options are available. But in terms of communication, we set the level of abstraction at an intuitive level to make sense to the reader.
   

There may not be a single right way to set the appropriate level of abstraction, but there are also plenty of ways to set an inappropriate level of abstraction. While there's a lot of attention given to setting a high enough level of abstraction, it's important to think about the ramifications of setting too high a level of abstraction.

Since, as we all know, programs are written for human readers, the level of abstraction is the most important tool for communicating a system effectively to another person. Putting in too much detail (i.e., a low level of abstraction) overwhelms the reader with excessive amounts of detail. People are stupid, so that's no good. But it's also well-known that people understand in terms of examples, and they can generalize much better once they have particular examples to start with. Setting too high a level of abstraction is a sure way to confuse the reader, make them feel stupid, and make them dislike you. (But hey, if that's your thing..)

How does this relate to point-free style? Well, for one thing, an argument name gives someone a name to perform hypothetical examples on. When you have &lambda n → n + 1, you can think about this entity n and what you're going to do with it. When all you have is succ, the only entity you have to work with is the operation itself (and oh, how the category theorists jump with glee!).

So? This may be just fine! It's all about talking at the right level of abstraction. If I'm thinking about a pipeline of conversions, having too many arguments may be a total distraction. I'd rather think of name->number as the composition

string->number ⋅ symbol->string ⋅ name->symbol

than as λ x → string->number(symbol->string(name->symbol(x))) because I really am thinking about this as a compound operation. The entities are functions, and I'm building a compound function from smaller ones. Watching the marble go into the pipe isn't relevant or interesting.

But when you generalize as absolutely far as you can, you sometimes create strange beasts that have no simple intuitions. This is why fold is so much harder to understand than map. Again, though, there isn't a single conclusion to draw. Sometimes these abstract monstrosities turn out to be so powerful that we get used to them out of necessity. People use fold a lot, so it just becomes one of those things you have to learn. It doesn't have an easy intuition, but it sure is useful.

But if you fill your program with such abstractions, good luck getting anyone to read it.