Closer To The Ideal

I do not know much about Objective-C, but I’ve got a lot of friends who want to do iPhone apps, so I’ve thought about diving in.

Matt Gallagher writes about the best aspects of Objective-C in a really interesting post:

The short answer is that this dynamic message handling in Objective-C makes it much easier to work within a large framework that you didn’t create because you can examine, patch and modify elements of that framework on the fly. The most common situation where this is likely to occur is when dealing with an application framework.

The biggest reason for this is that you can add or change methods on existing objects, without needing to subclass them, while they are running. Approaches for this include categories, method swizzling and isa-swizzling.

This makes the following situations possible:

• You want to add a convenience method to someone else’s object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI).
• You want to change the behavior of a class you didn’t (and can’t) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa).
• You want to treat objects generically and handle potential differences with runtime introspection.
• You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object).

These points may seem somewhat mild but they are central to maximizing code reuse when working within someone else’s framework: if you need existing code to work differently, you don’t need to reimplement the whole class and you don’t need to change how it is allocated.

Languages using virtual method tables can adopt some of these ideas (like the boost::any class or C♯ 4.0’s dynamic member lookup) but these features have additional restrictions and don’t apply to all objects, meaning that they can’t be used on purely arbitrary objects (such as those you don’t control or didn’t create) and so don’t help when interacting with someone else’s framework.

Simply put: dynamic message passing instead of virtual method invocations makes Objective-C a much better language for working with a large library or framework that someone else has written.

… In my opinion, Objective-C is the best language for programming situations where you must make extensive use of a framework written by someone else (particularly an application framework). The success of Objective-C in this situation is due to the combination of:

* speed and precision (from its compiled C roots)
* dynamic flexibility (due to using message passing for method invocations)

To frame this conclusion, I’ll state that I’ve written major projects using C/WIN32, C++/PowerPlant, C++/MFC, and Java/Swing/AWT. I’ve also dabbled in smaller projects using C♯/.Net. In all of these cases I have found the application frameworks to be less flexible and less reusable because they lack the dynamic modifiability of Objective-C.

When I hear the words “change methods on existing objects… while they are running” I immediately think of Ruby. In fact, till recently, Ruby was the only language I was aware of that allowed you to modify a class at runtime. Some programmers regard this as heresy. Consider the fear in Bill Venners voice as he talks about this with Yukihiro Matsumoto (the creator of Ruby):

Bill Venners: In Ruby, I can add methods and variables to objects at runtime. I have certainly added methods and variables to classes, which become objects at runtime, in other languages. But in Java, for example, once a class is loaded or an object is instantiated, its interface stays the same. Allowing the interface to change at runtime seems a bit scary to me. I’m curious how I would use that feature in Ruby. What’s the benefit of being able to add methods at runtime?

Yukihiro Matsumoto: First of all, you don’t have to use that feature. The most useful application of dynamic features, such as adding methods to objects, is meta-programming. Such features allow you to create a library that adapts to the environment, but they are not for casual uses.

So, it seems to me, Objective-C was pioneering many of the advantages that I would nowadays associate with dynamic scripting languages, like Ruby or Groovy. But an interesting thing about Objective-C is that it is a compiled language. It was compiled largely because the computers that existed back then were not powerful enough to handle script languages. Perl and Python don’t get going till the end of the 80s, and scripting languages don’t really take off till the 90s, when there was sort of an explosion of them (Ruby, PHP, etc).

The SmallTalk language was an inspiration for Objective-C, but SmallTalk ran very slowly on the machines of the early 80s:

In the early 1980s, common software engineering practice was based on structured programming. Structured programming was implemented in order to help “break down” programs into smaller parts, primarily to make them easier to work on as they grew increasingly large. However, as the problems being solved grew in size, structured programming became less useful as more and more procedures had to be written, leading to complex control structures and a low level of code reuse.

Many saw object-oriented programming as a potential solution to the problem. In fact, Smalltalk had already addressed many of these engineering issues; some of the most complex systems in the world were Smalltalk environments.[citation needed] On the downside, Smalltalk used a virtual machine. The virtual machine interpreted an object memory called an image, containing all development tools. The Smalltalk image was very large and tended to require huge amounts of memory for the time. The virtual machine also ran very slowly, partly due to the lack of useful hardware VM/container support.

So what was needed, at that time, was a compiled language that offered the flexibility of object oriented code, and perhaps some of the productivity benefits of dynamic languages:

Objective-C was created primarily by Brad Cox and Tom Love in the early 1980s at their company Stepstone. Both had been introduced to Smalltalk while at ITT Corporation’s Programming Technology Center in 1981. Cox had become interested in the problems of true reusability in software design and programming. He realized that a language like Smalltalk would be invaluable in building development environments for system developers at ITT. Cox began by modifying the C compiler to add some of the capabilities of Smalltalk. He soon had a working implementation of an object-oriented extension to the C language, which he called “OOPC” for Object-Oriented Programming in C. Meanwhile, Love was hired by Schlumberger Research in 1982 and had the opportunity to acquire the first commercial copy of Smalltalk-80, which further influenced development of their brainchild.

Objective-C arrived at Apple via NeXT:

After Steve Jobs left Apple, he started the company NeXT. In 1988, NeXT licensed Objective-C from StepStone (the owner of the Objective-C trademark) and released its own Objective-C compiler and libraries on which the NeXTstep user interface and interface builder were based. Although the NeXT workstations failed to make a great impact in the marketplace, the tools were widely lauded in the industry. This led NeXT to drop hardware production and focus on software tools, selling NeXTstep (and OpenStep) as a platform for custom programming.

…After acquiring NeXT in 1996, Apple Inc. used OpenStep in its new operating system, Mac OS X.

I can imagine that at the time Steve Jobs was starting NeXT, Objective-C would have huge appeal as the most dynamic compiled language available at that time. And Jobs has stuck with it for over 20 years now, first bringing it into the MacOS and then making it the basis of programming in the iPhone API.

The Wikipedia page says Objective-C tends to run 3 times slower than plain C. I imagine that used to matter, though of course nowadays large projects (possibly the majority of all software written?) is written in languages that depend on a virtual machine, so I assume Objective-C is faster than most of the languages that are nowadays in heavy use.

All of this leaves me somewhat curious about why Objective-C isn’t more popular. Perhaps it is just too much in the middle in terms of performance versus its dynamic nature? Nowadays programming tends to fall into 2 worlds – when you need speed, write in C, but if you want dynamic productivity, use something like a script language: Ruby, Groovy, PHP. Or, at the very least, a language that cleans up variables and memory for you (automatic garbage collection) as in Java and C#. Possibly it is the lack of automatic garbage collection that has kept Objective-C from taking off?

It is somewhat amusing to listen to Steve Jobs, addressing a graduating class at Stanford, as he describes his own path: “Dropping out of college was the best move for me.”