> 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.
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.
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).
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.
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.
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).
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.
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 :-)
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.
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.
I don't think MacRuby is really a second thought. I mean, I haven't personally done anything with it, as I like Objective C as well as Ruby, but I've only heard that the integration is absolutely stellar.
He's talking about RubyCocoa, which is what OS X comes with, not MacRuby. RubyCocoa uses the Objective-C/Cocoa object bridge, to allow Ruby to talk to Cocoa objects and send messages.
MacRuby is a different beast. It compiles with LLVM, is not bridged, and therefore works directly with Obj-C/Cocoa.
(Though, honestly, the bridged languages are really pretty good, too. Obj-C bridging is good in general. MacRuby is just sensational.)
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 ;)
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.
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.
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.
The whole manual isn't exactly a lot of help since I don't know what I am supposed to be looking for in there.
As a concrete example, can you walk me through how you can take a function that expects to receive objects of a specific class, and instead give them objects of another class? In particular imagine that you are implementing something like NSProxy, and are replacing objects that had lived locally with distributed objects that now exist on a different machine that you access with remote code calls.
The objects have to be usable within a framework that is expecting the original kind of object, and you do not have access to source code or the ability to recompile.
Not necessarily a tutorial. However in response to a specific question I would hope for a specific pointer on how you might do that specific thing. The link you gave me the second time was far more helpful for re-evaluating aspect-oriented programming's capabilities in this regard than the manual.
In particular I am now convinced that it can do things that I had not previously realized were possible.
Theoretically, aspect orientation can even reach inside the code that is being modified: join points can include loops and branches, but aspectJ does not provide that functionality.
Anyway, the point that I was making is that virtual method dispatch coupled with virtual machines afford the possibility of models of indirection that are more efficient, more expressive, and formally declarable.
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.
"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.
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.
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.
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.
"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."
I up-voted you even though I was unable to parse this sentence.
First thanks for the up-vote. Let me see if I can try to explain it a little more linearly and see if it helps. You have a generic function that you pass in a reference to another function, the generic function does a generic routine and then calls the reference function at a specific point. The reference function then returns a value that the generic function uses to give it a calculation that it wil use in its routine. The interesting part is the reference function can have scope visibility outside of the generic function. This allows for very loose coupling, where one can inject a function into a master function and all scope for the referenced function can be abstracted away from the generic function. It makes the only hard contract between the two the return value of the referenced function and possibly the parameters. It eliminates the need for interfaces or tight coupling to build systems such as listeners, notifiers, callbacks and event systems.
I hope that helps, if it is just a convoluted, then I am sorry. Delegates are a pretty abstract subject and I may not be the best at explaining them.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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):
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
60 comments
[ 3.1 ms ] story [ 71.0 ms ] threadSwapping 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.
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.
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.
Internally, I've heard Apple uses WebObjects 4.5 for their stores, mobileme, and other web projects.
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.
MacRuby is a different beast. It compiles with LLVM, is not bridged, and therefore works directly with Obj-C/Cocoa.
(Though, honestly, the bridged languages are really pretty good, too. Obj-C bridging is good in general. MacRuby is just sensational.)
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 ;)
It is interesting that the drop in love for Java occurred around the same time that Carbon was shown the door.
:D
It's no loss... it's just Java. Old... creaky... and why are we still using it again? (Oh, right -- for the progress-averse developers.)
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.
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.
http://eclipse.org/aspectj/doc/released/progguide/index.html
As a concrete example, can you walk me through how you can take a function that expects to receive objects of a specific class, and instead give them objects of another class? In particular imagine that you are implementing something like NSProxy, and are replacing objects that had lived locally with distributed objects that now exist on a different machine that you access with remote code calls.
The objects have to be usable within a framework that is expecting the original kind of object, and you do not have access to source code or the ability to recompile.
Thanks.
The gist: byte codes are transformed ("weaved") on load. Its irrelevant whether you have the source or not.
http://my.safaribooksonline.com/0596006543/aspectjckbk-CHP-1...
In particular I am now convinced that it can do things that I had not previously realized were possible.
Anyway, the point that I was making is that virtual method dispatch coupled with virtual machines afford the possibility of models of indirection that are more efficient, more expressive, and formally declarable.
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.
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.
(Obj-C is basically Smalltalk on top of C with a rocking API).
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.
Agreed. Which ObjC doesn't entirely do; SELs and IMPs are primitive types rather than objects, which is annoying.
I up-voted you even though I was unable to parse this sentence.
I hope that helps, if it is just a convoluted, then I am sorry. Delegates are a pretty abstract subject and I may not be the best at explaining them.
[1] http://supercollider.sourceforge.net
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).
http://en.wikipedia.org/wiki/Multiple_dispatch http://c2.com/cgi/wiki?MultipleDispatch
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.
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.
And, it looks like MacRuby is going to be the high-level alternative to Objective-C, with no bridging required.