That's because we like to create applications, not program computers. Memory management is programming for the sake of programming, it doesn't do anything user-visible. The computer can do it automatically, so why pass it off to the human?
(Also, C does have automatic memory management. Ever "free" anything you allocate on the stack? I thought not.)
By the way, I'm actually fairly young myself (23), but I've always loved the down and dirty, close-to-the-metal details of programming. And I also have the soul of a 50 year old (a la: "I need a lawn so I can yell at kids to stay off it." http://xkcd.com/479/).
OK, sure, I agree.
> Just because a platform manages memory management doesn't mean you can create 1 million objects.
Yes, you still have to watch out. Only your example is not crass enough. A million objects does not have to be very much. And e.g. a Haskell program compiled with GHC can churn through a Gigabyte of memory in a second (see http://blog.interlinked.org/tutorials/haskell_laziness.html), and this isn't a bad thing. (As long as the memory is immediately reclaimed, and you do not actually use the whole Gigabyte at once.)
Why is allocating your own memory in Objective-C "better" than letting, say, GHC, do it for you? I may be a young whippersnapper standing on your lawn, but my programs run as fast or faster and are more reliable. And it takes less time to write them.
Here's the disconnect I'm seeing: Allocating your own memory in Objective-C is not necessarily better. But all other things equal, a programmer that understands how GHC manages memory is better than one that does not. You're arguing the utility of this knowledge, as it pertains to your usual use case, is minimal. This is not the same as saying that the utility of this knowledge is minimal.
Sure, but I never said this. The original post, now many levels up, said "kids bitch about how hard it is to manage memory". It is hard. That's why people bitch about it, and don't want to do it.
I say that it's conceptually very simple. But in practice, it's very difficult to type the code to do this yourself at the right place. (It doesn't sound difficult, but most C programs either leak memory or use memory they didn't allocate, so clearly it is difficult.) There is a reason why C++ has things like the boost pointer library (and even auto_ptr). It's because memory management is for computers to do, not for humans to do.
I think people have trouble realizing that a human can know both "high-level" and "low-level" things, but that a programmer needs to stick to one level or the other -- don't write low-level concepts (memory allocators) in your high-level application program. The same person can write both parts, but the programmer writing the high-level app shouldn't be worried about the low-level details ("of course it works"). When you mix the levels of abstraction, you write bad code.
(I wrote a toy language once. I found that writing a garbage collector was much easier to get right than manually managing my own memory. When writing the collector, the details of memory allocation was all I needed to think about. When writing the high-level application code on top, all I had to think about was my high-level application. That's the whole point of abstraction, and it's what C-level languages fail to provide.)
Having used lots of languages and frameworks I think that Cocoa/UIKit is very elegant despite the manual memory management.
It might even be true that most of the big Cocoa applications will continue to use manual memory management.
Maybe the ageism thing is more of a lack of understanding on both sides than a directed bias against only the older people?
I'm not trying to say that young people won't end up being better programmers in 10 to 20 years; if that weren't the case, there'd be no point in pursuing it as a career. However, to assume that comparative ignorance at 20 is the same thing as global ignorance is unfair.