Cocoa & Objective-C: the good, the bad, and the extremely ugly August 13, 2008
Posted by Wille in Software Development.trackback
I’ve been spending a fair amount of time in the last week getting up to speed with Objective-C and Cocoa programming, with the view of developing a couple of Mac- and iPhone applications.
I’m by no means an expert yet, but I think I’m starting to get my head around the fundamentals of it, and coming from a Java background I find quite a few things puzzling..
It’s quite obvious Objective-C is a lower level language than Java, and some of the things it does are in my opinion pure abominations, lets start with some of the things I dislike:
- “Informal protocols”: Protocols in Objective-C is what we in the Java world know as interfaces. However, it has two types of protocols, formal and informal. The first type would be pretty much equivalent to a Java interface. The second type, well.. There is no way to force or assert that an informal protocol is actually implemented, it effectively only requires your object to respond to a given method signature, most of the time copy-pasted from the documentation. Argh!
- Very, very loose typing in “messaging”: calling a method is called “messaging”. When you send a “message” (invoke a method) you don’t actually have to know whether the method exists on the target in the first place, if it doesn’t the call will simply fly out into the void and the code will happily continue executing. This can cause some very frustrating issues during development time.
- XCode does a lot of “black magic” you can’t get at: If you decide to fully leverage XCode (the IDE), you can get a lot done for you. Only problem is, if it doesn’t have the expected outcome you can be stuck, to my knowledge there is no way to get at the core of this, other than through the point-and-click tools.
The things I do like:
- Reasonably productive: I’d rather work in Objective-C than with something like Struts in Java. Despite some arcane behaviour, with XCode, it is actually quite a productive environment.
- Apple’s Frameworks provide a lot of the basic plumbing – anything you could think of wanting to do, Apple has thought of providing the building blocks for you. The frameworks are very thorough and well thought out, it’s just a matter of learning how to leverage them.
I guess on the whole, my biggest issue with Objective-C and Cocoa has more to do with my personal background than Objective-C itself, the dynamicity and loose typing of the language, which are conscious design decisions, drive me up the wall coming from a Java environment.
Objective-C feels like a compromise between Object-orientation and scripting to me, but that’s probably the point.. Being from an environment where the compiler catches a lot of your potential mistakes, this can be a really contentious issue getting past the learning curve.
Personally, I’m not about to give up – I’m getting the feeling I am just on the cusp of being able to become really productive in Objective-C and Cocoa, and I already have a few ideas for applications I’d like to make.
Yes, it is your personal background which is to blame for at least the first two ‘dislikes’. This behavior is typical of, no, it is the norm for dynamic languages like for instance Ruby or Python.
I’d agree that my objections about the dynamicity of Objective-C probably has mostly to do with my background in statically typed languages, rather than any inherent flaw – it’s just an opposite design decision compared to Java..
But informal protocols? That is one thing I cannot see any sort of redeeming quality for (if it’s a protocol, make it formal!). It makes code very hard to read, refactor and debug..
Obj-C uses late binding and is therefore much more like smalltalk than C++ or Java. This late binding allows you to do some really interesting things, you can see some of that going on in CoreData.
Informal protocols remove the need to implement every method in a protocol/interface. This means you don’t have a lot of empty methods cluttering your code. The caller in this case should use respondsToSelector: rather than assuming and sending the message anyway. It places more of the work on the library than on the user, which is the way it should be.
Jason:
Yes, I started looking into Core Data yesterday, and some of the things you can do are really impressive.
What really blows me away is that some of the things the Frameworks provide are way, way beyond anything Java can give you, with or without additional libraries – Java is so verbose in this aspect compared to Objective-C.
..also, as for “informal protocols” – how I would usually do this in Java is to have very small, minimal interfaces, so there aren’t lots of dead methods. If you want more stuff in your interfaces, just extend or compose existing ones into larger ones.
Hi,
One thing you might like to consider is using static typing for objects. Instead of using “id”, you can use the actual type (similarly to java) and the compiler will flag messages that the target won’t respond to.
e.g
instead of
id testObject = [[Test alloc] init];
use
Test* testObject = [[Test alloc] init];
and you’ll get warnings for messages that the Test class doesn’t respond to.
Angus – thanks for the tip, pretty much what I’ve been doing, good enough a compromise for me, as I’m still yearning for the safety blanket of static typing.
One other thing that is interesting regarding late binding is that it makes a lot of the stuff that Interface Builder does possible. Interface Builder is often underestimated, it is way, way better than other user interface builder tools.
Visual Basic set a very bad example with it’s tendency to put logic in the onClick handlers etc. Really, really ugly code.
Then Java came along with code generating interface builders that build really ugly code that was hard to maintain. All through this (since about 1989) Interface Builder was doing a great job on allowing you to build an object graph in memory that was serialised to a nib file. No code to maintain. Plus the cocoa frameworks implment MVC well and encourage you to use that pattern, in a lot of the other frameworks you have to battle the framework to do MVC right.
I come from a Java background, but don’t mind Objective-C or Cocoa. What I don’t like is the terrible autocompletion that XCode provides. It needs to be provided in a drop down box, rather than as something that just tries to predict the next letters you’ll type. That’s very important because a lot of Objective-C object methods are very long.
Wille,
Thanks for your posts about Mac OS X development. It’s interesting to get fresh perspectives from a newcomer to the platform.
A little remark : you might have misunderstood the “loosely typed” aspect of Objective-C. When a message is sent to an object that can’t interpret it, it doesn’t “simply fly out into the void”. Actually, it raises an exception.
Also, in Java, static typing doesn’t get you type safety (unfortunately). Just think about what happens at run-time when you try to downcast an object to a class that doesn’t match the actual class of the object. You just get the same kind of run-time errors. Now that Java has templates downcasting is less frequently used, tough.
[...] Switch. Cocoa & Objective-C: the good, the bad, and the extremely ugly. Or, what it feels like switching from Java to Objective-C. Not a big surprise if you know anything about the history behind OS X. Like any other language made to make your life simpler, the dynamic aspects can be surprising at first, but end up making all the difference: What really blows me away is that some of the things the Frameworks provide are way, way beyond anything Java can give you, with or without additional libraries – Java is so verbose in this aspect compared to Objective-C. [...]
Interesting blog Willie thanks. I’m also using Java and have recently swapped over to an iMac at home so should get to grips with Objective-C.
I can understand the frustration with going from a static type to dynamic type but it also effects you the other way round. I used to develope in C++, then Perl and now Java. I learned to love the flexibility of Perl and really miss some of the flexible way of doing things because it wasn’t statically typed, however it also really used to bug (sic) me that the code was sometimes difficult to follow because of this and appeared open to misuse.
fuck me objective-c sucks compared to java… there are obviously lots of good stuff for neat UI functionality but for crying out loud, is it not time for apple to modernise!!