The problem isn't that those principles are bad - they're useful - but the languages we're attempting to use them from are not sufficiently expressive enough to

The problem isn't that those principles are bad - they're useful - but the languages we're attempting to use them from are not sufficiently expressive enough to follow them all in a practical way. "Design patterns" and DRY don't mix very well - because the act of implementing a design pattern is largely repetitious. We create XFactory, YFactory, ZFactory for example, with largely the same structure but slightly different logic - then someone takes DRY to the extreme and tries to abstract it away into a FactoryFactory, using reflection or some other tool to get around the host language's lack of expressivity. This is where the mess begins, because it becomes so cryptic to figure out how to use the FactoryFactory to create your own Factory to create some other types you need. It may be trivial to people who've been hacking with the same languages and frameworks for years, but the principle of least surprise is abandonded for new users attempting to use a framework for the first time. Functional programming suffers from the same overuse of idioms which are unwelcoming to novices, and often throws away some useful ones in favor of ease of use. FP doesn't necessarily dismiss OOP, and it's often used in combination with functions to write practical programs. Functional programmers don't see OOP as a problem - it's a very practical tool. The problem is that it's the wrong tool for many problems - particularly if you're just computing functions[1]. That a lot of developers are proficient with OOP and see it as a good way to develop programs is part of the cause - they're blind to alternative methodologies and shoehorning something into an object where it doesn't fit is seen as a being skillful. Also, anything that doesn't conform to the language's narrow view of "the right way" is considered an anti-pattern. [1]:http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html http://www.yegor256.com/2014/05/05/oop-alternative-to-utilit...