Home > Articles > Home & Office Computing > Mac OS X

From NeXTSTEP to Cocoa: Erik Buck on the Development of Cocoa and Objective-C

Erik Buck, author of Cocoa Design Patterns, talks with David Chisnall about the history of modern Apple development from it's NeXTSTEP beginnings to Cocoa and Objective-C today.
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?

EB: There is a lot of excitement surrounding Mac OS X and iPhone development, and it's about time! Technology that I love is becoming mainstream, and since about 2002 Apple has been consistently advancing the state of the art in software development. From 1996 until about 2002, Apple removed or neutered feature after feature from Cocoa without providing replacements. (Objective-C EOF, 3D Kit, Music Kit, NeXTtime, Sound Kit, Indexing Kit, D'OLE, Objective-C WebObjects, asynchronous graphics) Ever since, Apple has been restoring features: QTKit is the future of multimedia. Core Data, Key Value Coding, and Key Value Observing have restored the best features of EOF. Spotlight resurrects much of Indexing Kit. Following the pattern, I expect to see future Webkit based dynamic web page content generating features. Apple is also adding new capabilities: Core Animation Layers show the future direction and tremendous promise. I expect to see even more advances in the direction of asynchronous graphics processing.

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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020