Objective-C Philosophy
Over the course of my Dilbert-like career, I’ve had the occasion to work on a few C++ projects. Thankfully, that was some time ago, as web-based apps have now pretty much replaced C++ apps at most corporations. Writing apps on my own in C was something I enjoyed, but C++ struck me as a big, freighted beast that was supposed to make things easier and better, but somehow made the code much larger, and scattered it across many files in a way that, to my mind, made it harder to examine the code’s functionality at a glance. In theory, the idea of objects and methods seemed like a good one, but I was never very happy working with it in C++.
When I first decided, about a year ago, to devote a significant chunk of my free time to trying to write my first serious Cocoa app, I discovered that Cocoa apps are written in something called “Objective-C” (ObjC for short). I was apprehensive — what’s this, another C++-like language that takes all the fun out of writing an app in C? And since I had already learned C++ some years ago, did I really want to learn another one? Why didn’t Apple just use C++? Over the past several months, though, I’ve come to appreciate Apple’s decision to use ObjC as the development language of Cocoa, and I’ve accumulated a list of reasons why I like it better.
As I see it, there are five key differences between ObjC and C++. The first three are the ones that matter most to me, as a developer:
1. C Friendliness
- C++ is not a strict superset of C. Not all C code will work in a C++ project.
- ObjC is a strict superset of C. Any valid C code can be dropped into an ObjC project and you can expect it to work as it would in a C project.
2. Weight
- C++ is a relatively heavy addition to C. Not only does it have more new syntax (as compared to ObjC), but it comes with a large, general-purpose class library that is considered part of the language — C++ programmers are expected to know it and use it, else risk writing code that will be automatically classified as “bad” by C++ developers and employers.
- ObjC is a light addition to C. It has a relatively small set of new syntax, and it comes with no general-purpose class library. Maybe you can get one somewhere, but it’s not standard with the language, nor is it considered part of the language. Of course, with ObjC you can expect there to be a large class library with which you interface with your OS — as would also be the case in C++ — but there is no generalized “helper” library as in C++. An OS class library can be learned in pieces as needed: For example, I didn’t need to use sound in my first Cocoa app, so I didn’t even bother to learn it. But a general-purpose, organizational class library that’s considered part of the language must be learned in its entirety to make sure that you aren’t reinventing a wheel already included in it.
3. Syntax Similarity
- In C++, the new, object-oriented syntax looks extremely similar to C — probably about as similar as they could make it.
- In ObjC, the new, object-oriented syntax looks very different from C — even at a quick glance, you’d never mistake it for plain C. (It does, however, have the same compact brevity as C, which we C programmers like.)
Now let’s pause and take stock of what those three differences mean, as a group. One conclusion, I think, seems readily apparent: The architects of C++ didn’t like C. They thought of C as a bad mistake that needed to be replaced with something radically different. They built their language on C, and made its syntax look like C, so that it could springboard off the popularity of C, and would be thought of as the natural progression of C, in the minds of C programmers. But C++ is actually trying to get you to stop using C, and to do everything, as much as possible, in the new, object-oriented way. It doesn’t bother the designers of C++ that you have to learn a big class library; you’re probably a captive audience anyway since your employer is requiring you to use C++, or your school is requiring you to take a course in it. The way they saw it, learning a big class library will help you get used to doing things in the object-oriented way, and by making it a standard part of the language, force you to use it too.
ObjC, on the other hand, isn’t trying to replace C, but rather is just trying to add object capability on top of it. The goal of ObjC is to provide the shortest learning curve possible to get C developers working in a language that does objects — but isn’t hostile to its C roots. With ObjC, you just learn a few new items of syntax, and you’re ready to go. All your C code can be dropped into your ObjC project where it will work fine and won’t be considered a bad programming practice. And the new, object syntax stands out as clearly different from C, so you’ll always know what you’re looking at: If it looks like C, it is.
Of course, since ObjC allows you to do things in straight C as much as you care to, it’s a lot more dangerous in the hands of inexperienced developers, who will be far more likely to create a solid, stable app in C++. But if you’re a developer who has little trouble writing clean, bug-free apps in straight C, why give up C for no good reason? That would explain why C++ would be popular (in the pre-internet era) with big corporations that make use of large teams of junior programmers, whereas ObjC would be chosen by a company like Apple to be used in its own (and its third-party developers’) apps.
The other two key differences have to do with how objects work in the two languages:
4. Object Independence
- In C++, an object is wholly owned by the object that created it, and must ultimately be destroyed by that object. For example, if object A creates object X, then it is up to A to destroy X. Object A can temporarily share X with objects B and C, but X is always owned by A, and must be destroyed by it. In C++, each object is dependent on the object that created it.
- In ObjC, by contrast, each object is an independent entity that can outlive the interest of its creator, and even outlive its creator. For example, if object A creates object X, and A tells B and C about X, then A can relinquish its interest in X, but X lives on as long as B and/or C are still interested in using it. Object A can even be destroyed, and object X lives on. Only when B and C (and any other objects that have been given a hand in X) have all said “I’m no longer interested in X,” will X be destroyed. (Update 2008.03.14 — This may be a feature specific to Cocoa’s and other development systems’ implementation of ObjC, not a required feature of ObjC itself.)
5. Object Orientation After Compilation
- In C++, method names are discarded during compilation, and the resultant executable consists of code that could just as well have come from a straight C compiler.
- In ObjC, method names are kept in the compiled app, resulting in executable code that allows the calling of methods by name. As the developer of a simple app, I have not found a use for this feature myself, but I can well imagine that it would permit the use of object A by object B even though the sourcecodes for each were never shared on one computer.
Taken together, differences 4 and 5 suggest that ObjC is a truer implementation of the concept of an “object” — its objects have more independent lives, and they retain much of their object-oriented nature even after compilation.
Put it all together, and what do you get? ObjC is a language for people who can (and do) write reliable, clean apps in straight C, but would also like the added ability to use objects. And when they use that ability, they want those objects to be as true to the object paradigm as they can be. C++ programmers might scorn the idea that ObjC is truer to the object paradigm, but such scorn would be based on the fact that ObjC does not frown on the use of straight C. In C++, object-orientation is not an added ability, but rather is a coding style — one that’s intended to force you to write your entire project a new, safer way. How true the resultant “objects” are to the object paradigm is of secondary importance to C++.
Thank you, Apple, for seeking out a little-used language with more author-friendly design goals, instead of going with the language everyone else was using at the time. I can’t imagine any other computer company being bold enough to make that choice.
Update 2008.03.11 — Guess what the development language is for the iPhone SDK? You got it.
Update 2008.03.14 — Special thanks to Brad Cox for creating this language in the first place!
© 2008 Darel Rex Finley | design by