I’ve mentioned before that, of all of the C dialects available, Objective-C appeals most to me from the standpoint of simplicity and elegance. The language isn’t perfect but, prior to version 2.0, I found the syntax to be relatively clean and intuitive, unlike that of C++.
When examining the syntax of the language, particularly the use of bracketed statements to indicate method calls (messaging), it’s easy to see that Smalltalk features were imposed on the underlying C syntax rather than being added as a natural evolution of the language — but I’d guess that this was because the initial "compiler" for Objective C was something closer to a preprocessor than a full-blown parser. Nevertheless, the syntax does make method calls easy to recognize in long stretches of code; and the ability to "tag" parameters also helps to clarify the purpose and use of each object.
Unfortunately, Objective C never really caught on as a mainstream language, and Apple seems to have abandoned it in favor of a language with semantics that are closer to C++ (read: uglier, in my opinion). Much of the reluctance to use the language seems to revolve around the idea that Objective C code can never compete with C and C++ in terms of performance: Objective C resolves method calls (messages) to their implementations at runtime, while traditional compilers do so at compile time. In general, the former approach is supposed to provide the most flexibility in implementing of a given method, while the latter approach will provide the greatest speed. But does the flexibility offered by Objective C actually actually penalize code execution times?
For the Apple implementation of the Objective C runtime, the answer would appear to be "yes" — at least, this was the case in 2003. But that was more than twenty years ago, and with the traditional Apple runtime. The question is whether the Objective C runtime implementation presently offered by GCC suffers from the same speed penalty.