Okay, the context of the reply to which I was initially replying to was about how the implementation of generics in Objective-C was "very bare." I'm beginning with this point, because though I agree with your second point about OOP perhaps not being necessarily "the best paradigm for coding problems developers face today," I don't quite see where that point fits in. We're talking about Objective-C, which means we're talking about OOP. If you want to explore some other kind of programming paradigm and insist that generics are needed there, I have no quarrel with you. My point was that I didn't see why generics were needed in OOP.
But that brings us to your first point: namely, what is the "right" way to approach OOP.
When I bring up Alan Kay, I'm bringing up a guy who was there at the start, and who set his stamp on OOP. Granted, "OOP" has been done in different ways. You'll note, however, my use of scare quotes. Allow me to explain.
When OOP had the misfortune to become a managerial buzz, somewhere back in the 1990's, and thus became a "must-have," what happened was a lot of procedural programmers simply took their procedural programming, wrapped in in C++, compiled it with a C++ compiler, nodded to the boss and assured him that they were doing OOP—and went along on their happy way.
Likewise, when college professors—set in their ways, as is their want—were told that they had to start teaching OOP, they largely did the same thing.
The result is that we have lots and lots of people out in the world "doing OOP"—who actually aren't. They're writing procedural programs, with the trappings of classes and sub-classing and what not. But all over in their programs, they are digging into the internals of their classes—and, sometimes, you see them digging in many layers deep.
And they're "doing OOP."
As I understand him, Kay is saying that you send a message to an object, on the understanding that the object will handle the message, the sender not having to worry about the ultimate who or how. If there's another kind of OOP other than that—or other than the travesty I described above—what is it?
But, that's another question, entirely. My original question was: why are generics such a big deal in OOP? I don't believe that's been answered.
But that brings us to your first point: namely, what is the "right" way to approach OOP.
When I bring up Alan Kay, I'm bringing up a guy who was there at the start, and who set his stamp on OOP. Granted, "OOP" has been done in different ways. You'll note, however, my use of scare quotes. Allow me to explain.
When OOP had the misfortune to become a managerial buzz, somewhere back in the 1990's, and thus became a "must-have," what happened was a lot of procedural programmers simply took their procedural programming, wrapped in in C++, compiled it with a C++ compiler, nodded to the boss and assured him that they were doing OOP—and went along on their happy way.
Likewise, when college professors—set in their ways, as is their want—were told that they had to start teaching OOP, they largely did the same thing.
The result is that we have lots and lots of people out in the world "doing OOP"—who actually aren't. They're writing procedural programs, with the trappings of classes and sub-classing and what not. But all over in their programs, they are digging into the internals of their classes—and, sometimes, you see them digging in many layers deep.
And they're "doing OOP."
As I understand him, Kay is saying that you send a message to an object, on the understanding that the object will handle the message, the sender not having to worry about the ultimate who or how. If there's another kind of OOP other than that—or other than the travesty I described above—what is it?
But, that's another question, entirely. My original question was: why are generics such a big deal in OOP? I don't believe that's been answered.