As some of you know, I am a great admirer of NextStep and many of the things that got developed out there. I’ve also played a bit with GNUStep, and liked it, so Cocoa would naturally end up as my framework of choice. Right?
Um, wrong. Actually, after sorting things out lately and unsuccessfully dealing with a rather trivial project (a syntax-highlighting editor which surely isn’t too much of a big deal), I reviewd my reasons. I will not be using Cocoa for my next project because:
- Objective-C is such a mess. I like some of the things (no multiple inheritance is such a relief when working with someone else’s code), but there are things that don’t belong here. I can understand the dynamic typecasting (and, since I shit on compiler warnings every few minutes, it cleans up my compile logs), lack of multiple inheritance and lack of private methods. I can appreciate runtime access to instance variable names and classes, but there are things I do not understand or appreciate. Like, why are there not any private methods? Why the stupid differences from C++, such as the fact that class definitions end with a semicolon in C++, but not in Objective-C (yes, this should be Objective-C’s greatest achievement)? Smalltalk is a great language, but did we really need to borrow its message passing (cough, method calling) format instead of sticking to the one virtually anyone but language experts were using?
- No C++ bindings. This truly baffles me since Objective-C is actually blatantly similar to C++. In fact, you can actually mix C and C++ (a thing called Objective-C++), but this is so limited that it’s hardly useful in most sittuations. Funnily enough, Apple though that some programmers wouldn’t like the switch to Objective-C. Which is why they added Java and Python bindings to Cocoa. Am I the only C++ programmer who is less likely to switch to Java than Objective-C? Funnily enough, I was able to use Lua and Oberon without these hassles — but Java is not for me and Python is for scripting.
- Xcode. I innitially thought that the stupid amount of times Xcode froze was because of my Hackintosh. But no, even people who own real Apples have the same problem. Xcode is so unstable that it’s barely usable. I had to turn off predictive compilation so that it didn’t freeze every time I built something. And then do a clean compile each time, or else every second compilation would result in a freeze. Random crashes when using CodeSense add to this. This is a shame, since Xcode has a lot of other things I like, mainly the great resemblance to Metrowerks CodeWarrior, but I can’t use an IDE that I have to restart every 1 hour in the best case.
- Monopoly. Cocoa is simply as portable as… what, the Win32 API? Even less, Win32 API has Wine. Writing a Cocoa application would make it run on OS X and, with some luck, on a GNUStep platform. Hmm, I wonder how many Linux/Unix users even <i>heard</i> about GNUStep, let alone knowing what the heck it is.
- Cumbersomness due to Objective-C. If I had to write a class that retains a calendaristic date, it would obviously cross my mind that, at a certain moment, people would want to compare two date objects. So I’d just overload the == and != operators, which would take a few lines of code. Well, surprise, surprise, Objective-C doesn’t support operator overloading. Therefore, comparing two instances of NSDate requires you to use the compare:anotherDate function. Which would return a bool, correct? Actually it returns a NSResultComparison. Extra checking goes here. Wtf?
- Crappy name. Carbon sounds so much cooler.
Frankly, it’s a shame, I really did like some things about Cocoa (including its mind-blowing completness that really makes it so much easier to do some things). Unfortunately, some things just don’t go.
What next? I’ll probably return to Qt, since it has an excellent support for OS X (as well as Unix/X11 and MS Windows) and uses C++. It’s not that I love C++ (in many cases, I’d actually use C if I had the choice), but Objective-C simply tries more than it should. Instead of resolving some of C++’s flaws (like C# does, and quite well frankly), it adds some of its holes.
No comments yet.
