Totally agree that generics in objective c are very bare. And that's what frustrates me the most. Apple/Lattner could have improved them, but chose not to, by focusing all their energy on Swift.

"Simple" things I want from generics:

1. Carry over generic information from header files to .m files, and not force us to drop all type information by having to use "id".

2. A compiler flag to enforce that the generic type must be specified at usage.

3. Where clauses in generics: Foo <T where T : NSCopying, MyProtocol>>

4. Generics on protocols, ideally with all the other features.

I know some of these are not trivial to implement, but they are mostly new syntax and hence don't have backward compatibility issues (except #2 which is why I asked for a compiler flag).

I wan't to ask in all seriousness, or in all ignorance—I don't mind, so please take your pick—why generics are so important. Let's say, in the first case, you have an NSArray in Objective-C. The object in the array is of type id. Now, in the second case, you have an NSArray, but you've declared that it will only hold types of NSString. Why is the second any better?

I ask, because the only way I could see it being better is if you're taking that array—that data structure—and passing it all over the program and using it everywhere. (Note to the literal-minded: this is hyperbole.) If that's what you're doing, that's not Object-Oriented Programming.

If you're instead doing real OOP, you're designing an object that will perform a clearly circumscribed bit of work for you by responding to a set of messages. The NSArray may live inside that object—in other words, the object is composed in part by using an NSArray—but that array is hidden from the rest of the program.

Generics are no big whoop-di-do in that case, because there is no client-programmer that has to worry about them; or, to put it another way, you—the original programmer—only have to worry about that NSArray with respect to the programming of that one object. In that case, the data type the array holds is not a big deal to keep track of.

So, again—seriously—what is so great about generics? The whole point of Objective-C, originally, was that it was late-binding—which, if you ask Alan Kay, was the point of OOP in the first place. If you're worrying about types all over the place, you're doing something wrong, no?

Your array of NSString example has little to do with generics. Instead think of a class that contains an NSArray, and has methods to do specific things to the array items, for example a sort() method. Using generics you can define the array values to match the type given when the class is created. So the same class could contain NSStrings, UImages, UIControls, etc, etc, and sort accordingly.

Alan Kay’s ideas are very interesting and Smalltalk introduced many groundbreaking ideas that still inspire programmers today. But there’s no fundamental law of nature that says dynamic message passing OOP is the “right” way to approach OOP, or even that OOP is the best paradigm for many coding problems developers face today.

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.

And even Smalltalk had many ideas from FP, like blocks (closures) and the collection messages similar to what modern developers know as LINQ.

For me, the big deal about generics is that they allow the type system to cover a much bigger part of my design. Without generics, any parametrized API will erase your types and then the compiler is blind. With generics the type information is preserved and when I specify a parameter type, somewhere several API layers away a type is suddenly fixed, too. That gives me a warm feeling (and code completion, too). And since expressive static type systems seem to be the right way to go, allowing the type system better insight into your code is a big win.

I don’t understand how you think this should be implemented. Many classes informally conform to protocols or in some cases the conformance can only be checked at runtime with a respondsToSelector: check. So any generics at compile time stricter than what we currently have will just not work or be useful.

Not useful as I’d rather find that mistake when a customer reports the crash, instead of having the compiler tell me?

The point I'm making is that the compiler can't tell you this, since conventional Objective-C code does generics checking at runtime. There's just not enough information available for this to be reliably diagnosed.

A fundamental problem with Objective-C generics that cannot be addressed in an additive manner is that generic parameters just desugar to ‘id’; you cannot use Objective-C generics with C types and you still pay the performance and memory use cost of trafficking exclusively in class instances. This of course was the right trade off, since it allowed generics to be layered on top of existing types like NSArray without either changing their implementation or breaking existing client code. However, when designing a new language with generics built in from the start you can make much better design decisions.