>>1
At first glance it seems
>>7-san is joking, but he has actually formulated legitimate criticism of the language in the guise of a joke. (Mind you, Smalltalk is faster than its reputation suggests, so don't take the joke at face value.) Consider his post the "tl;dr" summary of mine.
All of Obj-C's extensions revolve around the dispatch system. Any moderately competent C++ programmer will tell you that compile-time polymorphism with templates yields better performance than runtime polymorphism with virtual methods. Any systems programmer familiar with Ruby or Javascript will also tell you that dynamic types and mutable classes greatly exacerbate the problem. At this point you're not just taking performance hits from a single pointer indirection like in C++'s vtables; you actually have to look up function names in a linked hash table on
every invocation, because the dispatch tables are actually mutable at runtime and new classes can be introduced at any time in a running program.
This is, in a nutshell, what they don't tell you about Obj-C. As far as the runtime is concerned, it's a dynamically typed language with mutable dispatch tables. You can actually remove all the type information from your method implementations and (at least in the last version I used) it will still run. They're really only there for documentation and static analysis. The runtime still has to check the type of an object on every method invocation. If you think I'm bullshitting you, check out the MacRuby project (
http://macruby.org/) which uses a Ruby interpreter instead of making literally everything a native extension method. The languages are so similar on a semantic level that they just ditched all the standard Ruby classes for Obj-C equivalents.
Now, this is all completely fine for GUI code, and really that's not a problem, because after all you'll never need it for anything else. If there's another language where it's easier to call into C libraries for heavy lifting, I've never heard of it. Hell, even if you're neck deep in Apple's proprietary Core Whatever libraries, it's very straightforward (little more than a search and replace macro + some manual memory management) to peel away the method invocation layer and just use the underlying C APIs. The result will be noisy, but hey, what C program isn't?
So as long as you know this shit,
and you're a competent C programmer, you're all set. Obj-C will actually be pretty painless for you.
Here's the fun part though:
They don't tell you this unless you ask! Apple just figures you should already be competent with C. An inexperienced programmer could dive right into learning Obj-C, and then go his entire career without figuring out why his object-oriented XML parser is
SLOW AS BALLS. This is the single worst thing about the way Obj-C is documented. I can't say anything outright
bad about the language itself (shit, man, programming is hard and everything has horrible warts) but the way this is handled by Apple is just really embarrassing and it makes me cringe to know that >90% of Obj-C code is written by people who fall into this trap.