These may all have interesting mathematical similarities, but the way you would use them in a program would be pretty different. Actually, by definition, h

These may all have interesting mathematical similarities, but the way you would use them in a program would be pretty different. Actually, by definition, how they are used are not different. This is a key concept. While the tuple example was just that, the idea of defining interaction contracts (often called "laws" in FP literature) is powerful. It can reduce conceptual load due to expectations being clearly defined. It also, perhaps more importantly, enables expressing a solution in a robust manner having clearly defined collaborator roles. I think your concern about communicating programmer intent is keen. The risk is there whether it is a chain of flatMap, LINQ, or fluent interfaces[0]. IMHO, this the same concern with poorly formulated imperative logic. Having to work backwards to figure things out is orthogonal to the approach taken and IME directly correlated with the attention paid to non-executable artifacts (such as comments, diagrams, discussions, etc.). 0 - https://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface