I read this in Mark Seemann’s blog:
Most of the classic design patterns are based upon the idea of programming to an interface instead of a concrete class. In OOD, it’s necessary to point this out as a piece of explicit advice because the default in OOD is to program against a concrete class.
That’s not the case in FP because functions can be composed as long as their signatures are compatible. Loose coupling is, so to speak, baked into the paradigm.
This is nonsense. The fact that functions can be composed as long as their signatures are compatible does not imply that the functions you compose are loosely coupled. In FP you can easily write functions that depend on the concrete way that information is represented. Changes in how a function returns data may break other functions down the road. I would say that in fact the opposite is true: the main danger of FP is that concrete representations are passed around all the time. At least this much can be said about OO, that OO pushes towards encapsulation of data representations. This is “baked into” the OO paradigm.
Look, I fully agree that FP is great. But how much of this new enthusiasm for FP is due to FP being a new thing (at least to these new converts?) People trying FP now did not have the time to write spectacularly bad systems with FP. Yet. Then what? We’ll be praising Logic Programming over FP? Me, I’d rather spend my time learning to use one paradigm *well*.