I should hope it'd be obvious to most people that you don't actually need all of OO just to get that little bit of syntactic sugar. I'd also like to point out another obvious fact: this idiom completely breaks down when the subject happens to be more than one person, i.e: steve_and_irene.drink(water) whereas it works fine in the procedural case (thanks to varargs): drink(water,steve,irene,...).

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.

This is correct. OO codifies the pattern of having a struct and a set of functions that operate on it. The syntax does help humans reason about that pattern. But my understanding is that the goal is more about the human limitations of managing large code bases than the human limitations of language.

OO is all about encapsulation. We tend to decompose a program into chunks for different teams and individuals to work on. Software development is a distributed task. Encapsulation means when you code against components written by other people, you only have to understand the public API that they provided. You are supposed to be guaranteed that that API will continue to work even as the code behind it is updated. As component users we can focus on our own task and not worry so much about the details of the component. As the author of a component, we can hide state from the users. That can't be done with structs. we can make updates and switch out implementations without (as much) fear of breaking the code that depends on it.

It's really all about being able to modify code more safely on bigger teams.

In my mind the issues that OO introduces are: * Encapsulation results in more verbosity for the same functionality. * Inheritance takes more thought. * OO as a whole is more complicated and has a bigger learning curve. * OO used incorrectly will magnify the first two points greatly. Given the learning curve I imagine a lot of people don't use it fully correctly.