
Reflections on Objective-C - fogus
http://alblue.bandlem.com/2011/02/reflections-on-objective-c.html
======
xsmasher
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.

~~~
chc
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.

~~~
Zev
_..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.

------
vasi
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.

~~~
nt
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.

~~~
jmah
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.)

------
alexkcd
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>

~~~
jon_hendry
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.

~~~
alexkcd
"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...](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++.

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

------
bestofme
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".

