Yes, that was my point. That example of point free programming is just bad and confusing, as you pointed out. On the other hand, if I try to keep my functions

Yes, that was my point. That example of point free programming is just bad and confusing, as you pointed out. On the other hand, if I try to keep my functions and methods small, I frequently have to write methods which just apply a function to all elements of a collection. In a point free style, I can just write manyFoo = map foo And that's it. No loop, no recursion, no boundary issues, no clutter, just the statement 'this applies foo to everything in a list'. Similar things work for other nicely curry-able problem statements. Imagine you have a higher-order-function traverse which takes two functions, and uses them to transform a binary tree to a value (applying the first higher order function in order to combine the left and right results of a tree and and the other function to turn leaves into values) Now you can define: treesum = traverse + toNum preorder = traverse ++ toList And so on. Overall, the best advice I had about point-free style was: "Try to refactor your code to the form "f x = g x" and remove the x, if the refactoring can be done in a painless way". If you apply this, the drill drills well :)