I think part of what might be going on here is that OOP patterns incur a large upfront cost in complexity, but the hope is that it will payoff later when it com

I think part of what might be going on here is that OOP patterns incur a large upfront cost in complexity, but the hope is that it will payoff later when it comes to maintaining and extending the code. For example, the visitor pattern he talks about might seem needlessly complex. Why scatter the logic for a recursive tree traversal across several classes when I could do it here, all in this one function? The response, of course, is that once the program starts to grow, and you want to write other modules that traverse that same structure, you won't have to copy and paste that same logic everywhere. Simply write another class that conforms to your visitor's interface. So, this reduces code duplication, and decouples the operations your performing on the tree, from the way that you're traversing the tree. Another issue is that static type systems often make OOP design patterns seem more complex than they really are. Compare, for example, Python's visitor (http://pythonwise.blogspot.com/2006/06/visitor-design-pattern.html http://pythonwise.blogspot.com/2006/06/visitor-design-patter...) with Java's (https://en.wikipedia.org/wiki/Visitor_pattern#Java_example https://en.wikipedia.org/wiki/Visitor_pattern#Java_example). Python simply uses reflection to pull out the right visit method. This is almost a one-liner. Java, on the other hand, needs a complex double-dispatch setup to please its type system. Now, I'm not saying that Python's approach is better. There's a trade off involved, and, in fact, it's the exact same trade off as before. Python's approach is simpler at first, but, once your program starts to grow, you might find that catching type errors at compile time is a very handy feature indeed. Also note that functional programming isn't without its seemingly complex design patterns. Monads are the obvious example, but there are many more: http://www.haskell.org/haskellwiki/Category:Idioms http://www.haskell.org/haskellwiki/Category:Idioms