April 29th, 2009 by Mike Fulton
Posted in Apple, iPhone, Mac, Tech

Once upon a time, Steve Jobs was the leader of a company called Apple.  Apple was known for being a technology leader, and their latest products were the envy of the industry.  Sadly, though, Apple’s sales figures didn’t seem to be able to keep pace with their reputation.  The board of directors of Apple, thinking that another style of management might be the way to go, decided that they’d had enough of Steve and handed him his walking papers.  The year was 1985.

Steve’s response to the situation was to start another computer company, called NeXT.  The Apple Macintosh was supposed to be the “computer for the rest of us” but with NeXT, it seemed Job’s goal was to create the “computer for the best of us“.  Largely inspired by his experience with getting the Macintosh into the education market, the NeXT Computer was going to be a powerful workstation designed to meet the needs of the scientific and higher educational community.  At the heart of this new computer was going to be NeXTStep, an object-oriented multi-tasking operating system that included tightly integrated development tools to aid users in quickly creating custom applications.

NeXTStep’s Language Of Choice

At the heart of NeXTStep was a fairly new programming language known as Objective C.  It was basically an extension of the C language to add Smalltalk-style messaging and other OOP features.  Conceptually it’s not too far off from where C++ was at the time, but the syntax is fairly different.  However, that simply didn’t matter at the time because most programmers hadn’t done much, if anything, with C++.

In 1985, any sort of object oriented programming was a relatively new thing to most programmers.  Modern languages like Java and C# were still years in the future, and C++ was still largely an experiment, with no standard in place and drastic differences from one implementation to the next.  In fact, most C++ solutions at the time were based on AT&T’s CFront program, which converted C++ code into standard C code that would then be compiled by a standard compiler.  It would be a few years yet before native C++ compilers became commonplace.

There were other OOP languages around, like Smalltalk or Lisp, but they were largely considered acedemic languages, not something you’d use to create shrink-wrapped products.

Since there simply wasn’t any better solution, the choice of Objective C for NeXTStep was completely reasonable at the time.

What Happened NeXT

The first version of NeXTStep was released in Sept. 1989.  Over the next few years, the NeXT computer and NeXTStep made a number of headlines and gained a lot of respect in the industry, but failed to become a major player in terms of sales.  In late 1996, NeXT had just teamed up with Sun Computer to create a cross-platform version called OpenStep, but before that really took off, something else happened.

In 1996, Apple was floundering.  Their stock price was down.  They’d had layoffs.  They had no clear plan for the future in place, and they were in serious danger of losing their place as the master of the graphic user interface.  Microsoft had just released Windows 95, which was a huge leap forward from Windows 3.1 in virtually every way, and PC video cards offering 24-bit and 32-bit color modes had become easily affordable.

Apple CEO Gil Amelio was fairly sure that updating the Mac to use some sort of object-oriented operating system was key to Apple’s future success, but Apple’s internal development had thus far failed to pay off.  Likewise Apple’s investment in Taligent, a company formed in partnership with IBM for the sole purpose of developing an object oriented operating system.  But then Amelio struck a bargain to purchase NeXT Computer and the NeXTStep operating system, bringing NeXT CEO Steve Jobs back into the fold, first as an advisor and then as CEO several months later when Amelio was shown the door.

It took Apple nearly 4 years to integrate their existing operating system with the NeXTStep tools and libraries, but ultimately NeXTStep formed the basis of the new Macintosh OS X operating system, released in March 2001.

Mac Development Tool History

When the Macintosh was first released in early 1984, you pretty much used either 68000 assembly language or Pascal to create programs.  Pascal had always been a popular language with the Apple crowd.  Apple had a set of development tools known as the Macintosh Programmer’s Workshop, which was essentially a GUI interface wrapper for a variety of commandline oriented tools, including the 68000 assembler and the Pascal language compiler.

It didn’t take long for the C language became available for the Mac.  Apple released a version for MPW, but it really took off with the release of LIGHTSPEED C (later renamed to THINK C), which had a GUI IDE of the sort that would be completely recognizable as such even today, almost 25 years later.  Think’s compiler quickly became the defacto standard development environment for the Mac.  Support for C++ would be added in 1993 with version 6.0, after the product was acquired by Symantec.

Unfortunately, when Apple made the transition from the Motorola 680×0 processor family to the PowerPC processor in 1994 & 1995, Symantec C/C++ failed to keep pace.  It wasn’t until version 8, released in 1997, that their compiler was able to generate native PowerPC code. 

Fortunately, a new player in the game appeared to save the day.  When Symantec bought out Think, some members of the Think C development team started a new company called Metrowerks.  While Symantec was struggling to bring out a PowerPC compiler, Metrowerks released their new CodeWarrior C/C++ environment.  In many ways, Codewarrior was like an upgrade to the Symantec product, and it quickly supplanted Symantec among developers.  Codewarrior would remain at the top of the heap until Apple released OS X.

The NeXT Development Tool

When Apple released Mac OS X in 2001, there were two big paradigm shifts for developers.  The first was that Apple now included their development tools with the operating system, at no additional charge.  After nearly two decades of charging premium prices for their tools, this was a big change.  Plus, the new XCode environment was an actual IDE, unlike the old Macintosh Programmer’s Workshop environment, with support for Objective C, C, C++, and Java.

The second paradigm shift was that everything you knew about programing the Mac was now old news.  You could continue to use an existing C/C++ codebase with the new Carbon libraries providing a bridge to the new OS, but this did not allow you to use the new tools such as the Interface Builder.  If you wanted to take full advantage of the new tools Apple and the Cocoa libraries, you needed to use Objective C instead of the familiar C or C++.

Objectionable C

I had been a Mac programmer since getting my first machine in 1986, and when Apple released Mac OS X in 2001, I was fully expecting to continue that tradition.  However, while I had no problems whatsoever with the idea of learning a new set of API calls, or learning new tools, I saw no good reason why it should be necessary to learn a new programming language.  Still, at one time in my younger days I had enjoyed experimenting with different programming languages, so I figured why not give Objective C a try?

Upon doing so, my first thought was, this was an UGLY language.  My second thought was, why did they change certain bits of syntax around for no good reason?  There were things where the old-style C syntax would have gotten the job done, but they changed it anyway.  The third thing that occurred to me was that this was a REALLY UGLY language.

After a few brief experiments, I pretty much stopped playing around with Cocoa and Objective C.  I started playing around with Carbon.  My first project was to rebuild an old project done in C++.  But the first thing I ran into was frustration that I couldn’t use the new tools like the Interface Builder.  It wasn’t too long before I decided I wasn’t getting paid enough to deal with all this BS.  Objective C had sucked all the fun out of Mac programming for me.

The shift to Objective C marked the end of Macintosh development for many other programmers I’ve talked to as well.  One can only conclude from their actions that Apple simply doesn’t care… if one programmer drops the platform, another will come around.  I’m sure there are plenty of other programmers around who either like Objective C just fine or who simply don’t care one way or the other.

As far as I’m concerned, Objective C is an ugly language, an ugly failed experiment that simply has no place in the world today.  It offers nothing substantial that we can’t get from other languages like C++, C#, or Java.  Nothing, that is, except for access to Apple’s tools and libraries.

Some Mac developers would tell you that the Cocoa libraries depend on some of Objective C’s capabilities like late-binding, delegates (as implemented in Cocoa), and the target-action pattern.  My response is that these people are confusing cause and effect.   The Cocoa libraries depend on those Objective C features because that was the best way to implement things with that language.  However, I have no doubt whatsoever that if Apple wanted to have a  C++ version of the Cocoa library, they could figure out a way to get things done without those Objective C features.

A Second Look

A few years later when I got my first Intel-based Mac, I decided to revisit the development tools.  I wrote a few simple programs.  I’d heard a few people express the opinion that Objective C was sort of like the Ugly Duckling… as I used it more and became familiar with it, it would grow into a beautful swan.  Nope.  Uh-uh.  Wrong.  No matter what I did, no matter what I do, Objective C remains just as frickin’ ugly as it was when I started.

I really wanted not to hate Objective C with a fiery vengeance that burned from the bottom of my soul, but what are ya gonna do?  Personally, I’m looking into alternatives like using C# with the Mono libraries.  No matter how non-standard these alternatives are, they can’t be any more icky than using Objective C.

Could It Be That Apple Doesn’t Care About Making Life Easier For Developers? 

The real question here is why the hell hasn’t Apple created a C++ version of the Cocoa library?  It’s been 12 years since Apple bought out NeXT.  Why hasn’t Apple made an effort in all that time to adapt the NeXTStep tools to use C++?  Or other modern languages like C#?  Microsoft may have invented the C# language, but even the Linux crowd has adopted it for gosh sakes!

Or why not annoy Sun and make a native-code version of Java with native Apple libraries?

Could it be they are trying to avoid the embarrassment that would occur when developers abandon Objective C en-masse as soon as there is a reasonable replacement?

Does Apple think developers are happy with Objective C?  Personally, I’ve yet to find a single programmer who actually even likes the language.  The only argument I’ve ever heard anybody put forth for using it has always been that it was necessary because it was the only choice that Apple offered.  I know that’s the only reason I use it.

Why does Apple continue to insist on inflicting Objectionable C on us?  I can only come to the conclusion that Apple simply doesn’t care if developers would rather use some other language.  It’s their way, or the highway.

, , , , , , , , ,

13 Responses to “Objective C – A Failed Experiment”

Agreed, there’s no doubt in my mind that Obj-C as a language is an epic failure in so many ways. Doubtless the need to be able to pre-process it into C for compilation was a killer when they originally specified the syntax so I have some sympathy, but software languages should not be specified so as to make them easy for a machine to parse.

The result, unfortunately, is a completely bastardized, non-intuitive syntax, especially in the basic, everyday things like method invocation. For example: the first parameter in the call to a method (sorry “message to an object”, for the pedants out there) does not have a label, yet the other parameters do. Inspired decision! Actually, that’s not quite true — the label of the first parameter is apparently the name of the method itself, which makes it all so much more sensible (not). And I’m required to provide labels (for all but the 1st parameter) when invoking a method — oh, come on! And the method name itself ends is as many colons as the method has parameters, for example setOrigin:: It’s laugh out loud stuff, this syntax.

It’s a tragedy that the popularity of the (elegant) iPhone and its (again, elegant) Cocoa framework means that more people will now have to learn this (inelegant) nonsense when it should have died gracefully years ago.

totally true. i have programmed in many modern object orient languages and this is the worst language ever conceived. so verbose, so cryptic and so annoying syntax. without the code complete in the tool it is impossible to be productive. when other tool makers offered alternative way to progam for mac/iphone apple shut them down quick and brutal. steve jobs is the most evil guy in computer industry. a brilliant product marketer but also the most evil.

I agree with everything you say. Reading this article was a little like finding a soul-mate out in the world! 🙂

I’ve seen quite a few posts in various places like StackOverflow from people who think ObjC is just fine, but I have to scratch my head and wonder how anyone can actually like this fugly language.

But beyond ObJC specifically, what really bothers me most about Apple development is that I DON’T HAVE A CHOICE. If i want to fully utilize OS X features, I MUST use ObjC — and that really annoys me. There ought to be a more language-neutral way to do it.

As for iPhone programming, thank God for Corona (a Lua-based system), or else I’d never get involved.

Preach it, brother. Objective-C is just ugly, ugly, ugly as sin. Every time I finish a program in it, I get the same shameful feeling I used to get back in college when I’d wake up, hung-over, next to some fat chick whose name I couldn’t remember.

Thanks for the brief history lesson. I am new to Objective-C (having years of experience in other languages) and since reading about the basics I have been attempting to suppress an overwhelming urge to throttle whoever invented it. However, given the context that you’ve explained here, I am a little bit more forgiving (only just).

It really is a horrible language and I’m just glad to know that I’m not the only one out there who thinks so. Still, as you say, I can’t imagine why they haven’t made any attempt to get rid of it. The creation of the App Store was really inspired. Clearly Steve knew that the success of his iPhone largely depended on the development community creating cool apps for it, so he must have thought about all the ways he could encourage developers onto the platform. Sadly, changing the language wasn’t one of them.

Legend Reborn Says:

All of you are not seeing the other side of coin and becoming bias in favor of your favorite programming language.

All of the people who are blaming Obj-C are afraid of learning new concepts and syntaxes. Obj-C has been updated now.

Objective-C is a good language and self descriptive in nature. I like it

All the people here are afraid of learning new syntax and missing all the fun.

@Legend Reborn – I combined your 4 separate comments into one.

I assure you I am not afraid of learning new syntax. I’ve always enjoyed working with new programming languages. Some I like, others not so much.

The main problem I’ve got with Objective C is that it changes a lot of standard C syntax for no good reason. It takes several constructs that were relatively simple and changes or complicates them unnecessarily, even in cases where early versions of C++ had already demonstrated a simple, straightforward extension to the base C language. One need look no further than the example of calling a class method for a particular object.

C++ : Object.Method(arg1)
Obj-C : [Object Method:arg1]

This is a fairly simple example, but any experienced C programmer will know what the first example does, while the second one will cause most to scratch their heads for a moment, at the very least. If the Obj-C syntax provided some advantage, I wouldn’t mind, but it does not, and in fact virtually all of the language features that Obj-C proponents tout are things that have little or no dependency on the syntax. It seems they made the syntax different merely for the sake of it being different.

However, none of that matters nearly as much as the fact that Objective C has virtually zero usage outside of Apple’s product line. It’s ultimately counterproductive for Apple to insist on using a programming language that nobody else wants to use, particularily when they spend so little effort on supporting anything else.

I’am long time develper that used various programming languages Java, C#, Javascript, PHP for web and desktop applications. Now I am working on Java Android and Objective C Iphone/Ipad applications.

What I like most ? Apple – OBJECTIVE C 🙂

Especially Apple libraries and possibility to create categories so i can have less code to write… Also big Github community of free libraries that Android does not have…

And auto synthetized properties… and ARC !!! No memory problems while on Android problems with big images and simmilar memory problems due to GC concep.

“What I like most ? Apple – Objective C… Especially Apple libraries”

That isn’t a language feature. Apple’s libraries would exist regardless of what language was used to create them.

“Also big Github community of free libraries that Android does not have.”

Again… not a language feature. Perhaps you thought this article was about Apple -vs- Android, but if so, you’ve misunderstood.

Auto-synthesized properties are one of Obj-C’s few redeeming qualities, but the time they save is not all that significant, in my opinion, and they can occasionally be the source of a “What the heck is going on with that… ” moment when the code generated isn’t quite what you had in mind.

“No memory problems…”

While it’s true that Java is a managed environment and Objective C is not, I think you’d find that on average, Java applications have far fewer memory-related problems as a result. No worries about memory leaks, stray pointers, etc. Given your reference to big images, it sounds like you’ve run into problems with being unable to allocate as much memory as you wanted. That’s almost certainly because of Android OS restrictions on memory usage, not because Java is a managed environment. It’s not a language issue at all.

One thing regarding Objective-C which deeply puzzles and annoys me is the “init” methods of NSArray (and collections alike):

NSArray* array = [[NSArray alloc] initWithObjects: a, b, c, nil];

The array content is lexically there, I don’t know why we need to terminate them with a redundant nil. That nil, however, is not needed when initializing array with only one object:

NSArray* array = [[NSArray alloc] initWithObjects: a];

And the retain / release cycle is truly a hell of mine. That says autorelease can do the job. Why still retain / release in constructor and destructor? The “auto” mechanism simply defeats itself, not to mention addition of a lot confusion.


I keep running into Obj-C for several years. No surprise, Apple popularity is on the rise.
And I totally hate it. It’s crappy, hideous language, featuring a pathetic, incongruous syntax, horrendous verbosity and idiotic and conflicting object management paradigms (in the order they were introduced: place it with the programmer, GC and now ARC).
The language feels like design for morons, certainly not for programmers. It takes any joy out of software development, it makes me hate my job. It makes me feel ashamed.

Years on and this still holds true. I graduated from university in 2008, one year after the first iPhone released. That same year I got the first Android phone released in the country, the T-Mobile G1, and really took to Java development and the Android Platform. Being a C/C++ fluent fresh graduate with just enough C# knowledge to be dangerous I embraced the multitude of libraries and tools available and slipped into a comfortable relationship as an Android hobbyist and enthusiast until around 2012 when I decided to be a full-time Android developer. The decision to dedicate my studies to Android was no accident.

In 2011 I worked for a small independent games studio. During that time I was tasked with adding features to an existing project written for Unity which necessitated learning a little bit of how iOS and its associated tools function. I never recovered from that experience. Something as simple as setting up as creating a variable seemed unnecessarily long-winded. Unlike every other C style language the syntax for creating a “class”, “method”, or “interface” was compounded by the fact that all conventional tools are shockingly named something completely different in the context of Objective-C. The amount of difficulty experienced in just getting started combined with the effort required to do simple things to a schedule eventually led me to abandon the pursuit of Objective-C all together. As time has gone on and market share has shifted drastically toward Android – even in the wake of Swift – I know that I made the correct decision. I don’t know how Objective-C has managed to survive this long and frankly I don’t care. I won’t be investing in it directly because it’s just not worth the time.

Leave A Comment