This article doesn't take a fair look at where the "wars" come from at all. In my experience, the wars come from people wanting to be productive in a language

This article doesn't take a fair look at where the "wars" come from at all. In my experience, the wars come from people wanting to be productive in a language but not feeling productive in an unfamiliar paradigm. It's a social problem that needs a social solution -- and the solution isn't to tell people to "reject purity." The skills and mental habits required to be productive in a given language and paradigm take time to develop, and different paradigms can have substantially different library ecosystems, even in the same language. In a language that supports multiple substantially different styles of programming, choosing a style has implications for short and long term productivity as well as programmer morale (maybe drastically different morale consequences for different programmers on your team.) Most people won't remember, but there was a time in the 1990s when there were a lot of professional programmers who were not comfortable with OO. In a codebase, you'd get fights between people who embraced classes and utilized dynamic dispatch and people who didn't see the point of those things and were able to be extremely productive without them. Now there are a ton of professional programmers who are not comfortable with FP, coexisting in the profession with programmers who have fallen in love with type classes and use them habitually to solve every problem. It's a massively unjust cop-out to tell the former that they need to "reject purity," as if it's a moral flaw they need to fix. It's a long process of learning new skills and concepts, during which they will not be performing as accustomed at their job. People who balk at that are not just narrow-minded. People who focus on present productivity rather than future productivity are often the people who are getting the most work done, and it's important for an organization to figure out a path forward for the entire team before letting a new paradigm loose in the codebase. Moreover, it's legitimate to ask if the short-term consequences will be balanced out by long-term gains. Also, as a response to the article trying to mix design patterns into the argument, if people want to make design patterns a thing, the idea needs a complete relaunch. Convince me that they're worth the effort. In my twenty years of experience working with other programmers, programmers who know design patterns are not better programmers than those who don't. I don't feel any less capable having 99% forgotten them. Most importantly, younger programmers who never bothered with them are just as good at structuring code as those of us who worked through the GoF book during our formative years. My opinion: just let it go.