From NeXTSTEP to Cocoa: Erik Buck on the Development of Cocoa and Objective-C
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Erik Buck is the co-author of Cocoa Design Patterns and a long-time Objective-C programmer. I talked to him about how he's seen the Cocoa platform evolve from OpenStep, and where he sees it going in the future.
Although OS X is relatively new, it is built on top of technology that has been under development since Steve Jobs founded NeXT in the mid '80s. Erik has been working with this platform for over two decades, and for several years ran a successful software company developing software for NeXT machines. His perspective on the development of Cocoa, from its beginnings in NeXTSTEP and its evolution through the OpenStep specification, provide some interesting insights.
David Chisnall: What caused you to learn Objective-C originally? Was it very different to other languages you knew at the time, and what features of the language did you like the most?
Erik Buck: I saw a demonstration of the original NeXT Cube (http://en.wikipedia.org/wiki/NeXT) computer in late 1988 when I was a student at the University of Dayton. I was captivated and later drove to play with Cubes in Cincinnati and the Ohio State University in Columbus. The original NeXT demonstration applications included digital signal processing for sound and Display Postscript for graphics.
Believe it or not, the price was right too. For $7500 with a student discount, I got a much more capable NeXT system at a fraction of the price of a Mac II or any of the popular Unix workstations from the time.
At about the same time, I attended a seminar on ATT's "C with Classes," a.k.a. C++, which introduced me to object-oriented programming. I remember wondering at the time "what was the big deal?" I managed to avoid really understanding Objective-C for at least a couple of years. I primarily wrote code in C using the Unix APIs, and I ported a lot of assembly language software originally written for the Atari ST computer. However, there was no way to avoid the heart of NeXTstep: Interface Builder and the various Objective-C frameworks including AppKit. NeXTstep became Mac OS X and Cocoa. Interface Builder and AppKit a.k.a. Application Kit Framework remain.
My first projects with Objective-C included writing a Tetris clone because my roommate derided any computer that didn't have a Tetris game. I confounded my college professors by turning in assignments written in Objective-C, but they were very supportive in the end. Objective-C grew on me gradually, and I appreciated the ability to mix procedural C code, functional Postscript code, and object-oriented code all in the same source file. I learned the NeXT frameworks from the documentation and the excellent book, NeXTSTEP Programming: STEP ONE: Object-Oriented Applications by Simson Garfinkel and Michael K. Mahoney.
The NeXT programming community was very tight-knit in the early 90s. It was not only possible but likely that you would meet the key developers both inside and outside NeXT. I was inspired by people like Andrew Stone of Stone Design (http://www.stone.com/New.html) and Jonathan Schwartz of Lighthouse Design (http://en.wikipedia.org/wiki/Lighthouse_Design). There were numerous NeXT related start-up companies and a wealth of excellent third party software. The excitement was contagious. NeXTstep and Objective-C were inspiring innovative new applications like WorldWideWeb (http://www.w3.org/People/Berners-Lee/WorldWideWeb.html), Lotus Improv (http://simson.net/clips/1991/91.NW.Improv.html), Diagram!, and Tailor (http://www.blackholeinc.com/catalog/software/Software/Graphics/Tailor.shtml).
Obviously, I had to start a company too. My company, EMB & Associates Inc., produced NeXTstep based design software for aerospace. The easiest way to describe our application was "Interface Builder for aircraft cockpits." Pictures of our application and its results appeared on the cover of nearly every aerospace magazine. We sold most of our intellectual property to a Fortune 500 company in 1996. The company continued for several years dabbling in the computer game industry before closing in 2002. I currently work as a Product Line Manager and Senior Staff for a different large aerospace company.
Tim Berners Lee once commented that his pioneering WorldWideWeb application was only feasible at the time because of NeXTstep. That was certainly true for my company's application. There were two failed attempts to port our application to Java, and each of the attempts likely cost more than the original development.
DC: I think you're the only person I've spoken to who liked the PostScript part of programming on NeXT. What kind of thing did embedding PostScript in your code make easy and what do you do on OS X, where Display PostScript is not present?
EB: Display Postscript provided a resolution independent What You See Is What You Get (WYSIWYG) display system with floating point coordinates and alpha channel transparency at a time when integer based VGA graphics were an extra-cost upgrade for competing systems. Apple has preserved and enhanced the Postscript imaging model with Quartz's implementation of display PDF.
Display Postscript provided a client server graphics model with stored procedures on the server. That provided several advantages that are only slowly coming back to MAC OS X. The most obvious feature lost with the transition to Quartz was remote display. It used to be common to display the output of an application on a different computer than the one running the application. The capabilities of stored procedures are coming back in different forms. For example, the Core Imaging model uses stored programatic "filters" that execute asynchronously on the graphics processor. Postscript programs were like Core Image filters for 2D vector graphics. They allowed external parametric inputs to drive potentially complex rendering tasks that were performed asynchronously by a remote processor. Think Quartz Composer for vector graphics. In some respects, Tailor.app was Quartz Composer for Postscript graphics.
Postscript was a "Turing complete" programming language that allowed arbitrary computation on a "graphics processor" in the same way that current trends toward General Purpose GPUs are allowing arbitrary computation on a graphics processor (http://gpgpu.org/). Modern Quartz Extreme tries to offload more and more work to asynchronous processing by the graphics subsystem as enabled by Apple's announced "Grand Central" parallel processing technology.
I like Quartz very much, and I appreciate many of the enhancements like standard antialiasing that have been provided as the PDF imaging model has advanced beyond Postscript. Display Postscript, like Cocoa, was far ahead of its time.
DC: How much of the structure of Cocoa do you think comes from the language and how much would be the same if OpenStep had been designed for, say, Java or C++?
EB: Object-oriented programming languages fall into two major categories: those inspired by Simula and those inspired by Smalltalk. The term "object-oriented" was coined by Alan Kay, the creator of Smalltalk, but he later regretted the term. Languages inspired by Smalltalk are actually "message-oriented" because the distinguishing feature of Smalltalk style languages is the ability to send messages to anonymous receivers.
C++ is a language that grafts Simula-style object orientation onto the C programming language while simultaneously trying to improve C. Objective-C is a language that grafts Smalltalk style message sending onto C while preserving the base C language unchanged. Both languages started from C because they wanted to preserve the world's investment in billions of lines of C code while providing a more productive path to the future.
Java was partly inspired by Objective-C. For example, Java "interfaces" reused the idea of Objective C "protocols." Java and C# use C++ like syntax but abandoned C semantics in favor of protected virtual machines.
In theory, Cocoa could have been written in C++ or Java. In practice, the message-oriented nature of Objective-C is what makes Cocoa feasible and so amazingly productive. Qt Software/Trolltech's Qt framework is the closest thing you will find to a C++ re-imagining of Cocoa. Qt uses C++ with several non-standard extensions implemented by an additional pre-processor. The pre-processor is necessary to enable Objective-C like expressiveness and defines a messaging like capability.
To my eye, Microsoft's C# .NET Framework is becoming very Cocoa like. Microsoft has finally embraced the Model View Controller design pattern that is ubiquitous in Cocoa. The C# language is evolving to be closer in concept to Objective-C.
There is no better argument in favor of the trade-offs provided by Objective C than the elegance of Cocoa. Seamlessly use C. Provide easy bridges to other dynamic languages like Python and Ruby. Network distributed messages use identical syntax to local messages. I would argue that Cocoa would be much less elegant if it were implemented in another language.
DC: A lot of the original Gang of Four design patterns came from Smalltalk-80, which was also the inspiration for Objective-C and a lot of Cocoa. Can you give some examples of patterns that are unique to OpenStep / Cocoa?
EB: The Gang of Four frequently cite examples of their patterns not only in Smalltalk but in NeXTstep. Design patterns are intended to be reusable solutions to recurring problems. As a result, patterns are seldom unique to any one technology. The patterns in Cocoa can be found in other frameworks. However, the Objective-C language makes many of the original Gang of Four design patterns trivial or unnecessary.
The goal of object-oriented programming is to maximize programmer productivity by reducing lifetime software development and maintenance costs. The principal technique used to achieve the goal is object reuse. Design patterns identify successful strategies for achieving reuse on a larger scale than individual objects.
The principal obstacle to reuse is coupling. Coupling refers to dependencies between objects. Whenever such dependencies exist, they reduce opportunities for reusing the objects independently. All of the Cocoa design patterns exist in part to limit or avoid coupling. Objective-C helps to minimize coupling by allowing dynamic typing, messages to anonymous receivers, heterogeneous containers, message forwarding, and in Objective-C 2.0, properties.
The consistency with which Cocoa applies patterns is astonishing and contributes to legendary high programmer productivity. Ironically, the same consistency is a barrier to getting started. You can't take Cocoa's patterns a la cart. They are all interrelated, and if you don't understand a key pattern it will impede everything you attempt. You just can't get started without understanding Delegates, and then you can't use Delegates effectively until understand the Responder Chain which leads you to Hierarchies and Targets and Actions.
DC: You mentioned that some patterns are made unnecessary by Objective-C. The one that springs to my mind is the command pattern, since every Objective-C message send is an equivalent of this. Can you give some other examples?
EB: Objective-C selectors and messaging largely eliminate the need for the Command design pattern, but Cocoa's NSInvocation class still provides a concrete implementation of the command pattern. The command pattern is used by other frameworks to provide target/action like capabilities and to support features like scripting, undo, and redo that are all almost automatic with no code when you use Cocoa.
I think all of the famous GoF patterns exist within Cocoa, but many are either trivially implemented or made less necessary thanks to Objective-C. For example, the Cocoa convention of two stage allocation and initialization makes the GoF Abstract factory and Builder patterns trivial. Cocoa's Responder Chain was the inspiration for the GoF Chain of Responsibility pattern, but Cocoa's implementation is greatly simplified by Objective-C and the language's built in support for Command pattern capabilities and introspection like -respondsToSelector:.
DC: The question for every Objective-C 2 programmer: what do you think of the dot syntax for property accessors? Love it, hate it, or totally ambivalent to it?
EB: I agree with Aaron Hillegass that dot syntax is "silly." I think it's even a little harmful because it masks the crucial message sending that is really happening under the surface and provides the real power and flexibility of the language. When I glance at code, I want to see the messages, and dot syntax obfuscates the messaging.
Having said that, the dot syntax is a very small addition to the language. I don't want to blow it out of proportion. The related properties syntax is a great addition to the language. Properties allow additional expressiveness and communication of usage and intent in object interfaces.
DC: Objective-C 2 introduced a lot of small changes, and a couple of large ones. What are your favourites, and are there any you don't like?
EB: I like the properties syntax in Objective-C 2.0. A single @property declaration eliminates two method declarations that would otherwise be needed while simultaneously expressing intention/usage information than would otherwise have to be provided in comments/documentation. Coupled with @synthesize used in class implementations, the properties syntax reduces the amount of code I write. As Steve Jobs once said, "the least expensive, most bug-free line of code is the one you didn't have to write."
Properties also provide language level formalization of framework conventions like method naming for Key Value Coding. I think properties syntax points the direction toward even more language level dynamic behavior.
DC: Would you recommend Cocoa and Objective-C to someone thinking about learning to program? If not, what language and environment would you suggest?
EB: I think the C subset of Objective-C is the hardest part to teach someone who is just learning to program. I have taught Objective-C and Cocoa to many experienced programmers, and I am currently teaching my 14 year old son to program. I think Python is a great teaching language because is allows the student to achieve interesting results very quickly and postpones the need to explore more advanced concepts. Mac OS X's Python/Objective-C bridge, PyObjC, lets Python programmers enjoy Cocoa with a minimum of fuss.
My son and I have had fun playing with the excellent and free F-Script (http://www.fscript.org/) The tutorials, "Exploring Cocoa with F-Script" and "Learn F-Script in 20 Minutes and Have Fun Playing with Core Image," are a great way to introduce a novice to Cocoa.
DC: Coming from a NeXT background, did you ever investigate the GNUstep project for porting your code elsewhere?
EB: I have used GNUstep for several personal projects over the years. I have also used Cocotron (http://www.cocotron.org/). I own a 3D game engine that was written in Objective-C during the dark period after Apple killed Objective-C++ and before Apple resurrected it. I achieved cross platform support by using my own pre-processor that translated Objective-C into a subset of C++ and used a runtime that was written in C++. This allowed easy intermixing of Objective-C and C++ that enabled proper behavior when C++ objects were used as Objective-C instance variables etc. I never did get C++ exceptions with stack unrolling to work right though. Several years ago, I used my tool chain to translate/recompile most of GNUstep. The result was some truly ugly C++ code that nevertheless compiled and ran on nearly any Unix system that has a C++ compiler.
I have supplied flex/bison based Objective-C scanners/parsers to many people over the years, but I don't know if or how they were ever used. I am currently fascinated by the possibilities of LLVM (http://llvm.org/).
DC: What projects are you currently working on?
EB: Like everyone else, I have an iPhone game in the works as a hobby project. The game has had a long history with on-again off-again publishing contracts for a Windows version. Right now, it looks like it will be self-published, and the iPhone and Mac OS X desktop versions will be the first or only places it ships. The iPhone App store is a revolution for software distribution. It has the potential to eliminate brick and mortar software sales. If/when that happens, what role will game publishers have? Even now, game publishers exist almost solely to lend money, generate publicity, and rent shelf space.
DC: What future directions do you see for Cocoa?
I expect the forthcoming Mac OS X Snow Leopard to set a new high standard for performance on multi-core computers. I predict that Cocoa will see huge performance enhancements in areas like text layout, spotlight, and multimedia thanks to Grand Central and Apple's fantastic developer/profiling tools including compiler improvements.