Objective-C's niche: why it survives in a world of alternatives

http://cocoawithlove.com/2009/10/objective-c-niche-why-it-survives-in.html

by twampss • 17 years ago

70 60 17 years ago

davidw• 17 years ago

> And for a company known to replace CPU architectures and their entire operating system, why does Apple persist with Objective-C?

Swapping out an architecture is way easier than rewriting hundreds of thousands (millions?) of lines of code. Orders of magnitude easier if there is any abstraction at all.

They avoid changing because the perceived benefits are smaller than the costs, which include large switching costs.

gte910h3• 17 years ago

I also think Objective C is quite a bit better than C++....and hope they share that same opinion, as that would be the logical replacement language.

ComputerGuru• 17 years ago

Easily millions. If you said > 1 billion, I think you'd still be in the clear.

We're working on middle-size end user software and we have millions of C++ lines of code. So I can only imagine how many lines of code Apple has riding on Objective-C.

jpcx013• 17 years ago

Well, Apple doesn't only write Objective-C. I'd bet a majority of the code they write is plain C and C++ for internal OSX stuff. And some of their major projects are still Carbon (C++) (though they are trying to port to Cocoa).

petercooper• 17 years ago

This is a nice look over some of Objective C's plus points, but the underlying answer to the question posed is less positive. Why does Objective C survive in a world of alternatives? Because Apple makes it tough not to use it.

malkia• 17 years ago

If you are talking about Cocoa (NextSTEP, OpenStep, etc.) being exposed to other languages - then it actually happened - in JAVA in WebObjects, but it was found that was not easy to use, as it was in Objective-C.

I think Apple have found their middle ground with Objective-C - you can really separate the designer/programmer jobs - one creating the Interface, the other programming it.

With Visual Studio, as soon as you double click on the button you are in the code. Some people (me) prefer that, because I'm in a position where I have to design/code myself most of the time, and it seems easier, but over the time, it looks like that's the only easy thing, as soon as your interface grows more complex, then it seems easier to describe most of the connections in IB, rather than your code.

Davertron• 17 years ago

You seem to be talking about XCode and the interface designer, not Objective-C; as far as I can tell, there's no reason they couldn't have nice tools and use another language besides Objective-C (I'm not advocating for that, just stating a point).

jpcx013• 17 years ago

Thats a good point. The switch from Objective-C to Java in WebObjects destroyed it. Maybe it would have died anyways, but it was definitely the final nail in the coffin as all the best WebObjects developers stuck with version 4.5 instead of upgrading to 5.0 (the java one).

Internally, I've heard Apple uses WebObjects 4.5 for their stores, mobileme, and other web projects.

acangiano• 17 years ago

Luckily, thanks to the efforts of a Belgian "chocolatier", MacRuby has a serious shot at changing this.

jpcx013• 17 years ago

Holding out great hope! Still learning Objective-C and Cocoa for iPhone development, however as soon as MacRuby surfaces, I'll be switching to it in a heartbeat :-)

StrawberryFrog• 17 years ago

Sure apple promotes Objective C. But that just raises the question: What does Apple see in Objective C? What is its merit to Apple?

ams61102• 17 years ago

Well big chunks of the code base that they bought from NeXT were Obj-C. So there's the legacy issue. And as protomyth said, in the early days of OS X they really tried to convert people to Java but few developers got on board with it. Maybe because most people writing Cocoa apps in the early days were former NEXTSTEP developers and they used what they knew. Using Java to write Cocoa apps probably felt a bit like using COBOL to write .NET apps. You can do it, but it's probably not too fun.

yan2• 17 years ago

> Because Apple makes it tough not to use it

That's not very accurate. Apple has gone out of their way more so than other companies in giving you options. Apple has always provided the Java bridge for their entire Cocoa API which exposed all of its functionality to the JVM. Apple also ships Python and Ruby bindings and provides documentation and sample code on how to use them.

I have limited experience with all those bindings, but I choose to use Obj-C. In my humble opinion, it's an excellently-designed language that mixes low and high level concepts with great success.

ohhmaagawd• 17 years ago

jvm support has been deprecated. other language options are 2nd thoughts.

henriklied• 17 years ago

But you still can't write PyObjC for the iPhone, right?

Tamerlin2• 17 years ago

IMO it's more like C# and .NET than that Apple is making it tough to not use Objective-C.

First look at .NET... there are a lot of .NET developers who think of .NET and C# development as the same... but there are also .NET developers using Ruby, VB#, F#, C++ .NET, and a growing number of scripting languages.

What I've seen of the Cocoa environment isn't Apple restricting developers from using languages other than Objective-C, but rather that Apple is putting its own efforts into Objective-C.

I would agree that Apple seems to be making Java hard to choose for programming the mac lately, but I'd call that progress, and therefore a positive, not a negative ;)

protomyth4• 17 years ago

Apple, for a while, tried pretty hard to make Java a first class citizen of the Cocoa framework, but it just was a bad fit. Non-dynamic languages don't really do well with dynamic frameworks.

It is interesting that the drop in love for Java occurred around the same time that Carbon was shown the door.

lucifer4• 17 years ago

Its a nice article and the objective-C specific content was informative, but it fails to convince given the fact that it does not even mention aspect orientation.

In a language like Java, declarative application of AOP constructs (such as that of AspectJ) give you all the benefits OP cites for dynamic dispatch, with the further benefits of (a) being still able to reap the benefits of efficient look-up and optimization, and, (b) using declarative programming (which allows for clean decoupling and thus even greater reuse).

Objective-C lives because (as pointed out in another comment) your Mac OS programming life is much more difficult if you choose not to use it.

btilly3• 17 years ago

All of the benefits?

Does it help you when using someone else's framework that you didn't write and can't control? That being the key benefit that he started with then repeated over and over again.

lucifer4• 17 years ago

Yes.

http://eclipse.org/aspectj/doc/released/progguide/index.html

allertonm• 17 years ago

If that were true, surely the Mac world would be dominated by Java applications written using AspectJ and the Java-Cocoa bridge?

As it turns out, that didn't happen - and not because Apple didn't try pushing Java as a Cocoa development language. What happened was users pushed back on slow launching, memory hungry Cocoa-Java apps.

So another reason for Objective-C's success is that yes, it does all the things the original article states, but it also does them in an Ahead-Of-Time compiled, non-Virtual-Machine language - and that combination is pretty unique.

My suspicion is that Obj-C's unique combination of features plays a large part in NeXT/Apple's success in producing a set of frameworks that are high-level enough to allow for rapid development, but are also able to create responsive applications on the desktop AND be able to scale down to mobile devices.

jimbokun3• 17 years ago

"My suspicion is that Obj-C's unique combination of features plays a large part in NeXT/Apple's success in producing a set of frameworks that are high-level enough to allow for rapid development, but are also able to create responsive applications on the desktop AND be able to scale down to mobile devices."

This does not get nearly enough attention when people think about the successes Apple has had over Microsoft since OS X. The sweet spot of a fast, compiled, dynamic language and tools built to leverage those strengths gives Apple a lot of flexibility and productivity in design and implementation, from the OS level to the GUI tool kit level. I think that where Microsoft increasingly found themselves pushing a ball of mud uphill with the Windows code base, Apple was able to do a lot of clever things with their software stack without changing the underlying design and architecture. Like porting their PC OS to a cell phone and allowing their developers to leverage much of their existing skills to make apps for it.

During Jobs' Nexodus, the NextStep environment became the main product because it was such a productive way to build software. With the return to Apple, it stopped being the product and started becoming a competitive advantage.

bensummers2• 17 years ago

Also the delegate design pattern, which Cocoa uses to great effect, is nicer to implement in Objective-C than other languages. Instead of having to define a formal interface which is explicitly used and all the member functions implemented, you just have to implement the relevant methods. Whether the delegate implements a method is looked up at runtime rather than checked with static typing.

9oliYQjP• 17 years ago

Yes! I first used delegates in Obj-C/Cocoa. When I then learned .NET delegates, my first thought was "Ewww!"

bensummers2• 17 years ago

Just looked those up. Sounds, er, fun. I suppose the clean implementation in Objective-C is a side effect of it being an oddly static dynamic language. But the oddness does yield a very nice application framework.

kls2• 17 years ago

If you think that is bad try using the Java pattern for implementing delegates, outright nasty. Personally, I like languages that treat methods as first class objects and allow for the passing of them just like any other variable.

I think delegation is one of the least understood, but most powerful techniques in programming. Being able to inject functionality into another routing based on context allows for reusable work-flow while injected context specific work-flow into that routine, but still allowing that context specific work-flow to have access to encapsulated scope outside of the routine.

This is extremely powerful flexibility, that allows a developer to accomplish developing more functionality with less lines of code.

transmit101• 17 years ago

This is the result of Objective-C's Smalltalk ancestry: similar design patterns are elegant to achieve in other Smalltalk-inspired languages as well, for example SuperCollider[1] and (to perhaps a lesser extent) Ruby.

[1] http://supercollider.sourceforge.net

wallflower• 17 years ago

I'm waiting for IntelliJ to support Objective-C (refactoring support in XCode is pitiful compared to what IntelliJ can do for Java).

pohl• 17 years ago

You may not have to wait that long. One of the reasons that the clang front-end is being written as a library is so it can be used for better refactoring in a future version of XCode.

gte910h3• 17 years ago

I am an embedded developer by training, and have been doing it for my entire career.

I've done C, Assembler, C++ and even python on some embedded devices, as well as the occasional javascript or shell scripts running the show.

Objective C, hands down, is the least hellish language I've EVER done embedded development in. Would I take a python runtime on the iPhone? In a heartbeat. Barring that am I okay with Objective C: Oh hell yes.

It has all the access you may want to C (libraries, certain operations), along with a bolted on smalltalkesque object system that is not overly templated (like java) or overly fiddly and easy to break (like C++) or just plain added on poorly (like lisp).

klipt• 17 years ago

If by lisp you mean CLOS, it's not meant to be a smalltalkesque (i.e. message passing) object system at all - it's a multiple dispatch system:

http://en.wikipedia.org/wiki/Multiple_dispatch http://c2.com/cgi/wiki?MultipleDispatch

Hexstream• 17 years ago

In what way(s) is Common Lisp's (I assume?) object system "just plain added on poorly"?

joe_the_user2• 17 years ago

I'm doing Qt/C++ development. On first glance, Qt's message-passing system seems about as flexible as the objective-C system (Qt using a custom pre-processor for their C++ and then feeds it to the compiler of choice).

joe_the_user2• 17 years ago

Also, it doesn't seem that strange that Apple would persist with their own "weird" language (good or bad). Apple is a classic vertical monopoly in a land of horizontal monopolies. Doing everything their unique way is desirable for them, not just when it helps them but even when it costs extra, as long it doesn't cost too much extra.

ams61102• 17 years ago

Objective-C is not Apples "own" language. They (and NeXT, before them) used it to build the Cocoa framework but Objective-C is an add-on to GNU C and freely available for anyone to use. The language dates back to the 1980's at least.

martingordon• 17 years ago

I like Objective-C a lot, but there are things that could use some work, and I think a lot of issues stem from its C roots. Garbage collection, while a great addition, is not entirely seamless to use. Blocks, because of the fact that they're a C feature and not an Objective-C feature, are verbose and complicated to define. The ton of boilerplate code required is also a bit painful.

All that said, I wouldn't switch to using any other language with Cocoa because the APIs are natural to Objective-C and they feel quite clunky when used in another language. MacRuby, and particularly HotCocoa, are interesting, but again, there's a re-learning curve involved.

cpr3• 17 years ago

I think part of Apple's success (repeating a story I told elsewhere on HN, about an Apple exec who used to be a core Smalltalker at Xerox PARC) is that they've organically grown a killer, but slightly oddball set of tools that work together very well as a whole. (Objective-C and Cocoa.)

Looked at from the outside, the language oddities (a static, low-level language like C with a very Smalltalk-like flexible runtime system plus the minimum syntax for Smalltalk-style message invocation) are quite off-putting.

It's not until you get inside and really use the system that you can appreciate how well it works.

So people usually just "stay away" unless they really want to get into that particular ecosystem for other reasons (now it's market size for the iPhone; before, it was the cleaner & more compelling Mac OS software niche).

Again, it's not any one particular feature (though most of the individual features are enablers, and can't be dropped), but the overall gestalt that is so (er, can't use "synergistic", I've already used "compelling", how about) coherent.

Cocoa (Foundation and AppKit), and now CocoaTouch, are exceedingly well-crafted, powerful, dynamic-language frameworks that have evolved organically for over 20 years, starting from the NeXT days.

The secret star behind this secret weapon is Ali Ozer, who's had a strong hand on the frameworks' tiller since the beginning, and who's still there.

So, just as Steve Jobs has a singular vision which keeps their hardware efforts focussed, Ali (& his crew, now with a lot of momentum and shared "taste" after all this time) have the same focus at the software framework level.

cpr3• 17 years ago

I've worked quite a bit on the design of a language I call Objective-CX, which leaves most of the higher-level features (Smalltalk-like message-passing) alone but brings the lower-level C features up to a higher level (such that [ ] means dictionary- or array-lookup, etc., like Python, and has NSDictionary and NSArray literals), but is otherwise entirely Objective-C object-based (no bridging), but it's too large an undertaking for a hobby OSS project.

And, it looks like MacRuby is going to be the high-level alternative to Objective-C, with no bridging required.

protomyth4• 17 years ago

Given its evolution, you might want to take a look at F-Script http://www.fscript.org/ - it is basically a Smalltalk-derivative with some unique array-oriented additions. In version 2, you can now create classes using F-Script.

cpr3• 17 years ago

Yes, I'm quite familiar with F-Script, but serious Obj-C programmers are never going to accept a non-Obj-C syntax. Sad to say...

mr_dbr• 17 years ago

Good or bad, I'd say Apple are pretty much stuck with ObjC. Cocoa and all the other frameworks OS X uses are written like they are because of the language's syntax. This is demonstrated by how crappy the PyObjC code looks (compared to "regular" Python):

    notificationCenter.addObserver_selector_name_object_(
        notificationHandler,
        "handleMountNotification:",
        NSWorkspaceDidMountNotification,
        None)

To make it work with some other language (say, C#/C++/Ruby/Brainfuck/Python or whatever) would basically be a complete redesign of the framework, which in turn would basically be a complete redesign of OS X.. And why? Objective C is a perfectly decent language.. I'm not sure anyone would be using it where it not for Carbon/Cocoa, but it's not a bad language at all

dchest• 17 years ago

MacRuby:

  notificationCenter.addObserver(notificationHandler, 
                        selector:"handleMoundNotification",                
                        name:NSWorkspaceDidMountNotification,
                        object:nil)

azirr• 17 years ago

Yes, the messaging syntax (which is very expressive) makes it hard to use other languages with Cocoa, but not all. Your example in F-Script gives:

  notificationCenter addObserver:notificationHandler
                     selector:#handleMountNotification:
                     name:NSWorkspaceDidMountNotification
                     object:nil

coolmenu• 17 years ago

I think apple will use macruby to replace some objective-c's app.

Objective-C's niche: why it survives in a world of alternatives

Related Stories