Hacker News Reader

Comment by orangecat | Hacker News Reader

And don't get me started on those lazy kids and their assemblers. I mean, how hard is it to remember a few dozen opcode hex values?

Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface.

For example, Angry Birds on the Galaxy Tab versus Angry Birds on the iPad are no where near the same experiences. The Galaxy Tab is jerky and slow, while the iPad is smooth.

The Android code for Angry Birds is primarily in native code, so garbage collection is unlikely to be the cause of your observations. And it's perfectly smooth on my Nexus One.

View on HN

How is the most ignorant comment in this thread voted up?

First of all, he offers no evidence that memory management in objective-c is resource or effort intensive. He can't, because it's not. This is not hard:

    -(id)initWithSomeNumber:(NSNumber *)aNumber {
        ...
        someField=[[SomeObject alloc] init];
        someOtherField=[aNumber copy];  // or retain, your call.
        ...
    }

    -(void)dealloc {
        [someField release];
        [someOtherField release];
        [super dealloc];
    }

How is that hard exactly? There are only 4 rules you need to follow for memory management in Objective-C/Cocoa/CocoaTouch:

* If you use a convenience method, eg [NSString stringWithFormat:...] you don't own it, so don't release it.

* If you use alloc, copy or new, you own it, so release it.

* Implement dealloc to release fields you own.

* Never invoke dealloc directly.

I mean you can be as snarky as you want dude, I write Cocoa apps all day long (as well as web apps and mobile apps) and I can tell you and the original poster, are either idiots or lazy. I'm going to go with lazy.

It's totally about laziness! But that's what computers are all about -- I could store printed versions of all of my documents in a filing cabinet, and go and manually sort them every time I needed a different ordering, but I'm lazy! I use a database!

I just don't see why laziness should be restricted to users. Developers are lazy too.

You're right that there are only 4 rules (or more or less depending on your formulation), but I don't care. I'd rather take the time to have another martini. Or, y'know, implement features that make my users happy.

And it definitely gets harder when there are more moving parts. You're right that the rules are simple, but the execution of those rules gets more complex as you add more components, more threads, remoting, etc. I never said it was impossible, or up there with Fermat's Last Theorem or anything like that. Just that this is work the computer could be doing for me. I want to be lazy, but Apple won't let me.

I've written memory managers used in console games for the N64 (4Mb), PS2 (32Mb) and a complete memory tracking system for Unreal Engine 3 on XBox360 (OMG 512Mb).

I use MonoTouch for iOS development. Why? Because I can build complex object graphs without having to maintain, in my head or in external documentation, the acyclic version of the graph. In a GC language I can create graphs that are happily cyclic, and have every reason to be, and yet have them deallocated when the application nulls the last reference.

In a reference counted system that desires cyclic pointers, one or more of those pointers have to be chosen as non-reference-incrementing pointers - and likewise one must remember not to release them either.

Memory management in Objective-C (without GC) is no effort provided one is making applications with simple object interactions, such as the plethora of tree-based hierarchies. Reference counting is great for that.

So it could be that the OP is lazy, or it could be that they have experience with problems that you do not. If you believe that OP actually requires a lesson on the basic rules of reference counted memory management (since thats what you provided) then I suggest that you are underestimating the experience of your detractors, which in turn leads me to believe that you are overestimating yours.

This is very well put. Much more insightful than my glib comments below. Thanks dude!

Memory management is Obj-C has issues. The documentation is spotty at explaining how to property handle it, or maybe it is an issue with the organization of the documentation cause I can't always find what I need, but I know it is there. When I started, I keep hearing the general rule of thumb, "if you don't alloc/init it, you don't need to release it." Except no one mentioned you have release properties. I never alloc/init them. Along with that, difference between an ivar and property is poorly documented. The fact that "aField = x" is different than "self.aField = x" and can mess up memory management was lost on me.

My problem with the documentation, as I said before is mostly organization. Along with that, some of these concepts are defined in ways that only make sense if you already know the language and framework.

After a couple projects and code reviews, I think I understand it now. It is not that we are lazy for not understanding or liking it; it is that it isn't intuitive or simple like GC.

If your property is defined as retain in your header, you are claiming ownership for it and so it needs to be released in your dealloc method.

This is covered in the basic Memory Management doc http://developer.apple.com/library/mac/#documentation/Cocoa/...

I love Obj-C dearly. But Obj-C's reference counting scheme is, and always has been, much more cognitive load than a GC. In Java the above would be roughly:

    public myObject(Number aNumber) {
        someField = new SomeObject();
        someOtherField = aNumber;
        }

...and that's it. No dealloc, no forgetting to release, no forgetting to retain objects you hold onto, no trying to figure out how to handle cyclic references (or indeed if certain references are cyclic at all). Just set it and forget it.

This isn't rocket science. The linked document takes all of 10 minutes to read and understand. If that is not enough, there are three years worth of WWDC sessions on memory management available on iTunes U (this year's are even free!). It's something as basic as learning a new language's if/else structure.

For reference, I'm a five year Java dev who has now been doing iOS dev for two years, and had no problem switching from GC to manual memory management.

I wasn't talking about the Nexus One, I was talking about the iPad vs the Galaxy Tab. And I didn't say that GC was what was slowing down Angry Birds, I was talking about subjective relative performance between Android and iOS.

The point of my criticism is that memory management in objective-c doesn't take any extra time beyond overloading dealloc and writing a few more retains and releases for 90% of all cases. It's just plain lazy, imo. Your comparison to writing raw assembler is nonsense and ignorant.

memory management in objective-c doesn't take any extra time beyond overloading dealloc and writing a few more retains and releases for 90% of all cases

It's the other 10% where the memory leaks that bring down your app come from.

Reply on news.ycombinator.com