(C# and .NET) vs. [Objective-C and Cocoa] – Part I

I’ve been writing .NET applications and websites for a long time, but recently I started developing Cocoa applications for both Mac and the iPhone. This Ars article made it seem like Apple had done a lot of great stuff with Cocoa, so I was excited to begin.

My first impression was confusion: Objective-C is very different from C# (both syntactically and functionally), and Xcode follows a pretty different model from Visual Studio 2008. Here are my thoughts:

C# vs. Objective-C

Messages

At first I was shaken by the syntax of “sending messages” instead of “calling functions,” but I got used to it pretty quickly.

C#: object.doSomeFunction(par1, par2);
Objective-C: [object doSomeFunction:par1 withThisOtherParm: par2];

In fact, the very long, Hungarion-notation method… err, I mean message… names are quite useful sometimes, and having to name the parameter name even when sending a message definitely increases readability:

C#: theBook.flipPage(4, true, false, true);
Objective-C: [theBook flipPageTo:4 andAnimate:YES

Certainly, it's much easier to figure out what the second line is doing, without having to check the definition or documentation.

Header files

In Objective-C with Xcode, the convention is to have the interface of a class in a "Class.h" file, and then the implementation in "Class.m".

I'm not sure if you need to have header files for each class you write, but they are definitely the convention, so it's "good" to have them. They are, however, complete overkill for small applications that I want to write quickly. And the problem is that Xcode doesn't manage the connection between ".h" and ".m" files, so if I change the return type of a method, I have to change it in 2 places. It's not a big deal, but it's pretty annoying when I'm not even using the interface for anything.

Memory Management

Objective-C is definitely more C-like than Java-like. On the other hand, C# strongly resembles Java memory management. Just look at these examples:

C#:
Object obj = new Object();
//No need to release or deallocate after
Objective-C:
Object* obj = [[Object alloc] init];
[obj release];

I’m amazed that only the most recent version of Xcode (Xcode 3.1) has memory management so that you don’t have to [release] or [autorelease] any allocated objects. The problem is: no garbage collection for the iPhone! It’s ironic that Apple is putting all this attention on how to make iPhone native apps run smoothly in the environment (no background processes, etc.), and yet they didn’t add garbage collection to the iPhone development environment!

Not only has C#/.NET had garbage collection since I started using it, it is ubiquitous, and not something you even have to think about. In Xcode, however, the option to turn on garbage collection (yes, it’s off by default), is buried in Project Settings > Build (and you have to search for “garbage” to even find it).

I know a lot of people love micro-managing their memory, but I believe that in a real development environment where performance is not primary (like games or mathematical applications), it’s simply a waste of time to think of memory management. The garbage collector does a very good job, and it’s just one less way to make fatal and mysterious bugs (or worse: silent bugs that quietly erode your application’s performance and your user’s computer).

Again, I was very disappointed to learn that garbage collection was a “new” thing to Objective-C/Cocoa.

[To be continued...]

[Very late edit on 9/25/09 in response to df's comment]

It’s not about knowing how to micro-manage memory. Not that I have to defend myself, but I did write a basic but operable operating system in C. It’s about not wanting to do that when optimizing memory is not my goal; instead, writing a usable app is. And the performance hit in C# is not noticeable, again, when maximal performance is not needed.

Advertisement