i've been exploring these ideas myself, and i sort of think everyone is asking the wrong question. its not OOP vs OOADP (or whatever), its a reflection on OOP a

i've been exploring these ideas myself, and i sort of think everyone is asking the wrong question. its not OOP vs OOADP (or whatever), its a reflection on OOP as it exists today, which for better or worse is mostly java. OOP in java is broken - not because an expert can't wield java effectively, but because someone with only java experience will probably not be able to learn effective OOP on their own, because the things java makes easy - the "opinions" of the language - are often not in line with the most elegant "mental" solution, due to things like no concept of mutability, excessive reliance on objects with state instead of functions on data structures. the things java makes easy become idiomatic, and the things that aren't easy become non-idiomatic... these driving forces create a feedback loop that creates an entire ecosystem of programmers and codebases that are decidedly crappy. Combatting macroeconomics problems requires marcoeconomic solutions; education at the individual level isn't sufficient, we need a way to shift the balance of the feedback loop by creating a mainstream language which influences people towards good code. Clojure, as you point out, has taken great care to have sensible idioms, Clojure is an awesome language in that simply trying to learn it makes you a better programmer, because Hickey has infused it with his opinions of what is excellent code. whether or not OOP can be done right isn't an interesting question. I'd rather ask what factors in modern mainstream languages are encouraging poor code, and whether its possible to learn from this and design a language/ecosystem that doesn't suffer from these problems. Scala & Clojure have this as a stated goal.