> What if one creates a multi-purpose class? How is that any better than a multi-purpose function?

Easily answered -- look at a class meant to deal with String objects. It encapsulates a string object plus any number of functions that deal with strings. Compare this to a function that does to a string what a class does, but necessarily under the command of a passed flag that instructs it which action to take. The latter is much less satisfactory from a comprehensibility standpoint.

I say this because I was programming before there were classes, or anything resembling high-level structure (I wrote Apple Writer in assembly language, a language utterly lacking in structure: http://en.wikipedia.org/wiki/Apple_Writer), so I've watched a number of revolutions in programming over the decades. The idea of a class associating a data type and functions meant to deal with it seemed to me to solve any number of problems -- problems I had to deal with in various clunky ways before that development.

> I disagree there (that "That's a good argument in favor of OO programming").

But it is. The idea that all functions having any special meaning to (for example) strings would be enclosed within an object also containing the string to be operated on, greatly reduced the confusion that preceded it. One can make too much out of the OO paradigm, but the basic idea is sound and based on pragmatic thinking.

I'd like to clarify my point -- I'm not arguing against OOP or for another paradigm. What I'm saying is that "do one thing" transcends paradigm. And in fact, its OOP incarnation is known as the single responsibility principle (http://en.wikipedia.org/wiki/Single_responsibility_principle). So when I say that "I disagree that 'do one thing' is an argument in favor of OO programming", what I'm saying is that "do one thing" is important, no matter which paradigm you choose. Neither OOP's strengths and weaknesses nor how it compares to any other paradigm are relevant to my point.

I'm sorry, but saying things like but it is and the basic idea is sound and based on pragmatic thinking without a supporting argument is unconvincing.

Behind the scenes using a method of an object is just syntactic sugar for calling a function with the object as the first argument. The modularity aspect is good but I think OO often leads to code that is difficult to read when there are many levels of inheritance, esp. in languages where you are forced to put everything in classes such as Java. Instead of the old spaghetti code you then get ravioli code: http://en.wikipedia.org/wiki/Ravioli_code#Ravioli_code

To me, one of the advantages of objects is that I can tune the object's functions and data structures to get the behavior I want, then while working at a different level of abstraction, I only need to remember the object's interface, not its internals, which makes it easier to use its abilities in a consistent way.

I agree with this advantage, that's what I meant with "the modularity aspect"; a non-OO programming language with support for modules also offers this. However, as soon as you get to non-trivial and often gratuitous inheritance hierarchies, it gets in the way of at least readability and probably also maintainability. Example: instead of String, you get AbstractMutableStringOfWesternCharacters, all the way to ArrayBasedStringOfASCII and everything in between. Suddenly to understand one function, you have to read and understand n classes, because they are part of the inheritance chain.