In defence of Objective-C

An unashamed apologist’s perspective on the loveliest language i’ve worked with.

I’ve worked with a lot of programming languages in my time. Not a huge number, mind you, but enough that i can say that i’m open minded and seasoned about it. And, as they say: ‘Don’t feed the trolls’ – well, i’m about to do exactly that: feed the trolls at work who love to rag on about how awful obj-c is! So here i go, foolishly treading where no sensible man dares go: justifying why i love obj-c.

Ugly?

But it’s so ugly! Brackets!

This one is a fair point. Brackets aren’t the most beautiful thing in the world. However – you must appreciate that C++ / Java / C# style syntax isn’t the be-all and end all in this world, and be open minded enough to not reflexively storm out of the building whenever some obj-c code appears on your screen. Go and look at some Lisp, then come back – obj-c will suddenly look better :)

Trust me, it grows on you. You’ll soon learn to see through the brackets – just like the green vertical text in the matrix, it becomes invisible after a while.

Verbose?

You have to type how many characters to format a string? What the – named arguments?

A lot of people see two snippets of code and start worrying:

NSString *formattedString = [NSString stringWithFormat:@"I am %d more verbose than X language", someVerbosityMeasure];

Well, yes, string interpolation is verbose. But really, it’s only NSString stringWithFormat vs String.format which isn’t that big a deal.

People think that obj-c is verbose when they take a superficial look at the language, especially the named arguments. But if you look deeper you’ll find some things are beautifully succinct. For example, to filter an array is lovely:

filteredArray = [allRecords filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]];

Also, in the bigger picture, you’ll find that the structural verbosity of languages like Java is missing. Things like factories, adapters, and other design patterns are all thankfully not there.

Function calls look weird!

So, when I call a method, which part is the method name? And which is the parameter?

Named parameters will confuse you if you haven’t seen a language with them before. Luckily for me, I used to be a Ruby hipster back in the day so this didn’t throw me, but I can understand the confusion for Java/C# types. So, you’re used to something like this:

myInstance.doSomethingWithParameters(a,b);

And it all makes sense. Things are ordered neatly: the instance you’re calling the method on, then the name of the method, then the parameters. All in that order, as God intended. And then some punk throws the following obj-c snippet in your face, and its just wrong:

[someInstance doSomethingWithObject:a andAnotherParam:b];

Have a look – we’re half way through the method name, then we decide to drop in a parameter (a), then keep going with more method name stuff, and then another parameter. It’s all mixed up. Yes, I can see how this is confusing. So here’s what’s going on:

• The instance you’re calling the method on is ‘someInstance’, because it’s the first thing inside the brackets
• The method name is ‘doSomethingWithObject:andAnotherParam:’, the parts to the left of the parameters
• The parameters are ‘a’ and ‘b’

If you hate this, simply realise that it is just a matter of taste. And think of the huge benefit: You get named parameters, which means your code will be easier to read later on, when you have to debug it.

Memory management

You’ll have to prise my garbage collecter out of my cold, dead hands!

Another common dread is memory management. Most people thought they’d seen the last of that when they moved to Java/C#. And to be honest, it is difficult to think of any other modern languages that still don’t handle your memory management for you. But here’s the rub: obj-c isn’t modern: it’s been around since the 80’s, pretty much unchanged. So it is a bit old, but I like to think it is old like an aged wine.

Keep in mind, the original iPhone had a 400mhz processor with 128mb of ram. The specs pretty much ruled out garbage collection for the sake of a smooth user interface. There’s a philosophy here: user happiness is prioritised over developer happiness. You may not agree with the philosophy, but at least you must understand their point of view.

Having said that, in practice memory management in obj-c becomes simple enough with some experience:

• It’s reference counted, which makes life a lot easier than C style malloc/free.
• Autorelease pools make returning allocated instances convenient.
• Retain properties, and setting them to nil in your ‘dealloc’ means you should never need write a retain/release statement.
• ARC in Xcode 4.2 should take care of 99% of your concerns automatically.
• Profiler/Instruments is a great way to find any memory leaks.

One more thing

Obj-C was born in the 80’s, when programming was simple. The architecture astronautitis (Java) that is all too common these days was nowhere to be seen, and it shows. It is the simplest possible OO layer on top of plain old C. Pragmatism rules the day in a lot of the design decisions, and i’ve found it is a great language for Getting Stuff Done, if not in the prettiest way possible. I like to think of it as a simple, reliable old car that just keeps going.

Chris Hulbert

(Comp Sci, Hons - UTS)

Software Developer (Freelancer / Contractor) in Australia.

I have worked at places such as Google, Cochlear, Assembly Payments, News Corp, Fox Sports, NineMSN, FetchTV, Coles, Woolworths, Trust Bank, and Westpac, among others. If you're looking for help developing an iOS app, drop me a line!

Get in touch:
[email protected]
github.com/chrishulbert
linkedin

 Subscribe via RSS