When most programmers are introduced to Objective C for the first time, they often recoil in some degree of disgust at its syntax: “Square brackets? Colons in statements? Yuck” (this is a close approximation of my first dances with the language). Objective C is a little different, a little other, so naturally programmers are loathe to like it at first glance.
I think that reaction, that claiming Objective C is bad because of its syntax results from two factors which coincided: 1. The syntax looks very alien; 2. Most learned it because they wanted to jump in on iOS development, and Apple more or less said “It’s this syntax or the highway, bub” which put perceptions precariously between a rock and a hard place. Not only did the language taste bad, developers were also forced to eat it regardless.
But any developer with even a modicum of sense will eventually realize the Objective part of Objective C’s syntax is among its greatest assets. Borrowed largely (or shamelessly copied) from Smalltalk’s message sending syntax by Brad Cox (see Object Oriented Programming: An Evolutionary Approach for a detailed look at the design decisions behind Objective C), Objective C’s message sending syntax has some strong benefits over traditional
object.method() method calling syntax. It allows for later binding of messages to objects, and perhaps most practically, reading code reads like a sentence, with parameters prefaced with their purpose in the message.
Objective C’s objects are pretty flexible when compared to similar languages like C++ (compare relative fun of extending and overriding parts of classes in Objective C vs C++), and can be extended at runtime via Categories or through runtime functions (more on those soon) itself, but Objective C’s objects pale in comparison to those of a Smalltalk-like environment, where objects are always live and browsable. Though objects can be extended at runtime, they seldom are, and are instead almost exclusively fully built by compile time (that is to say, yes lots of objects are allocated during the runtime of an application, and yes some methods are added via Categories which are loaded in at runtime, but rarely are whole classes added to the application at runtime).
This compiled nature, along with the runtime functions point to the real crux of what’s wrong with Objective C: the language is still feels quite tacked on to C. The language was in fact originally built as a preprocessor to C (c.f.: Cox), but over the years has been built up a little sturdier, all the while remaining still atop C. It’s a superset of C, so all C code is considered Objective C code, which includes:
- Header files
- The preprocessor
- Manual Memory Management (ARC automates this, but it’s still “automatic-manual”)
- Header files
- Classes are fancy
structsaccording to Landon Fuller)
- Methods are fancy function pointers
- Header files
- All of this is jury-rigged by runtime C (and/or C++) functions
In addition, Objective C has its own proper warts, including a lack of method visibility methods (like
public), lacks class namespacing (although curiously protocols exist in their own namespace), require method declarations for public methods, lacks a proper importing system (yes, I’m aware of
@import), suffers from C’s support of library linking because it lacks its own, has header files, has a weak abstraction for dynamically sending messages (selectors are not much more than strings), must be compiled and re-run to see changes, etc.
John Siracusa has talked at length about what kinds of problems a problemmed language like Objective C can cause in his Copland 2010 essays. In short, Objective C is a liability.
I don’t see Apple dramatically improving or replacing Objective C anytime soon. It doesn’t seem to be in their technical culture, which still largely revolves around C. Apple has routinely added language features (e.g., Blocks, modules) and libraries (e.g., libdispatch) at the C level. Revolving around a language like C makes sense when you consider Apple’s performance-driven culture (“it scrolls like butter because it has to”). iOS, Grand Central Dispatch, Core Animation, WebKit are all written at the C or C++ level where runtime costs are near-non-extant, where higher level concepts like a true object system can’t belong, due to the performance goals the company is ruled by.
Apple is a product-driven company, not a computing-driven company. While there are certainly many employees interested in the future of computing, Apple isn’t the company to drive it. It’s hard to convince such a highly successful product company to operate otherwise.
So if a successor language is to emerge, it’s got to come from elsewhere. I work on programming languages professionally at Hopscotch, but I’m not convinced a better Objective C, some kind of Objective Next is the right way to go. A new old thing is not really what we need. It seems absurd that 30 years after the Mac we still build the same applications the same ways. It seems absurd we still haven’t really caught up to Smalltalk. It seems absurd beautiful graphical applications are created solely and sorely in textual, coded languages. And it seems absurd to rely on one vendor to do something about it.