I've been in many such debates and Laynes Law indeed keeps rearing its ugly head. I've never found an agreement on what OOP really is. Flame wars often break ou

I've been in many such debates and Laynes Law indeed keeps rearing its ugly head. I've never found an agreement on what OOP really is. Flame wars often break out. We can point to a particular language and say "this is how language X views it", but that's limiting. As far as whether to use OOP versus functional, I'd also add imperative and relational into the choices, and say "pick the right tool for the job". RDBMS are powerful tools if leveraged properly that keep you from reinventing collection-oriented idioms in app code. However, picking the right tool for the job is hard to create clear-cut rules for. Experience matters, and so does the domain and team structure (Conway's Law). Further, I find OOP is very limited in languages like Java and C#. For example, why can't annotations be handled with the existing OOP engine? Why invent a new kind of thing rather than leverage or expand OOP? And why can't one attach an "on click" method to a button object? Instead, screwy lambdas are often used. If Java did OOP right, it wouldn't need lambdas for that. The "listener" object would be hidden away for the majority of UI coding: the UI coder shouldn't have to know or care about it 99% of the time. The guts are inside out. Finally, I often find functional hard to debug. It's easier to "X-ray" the intermediate steps in imperative and OOP. I know saying this angers FP fans, but I stand by it. Perhaps it's subjective, but I believe it's a big reason why FP doesn't expand more in practice despite being around for 60 years.