Anil Wadghule explains why applying SOLID OO design principles to their extreme leads to Functional Programming.
Our aim is to provide Great events rather than Big events. We want our participants to enjoy a learning experience that is second to none. We pride ourselves on being user focussed, designing then refining all our events to ensure our participants want to come back every year.
Do you really think that we can somehow roll up the OO sleeve to make it functional and expect that it will solve all our problems? Don't you think that "patterns" will precisely be needed to properly deal with the missing semantics?
Patterns are indeed only about teaching people how to properly encode the missing semantics of a deficient formalism. Why don't we actually create a formalism with enough semantics to cover State, Type, Action and Relationships (STAR)?
Since you can embed OO in FP very neatly and FP forms a strong foundation, it seems that an industry which is embracing understanding and exploiting foundational structure will be better off than one that doesn't and, from this position, valuable "insights of art" can be properly developed which might include analyses like STAR and SOLID.
On the other hand there's a reasonable question as to whether FP can act as more than merely foundational. Another way of asking this question is to ask whether functional mechanisms are too cumbersome for describing meaningful models of thought that programmers would like to use. For instance, while OO is neatly encoded in FP, if you want OO that, say, resembles Java then you will be in for a very difficult encoding.
My thoughts here—which, I'd like to clearly distinguish from the ones before, are much closer to mere opinion—are that FP is not too cumbersome and instead provides insight into better, more compositional abstractions than the ones programmers are used to (from OO). It may be the case in time that FP does feel too cumbersome—from a Haskell point of view, the most immediate example would be desiring to always have ambient reference state, to always live in an ambient reference state monad—but my belief is that this pathway of development will lead to higher-level "default" abstraction states which are *far* more principled than OO as it is known today.
I would encourage anyone who writes code to read this paper from Dr. Lamport: Computation and State Machines. This should close the debate once and for all about this FP vs OO nonsense. The arguments put forward make sense but it's a bit like saying a screwdriver is better than a hammer. The reality is that it depends.
Hipsters, which voice is often over-amplified on InfoQ, love to claim having discovered the next "magic bullet"... but after decades, we all know how things pan out. Nothing beats understanding what you are trying to accomplish and use the proper tool(s) for it.
Opinions are cheap, and make sure you understand you use them at your own risks.