> 'Right tool for the right job' 'No silver bullet' 'Bad programmer write bad code' Those are all good tools to stop thinking/progressing and being comfortable

> 'Right tool for the right job' 'No silver bullet' 'Bad programmer write bad code' Those are all good tools to stop thinking/progressing and being comfortable ever after. But no, everyone knows those and they're not the answer to the question. 'No silver bullet' could only be true when accidental complexities are very small compared to core complexities, but it's far from the truth for nowadays industry. OOP is bad because it's a foot gun. It forces people making strong assumptions by default. It's only a tool modeling static and mid-sized scale problem. When the assumption is very strong it means behaviors in a class are strongly coupled, its relation to other classes are static and specific. And that's why people feel OOP is more understandable and readable - because OOP toys are very specific, thus readable. And it's very vulnerable to change. To deal with that, people have to make less assumption, but every technique doing that have serious trade-offs - people have to choose. And those techniques are where all those obscure 'AbstractFactoryBuilder' came from. For the same problem, 10 people tend to have 10 different trade-offs, using different obscure solution, and 8 get burned in the next release. For example, to modeling the concept Payment, in a mediocre functional programming language, it might be an algebra data type: type Payment = FreeCoupon | Cash Amount | CreditCard Number CVV Every time you want to process a payment, just handle the three possibilities concretely, if there's duplication just extract it. If there are 100 functions operates the Payment type, it's perfectly fine just like Alan Perlis described. The type is perfectly natural - just what it should be. There is a very high chance people yielding the same result independently. In so-called OOP, this probably be: class Payment getFoo() getBar() doBaz() class FreeCoupon extends Payment class Cash extends Payment class CreditCard extends Payment In order to accept Payment type, you have to bend three sub-classes into the Payment interface. And there probably 100 methods for Payment, and the refactoring result would be totally opinionated, everyone has their own idea but none of them solve it without introducing new problems.