I agree with you in a sense. FP has its pitfalls, it is almost too easy to decompose, compose and build abstractions in the FP idiom. We often only praise the

I agree with you in a sense. FP has its pitfalls, it is almost too easy to decompose, compose and build abstractions in the FP idiom. We often only praise the power and expressiveness of that property and act as if most of us are capable of making the right decisions all the time, which is quite obviously not the case. (This is especially true if we add stuff like macros and homoiconicity to the language. The Lisp Curse has been discussed to death.) I think the best approach here is a disciplined/pragmatic focus on readability as you are implying, without neglecting advanced FP techniques in the places where they actually solve a problem well. Currying is in a sense one way of doing dependency injection in the FP paradigm. But more often than not, when I'm looking at a function that can/should be curried there is something wrong with the data/data-structures and not with the function. And instead of bending the function(s) in an 'advanced' (read: complicated/complected) way, we can often transform or even re-model the data itself to make our code clearer and more robust. The toy examples in the blog post can't be used to illustrate this well, which is fine, because the author just showcases the technique basics.