Which is great until you have to OO-ify `playWith(steve, bob, ball)`. OO dictates that one of steve, bob, or the ball, knows how these three interact, and that

Which is great until you have to OO-ify `playWith(steve, bob, ball)`. OO dictates that one of steve, bob, or the ball, knows how these three interact, and that it not vary with respect to the other two. Or `steve' is given to you from a 3rd-party library, and you want to imbue him with the ability also to eat. Well, you can't define `steve.eat(salad)', unless you subclass his class and make a proxy of the object from the library. To properly solve either of these, you are forced to resort to the second-class citizen of a static class, which is exactly just functions in a namespace. The one actual "benefit" OO gives you is run-time dispatch; the ability for the program to defer until run-time the decision which implementation of `steve' actually handles `.drink()'. Outside of OO's poster child of GUIs, I have rarely seen a need for this capability in 20+ years of programming. (Mere compile-time dispatch, as captured precisely by OCaml's module functors, is much more common.) Centering a paradigm around this rarity is quite bizarre.