Title: An Introduction to Objective-C

As mentioned in Part 1, it was Cox's idea to apply the principles of Smalltalk to a lower-level language like C, thus producing a useful hybrid which combined the advantages of both. Polymorphism is implemented by late binding and is not dependent on inheritance, as it is permitted to send any message to any object. This gives the developer the maximum flexibility and enables techniques such as delegation and notification, which are very important in the construction of complex graphical user interfaces. These techniques are very difficult to implement in C++, as the compiler needs to know at compile time about all the member functions that are going to be called on an object. Objective-C programmers tend to find C++ very restrictive in this regard, and they typically say that they are having to fight against the language instead of being able to use it as a tool. In fact, I must admit to having experienced this feeling myself. Supporters of C++, on the other hand, say that having the compiler do the checking for you eliminates at an early stage a common class of errors. The fact remains, however, that certain problems are very difficult to solve in pure C++, and vendors like Trolltech (who supply the Qt application development framework) and Microsoft provide some quite elaborate mechanisms in order to get around this.

Another area where the message-passing model of Objective-C shines is distributed objects; with NeXT/Apple's PDO invoking a method belonging to an object in another thread, address space, or even a remote host differs little from invoking one in a local object..

It has been said that C++ excels at solving closed-world problems, while Objective-C's realm is an open world. Anguish et al. write:

My first introduction to C++ was something of a disappointment. To be sure, I was greatly impressed by the power of the 'template' facility to operate with arbitrary types, though it did not seem as elegant as the strong generic typing of SML and Haskell. I expected C++ to come packaged with general-purpose and GUI class es in the same way as Smalltalk, and all I got was iostreams! The position is a little better today, as the standard C++ library now incorporates the Standard Template Library, a very versatile basic set of algorithms and data structures, yet I still have the impression that people who work in C++ 'cut their own code' for the most part rather than make the maximum use of code written by others.

I hope to have convinced the reader that Objective-C is very simple in terms of both its syntax and its concepts; much like Java, it eschews 'frills' like operator overloading and multiple inheritance. It has no 'templates' either, which are perhaps the source of the best and the worst of C++. However, the APIs associated with Objective-C, for example those of Apple's Cocoa, tend to have a very steep learning curve.

As the programming language of choice for new Macintosh applications, Objective-C would seem to have a future at least as secure as that of its main platform. In the wider world of object computing, however, I perceive a trend away from low-level hybrids like Objective-C and C++ towards managed object environments like those of Java and the Microsoft Common Language Runtime on the one hand and scripting languages like Perl, Python and Ruby on the other. There are several reasons for this. First, languages in the C family allow the programmer access to raw, unchecked pointers, which, while often efficient, can also lead to application crashes and buffer overruns. The difficulty of providing reliable automatic garbage collection for these languages can also cause crashes (from deallocating unallocated memory) and memory leaks. The Cocoa frameworks use partly manual and partly automated reference counting, which is better than leaving memory management completely to the programmer, but inappropriate use of -retain and -release can still result in crashes and memory leaks, and of course, there is always the possibility of the retain count never reaching zero because of circular references; in addition, the book-keeping overhead involved with reference counting can be extremely severe where a large number of objects is inserted into and taken out of container objects. Object programming seems to me to demand automatic memory management, something which is possible in C++ and Objective-C only under controlled circumstances, like the 'safe mode' of Microsoft Visual C++ .NET. As computers become ever faster, the undoubted machine efficiency of Objective-C and C++ is perceived as less of an advantage relative to the interpreted, thus slower, but also safer, easier and more flexible, scripting languages.