This is just another coding style. After 1-2 weeks you get used to whatever you're reading. Try it and you'll see. It's the high-level code that can become an

This is just another coding style. After 1-2 weeks you get used to whatever you're reading. Try it and you'll see. It's the high-level code that can become an issue (structuring the state of your program, using dependency injection incorrectly, having a convoluted monad transformer stack, putting very specifically typed effects in your Reader etc.). If you make mistakes there, you will struggle to read, write and reuse code, and even then, not all is lost. If there's bad structure you can most often transform it into a good one. When there's no structure, that's a problem. Seeing .map.filter becomes a quick pattern match. You know what's happening there. It does not matter if it's a named variable or just part of a long a.map .filter .reduce .map chain. I agree, if your goal is to hire a lot of people, then you might want a style that does not strain the pattern matching abilities too much. We can compare which style is the best for that. Nothing stops you from extracting a sequence from a long chain into a function to reuse it elsewhere. pipe( object, map, filter, ... ) Many languages today allow declaring functions inside functions. I'd argue that in that case it's better you declare functions as close as possible to the place where you'll call them, which can be inside another function.