7 ms·

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

70 points by twampss 17y ago

davidw 17y 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.
- gte910h 17y 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 17y 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.
  - jpcx01 17y 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).
lucifer 17y 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.
- btilly 17y 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.
  - lucifer 17y ago
    Yes. http://eclipse.org/aspectj/doc/released/progguide/index.html http://eclipse.org/aspectj/doc/released/progguide/index.html
    - btilly 17y ago
      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. Thanks.
      - lucifer 17y ago
        I didn't realize you expected a tutorial in aspect orientation! 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-18-SECT-6 http://my.safaribooksonline.com/0596006543/aspectjckbk-CHP-1...
        btilly 17y ago
        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.
petercooper 17y 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 17y 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 17y 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).
  - jpcx01 17y 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.
    - jimbokun 17y ago
      I think they've finally switched to the Java version across the board (from an Apple employee friend of mine) but it took a long time to get there.
bensummers 17y 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 17y ago
  Yes! I first used delegates in Obj-C/Cocoa. When I then learned .NET delegates, my first thought was "Ewww!"
  - bensummers 17y 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.
    - gte910h 17y ago
      Obj-C delegates look like how smalltalk does delegates. (Obj-C is basically Smalltalk on top of C with a rocking API).
  - kls 17y 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.
wallflower 17y 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 17y 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.
gte910h 17y 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 17y 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://en.wikipedia.org/wiki/Multiple_dispatch http://c2.com/cgi/wiki?MultipleDispatch http://c2.com/cgi/wiki?MultipleDispatch
- Hexstream 17y ago
  In what way(s) is Common Lisp's (I assume?) object system "just plain added on poorly"?
joe_the_user 17y 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_user 17y 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.
  - ams6110 17y 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.
    - protomyth 17y ago
      I do believe Apple (via NeXT) does own the trademark bought from Stepstone.
martingordon 17y 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.
cpr 17y 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.
cpr 17y 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.
- protomyth 17y ago
  Given its evolution, you might want to take a look at F-Script http://www.fscript.org/ 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.
  - cpr 17y 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...
    - protomyth 17y ago
      I actually think that after using Obj-C, some percentage of "serious" Obj-C programmers will find going farther into the Smalltalk world a good thing.
mr_dbr 17y 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 17y ago
  MacRuby: notificationCenter.addObserver(notificationHandler, selector:"handleMoundNotification", name:NSWorkspaceDidMountNotification, object:nil)
- azirr 17y 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 17y ago
I think apple will use macruby to replace some objective-c's app.

70 points by twampss 17y 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.

gte910h 17y 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 17y 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.
- jpcx01 17y 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).

lucifer 17y 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.

btilly 17y 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.
- lucifer 17y ago
  Yes. http://eclipse.org/aspectj/doc/released/progguide/index.html http://eclipse.org/aspectj/doc/released/progguide/index.html
  - btilly 17y ago
    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. Thanks.
    - lucifer 17y ago
      I didn't realize you expected a tutorial in aspect orientation! 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-18-SECT-6 http://my.safaribooksonline.com/0596006543/aspectjckbk-CHP-1...
      - btilly 17y ago
        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.

petercooper 17y 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 17y 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 17y 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).
- jpcx01 17y 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.
  - jimbokun 17y ago
    I think they've finally switched to the Java version across the board (from an Apple employee friend of mine) but it took a long time to get there.

bensummers 17y 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 17y ago
Yes! I first used delegates in Obj-C/Cocoa. When I then learned .NET delegates, my first thought was "Ewww!"
- bensummers 17y 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.
  - gte910h 17y ago
    Obj-C delegates look like how smalltalk does delegates. (Obj-C is basically Smalltalk on top of C with a rocking API).
- kls 17y 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.

wallflower 17y 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 17y 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.

gte910h 17y 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 17y 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://en.wikipedia.org/wiki/Multiple_dispatch http://c2.com/cgi/wiki?MultipleDispatch http://c2.com/cgi/wiki?MultipleDispatch
Hexstream 17y ago
In what way(s) is Common Lisp's (I assume?) object system "just plain added on poorly"?

joe_the_user 17y 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_user 17y 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.
- ams6110 17y 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.
  - protomyth 17y ago
    I do believe Apple (via NeXT) does own the trademark bought from Stepstone.

martingordon 17y 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.

cpr 17y 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.

cpr 17y 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.

protomyth 17y ago
Given its evolution, you might want to take a look at F-Script http://www.fscript.org/ 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.
- cpr 17y 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...
  - protomyth 17y ago
    I actually think that after using Obj-C, some percentage of "serious" Obj-C programmers will find going farther into the Smalltalk world a good thing.

mr_dbr 17y 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 17y ago
MacRuby: notificationCenter.addObserver(notificationHandler, selector:"handleMoundNotification", name:NSWorkspaceDidMountNotification, object:nil)
azirr 17y 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 17y ago

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