Reflections on Objective-C | Hacker News Reader

Reflections on Objective-C

alblue.bandlem.com

63 pointsfogus13 comments

It looks like everything here are platform features and not language features. The author likes the features of NSObject and NSAutoreleasePool and the fact that the Cocoa libraries make use of autorelease pools.

I have a similar fondness for the Cocoa platform. I was recently asked to port some work to another platform, and considered keeping Objective-C as the language... but my love for the language runs thin once Apple's libraries are gone. The dynamic typing and categories(adding methods to arbitrary classes) are still nice though.

This is what I always try to explain to people. Objective-C is a slightly above-average core language (it's a minimal set of extensions to ISO C) with no standard library to speak of. Cocoa is an awesome library written in Objective-C. Any enjoyment you get from Objective-C programming (and pretty much anything you accomplish) is probably thanks to Cocoa, not Objective-C itself.

To illustrate how minimal Objective-C is: There isn't even a standard root class. It includes an Object class, but using it is not mandatory, and only one class used in any Cocoa app is derived from it. There also isn't a "root class" protocol. Due to the lack of a standard root class, outside the safety of Cocoa, there isn't even a standard way to ask an object what class it is or what selectors is responds to.

..outside the safety of Cocoa, there isn't even a standard way to ask an object what class it is or what selectors is responds to.

Yes, there is. The Objective-C run time lets you do all of this. It is in C and not Objective-C. But, NSObject is barely more than a thin wrapper for these functions, anyway.

I wish there was more documentation about the portability of Objective-C and specific Core Foundation features. It's hard to find a definitive answer. gcc supports Objective-C, and Apple open sources CF-Lite, but apparently and confusingly, that is only a subset of Core Foundation.

I make OpenGL videogames but my code is written in Objective-C (long story) and so currently only supports iOS and OS X. I feel almost at home with ObjC and my codebase, I enjoy the features mentioned in this article, and it's performant enough for what I need, but I'm reaching a point where I wish my core logic code was multi platform (from PS3 to Android including iPhone). Moving to C++ would mean learning C++ and best practices (which sounds quite daunting to beginners) and rewriting the whole codebase, but the lack of practical documentation on the portability of Core Foundation looks like a big neon sign that dropping Objective-C is the only reasonable way towards a cross-platform codebase.

Reference-counting in Objective-C is probably an improvement compared to the very basic memory management of C++. (C++ fans, yes, RAII is better than nothing, but no, it's not enough.) But ref-counting is also a far cry from the tracing garbage collectors most of us expect in a modern language.

There are plenty of gotchas in non-GC'ed Obj-C memory management, see my previous comment in a different thread: http://news.ycombinator.com/item?id=1986799 . Also, the interaction of ref-counting with multi-threading is just awful: objects that some code uses but doesn't own must be obsessively retained-and-autoreleased in case another thread preempts and releases them. Behind the scenes, this takes and releases a lock on the object, which doesn't exactly help efficiency.

I'd rather hear about more of the things that Objective-C really gets right, instead of another "omg, I'd never heard of ref-counting before!" post. Here's a couple to start people off:

* Using named messages (instead of vtables a la C++) provides quite good introspection and run-time modification of the class hierarchy. This allows cool features like "delegates" that implement a subset of extension behaviours, and method forwarding.

* Objective-C's "informal protocols" are what we'd now call duck-typing.

Reference counting is available in C++ through the use of smart pointers ( ex. boost::shared_ptr ). In fact unlike Objective C there is no need to explicitly increment/decrement the reference count.

You can also just make your own CSmartObject base class (which does reference counting), and just have all of your objects inherit from that.

Reference counting may not be built into C++ itself, but it's not super difficult to add in either.

Yes, but the problem is that it's just one approach out of many, so when using other libraries and APIs, you have no consistency. (For example, you'll have to wrap their classes in your refcounting scheme, and unwrap when passing them back in.)

Wow, the author is pretty clueless about C++: "Objective-C users never call "dealloc" themselves; whereas C++ users have to call this all the time."

If you ever call delete in C++, you're doing it wrong. I have a large project where I never call new or delete even once. Whereas my Objective-C has plenty of release and retain calls.

Frankly, I'm tired of the endless C++ bashing. Yes, it's a complex language. Yes, it has bad parts that you shouldn't use. But it has strengths that make it ideal for certain high-performance applications. (And before anyone brings up C, profile qsort and std::sort and then shut up).

Use the right tool for the job, and stop being religious about language choice. If you look far enough, you'll find there's something to complain about in every language: http://twitter.com/#!/ID_AA_Carmack/status/28939697453

NSFormatters do a lot of stuff, internationalization, user preferences for number representation, etc. It shouldn't be a surprise if they're a bit heavy. IIRC they're pretty much intended for UI display, not for tight loops.

"A single use of an obj-C number formatter..." [emphasis mine]. Carmack is a pretty smart guy, he wouldn't be using number formatters in an inner loop.

Anyway my point was that you can find fault in just about anything. But, you'll be much better off if you found out the strengths of each language instead, and used that to your advantage. Here's a guy that has this figured out: http://www.savoysoftware.com/blog/my-iphone-is-not-a-mac-pro...

We need fewer religious language BS articles like this one, especially from a guy who seems completely clueless about C++.

tl;dr Autorelease pools are neat, and C++ doesn't have them.

tl;dr "I think my language is better than your language because I haven't used your language and am ignorant of the fact that it can do everything I've just described, but with less effort".

Reply on news.ycombinator.com