Those are some good points, but let's talk about OOP for a second. Isn't it just a set of conventions with intuitive names? The principles are often not followed as is with inheritance, and the other principles are applicable to other paradigms. In contrast, FP in its strictest form (best form) is formally defined by lambda calculus and extended via category theory. I agree there is no comparison between FP and OOP, but in my opinion it's because OOP isn't really a paradigm but a set of conventions that "lower level" languages made popular by making these conventions first class.<p>I think FP is the best paradigm because it is so well defined, but the biggest problem that I'm seeing is that it's not enterprise friendly. It's hard to scale teams using pure FP, it's hard for managers to intuitively grasp the concepts which decreases "transparency" and shifts the control to engineers (and unfortunately that is not good for most companies). If the software industry shifted to using pure FP as its main paradigm, the benefits would ripple across all layers of software. UI's would not be so unreliable, apps would crash less and crash gracefully when it happens. Then there is the development experience where we would see unprecedented modularity and reusability, functions would be written once and the stack would grow without reinventing the wheel. But again, this doesn't happen because it would require companies to let their engineers have much more control than the leadership roles are willing to entertain. The complexity and esoteric nature of FP would prevent non-technical people from overseeing the process.<p>Using the wizard analogy, the ivory tower is both a source of magic and inevitable isolation.