
Objective-C's niche: why it survives in a world of alternatives - twampss
http://cocoawithlove.com/2009/10/objective-c-niche-why-it-survives-in.html
======
gte910h
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
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>

------
petercooper
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.

~~~
yan
> 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
jvm support has been deprecated. other language options are 2nd thoughts.

~~~
steveklabnik
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.

~~~
tumult
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.)

~~~
steveklabnik
Ah, thanks. It's funny, I love Apple, and I love Ruby, but I've yet to code
Ruby on a Mac.

------
bensummers
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
Yes! I first used delegates in Obj-C/Cocoa. When I then learned .NET
delegates, my first thought was "Ewww!"

~~~
kls
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.

~~~
jimbokun
"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.

~~~
kls
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.

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

------
davidw
> 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.

~~~
ComputerGuru
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
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).

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

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

~~~
pohl
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.

------
mr_dbr
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
MacRuby:

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

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

~~~
cpr
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
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.

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

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

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

~~~
allertonm
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.

~~~
jimbokun
"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.

