
Objective-C's niche: why it survives in a world of alternatives - stephth
http://www.cocoawithlove.com/2009/10/objective-c-niche-why-it-survives-in.html
======
zoul
I find it surprising that there are so many people bashing Objective-C here in
the comments. I have been programming in Objective-C for living since the
iPhone SDK came public and I came to love both the language and the libraries.

I think that many people who despise Objective-C syntax are simply not
programming long enough in the language to overcome the initial knee-jerk
reaction. Mostly the issue seems to be the message passing syntax, which I
find very readable and self-documenting. What else should matter if not this?

Then there’s comments about speed. I have written two action games for the
first-generation iPhones and I have never encountered a performance problem
caused by the runtime. Over 99% of the time I could stick to high-level code
without resorting to C to gain speed. That says _a lot_ about performance for
regular applications.

Block syntax could be better, I can’t use closures with such ease as in Perl
(for example). But this is one of the things that have to do with Objective-C
being a relatively thin layer atop of C. And that I see as a huge win, because
you can very easily and naturally mix higher-level Objective-C code with plain
C APIs that are very common on most systems. And if you want some lower-level
bit-twiddling trickery for performance reasons, you are free to go. For me, C
is a very elegant language and Objective-C takes out most of its rough
corners.

Saying that Objective-C could be replaced by something “smarter” like Lisp or
Haskell is simply ignoring the reality. Objective-C has very low language
complexity, both the building blocks and their interactions are simple and
there are few surprises. This is a huge advantage both for the newcomers and
for programmers that deal with the stack most of their working hours.

The manual memory management first seemed like a chore to me after coming to
Objective-C from Java, but the rules are dead simple and after a few weeks you
don’t think about the memory management any more.

Yes, Objective-C is not hip. So what? It’s a pragmatic and reasonably
expressive language that gets the job done. I don’t think that replacing it
would serve any real purpose – and that’s a very good reason to survive.

~~~
tomjen3
My biggest beef with Objective C is that it takes the most retarded feature of
C++ -- that you have to write both a header and a implementation file (why oh
why can't the compiler compile one?) -- and removes the really nice ability to
allocate your object on the stack (which means memory allocation is really,
really, cheap and you know when the object is deallocated).

~~~
zoul
As for the header/implementation split, I might have been brainwashed by the
language, but I like it :) I take it as a nice division between the public
interface and private implementation. And now that we have purely synthesized
properties in the modern runtimes, we can keep the header file really clean:

<https://gist.github.com/766381>

I have never missed allocating objects on the stack, I am mostly happy with
autorelease pools. They are slower and “less deterministic” than stack-based
objects, but I don’t mind.

------
fingerprinter
Obj-C survives b/c it is the only real way to write iPhone and iPad apps,
plain and simple (ignoring Appcelerator and PhoneGap for the moment). If
people had options, it is likely they would use the alternatives.

Look at Linux. The "official" language will always be C, but there are
toolkits for building GTK apps in Python, Vala, Mono and other even more
obscure languages. Some pretty big apps have been written in each and people
will continue to use those as long as they are viable options. If, however,
someone big enough and with enough clout basically said "only native C/GTK
apps will be accepted on our platform", you would see people migrate to that
toolchain. It is simple economics.

Apple has the clout (imo, unfortunately) to do that and have done it with
Obj-C. They basically killed Java, which was an option up until I think 2
years ago. I can see Apple's perspective, supporting two toolkits is expensive
and takes time, resource, energy and focus. In their mind, what benefit to
they gain from supporting multiple toolkits? Developers? They know they are
popular enough that the developers will take up Obj-C when Java was dropped.
Sure there will be grumbling and moaning, but Apple DOESN'T CARE ABOUT
DEVELOPERS except that they make apps to attract the users.

I'm not saying what Apple did is right or wrong, but it does make sense from a
strategic point of view. However, there is practically no merit to Obj-c on
it's own. There are more compelling alternatives at nearly every turn, but NOT
if you want to play in the iphone and ipad ecosystem.

~~~
zoul
What would you rather write iOS/Mac applications in if not Objective-C?

~~~
palish
Me personally? Lua. That language is as simple and as rugged as a cockroach.

~~~
ams6110
<https://github.com/probablycorey/wax>

------
jrockway
Objective-C's niche: it's the core of two popular operating systems.

A lot of strange programming languages survive because of inertia. Emacs Lisp
exists because Emacs was written by Lisp hackers. It survives because Emacs
ships with a few million lines of Lisp. Replacing it would take hundreds of
man-years.

Objective-C survives for the same reason; Cocoa was expensive to write and
rewriting it would serve no purpose. So it remains. Is anyone using
Objective-C for some reason other than writing OS X or iOS apps?

~~~
fleitz
No, and if there was an easy way to bind UIKit with out Obj-C I'd use it in a
heartbeat. I'm seriously considering WAX for LUA. Obj-C has the flexibility of
C with the speed of small talk.

~~~
boucher
That strikes me as a pretty indefensible statement. Objective-C has an
incredibly powerful runtime, which is nearly as flexible as the ruby runtime.
It's also much much faster than ruby, and probably every other popular dynamic
language.

~~~
fleitz
I'm sure the runtime is great, unfortunately the syntax sucks, there is no GC
(on iOS) and it can't curry functions, and you can't put an NSInteger into an
NSDictionary with out line noise that would do java proud, it doesn't support
passing or currying functions.

Sorry, but passing a selector and an object is atrocious, even MS can figure
out how to pass a delegate that can figure out whether it needs to pass a this
pointer before passing the rest of the arguments.

It's lambda syntax is also attrocious [[ ^ (int x, int x) { return x+y; }
copy] autorelease] , wtf is that garbage?

In ruby I don't need to touch 2 different files and put code in 3 places just
to define a property, nor do I have to do this in C# or F#.

I doubt it's much faster than C# or F#, especially if it ever involves
something simple like putting an integer in a hashtable.

I'd hardly call a language dynamically typed when it will fuck up adding a
long and an int. Seriously, define a type that takes an int, pass it a long
and see what happens. This is exactly what I mean by the flexibility of C
(attrocious type system) and the speed of small talk (incurring a call to
objc_msg_send anytime you do anything)

~~~
koko775
* Syntax sucks: I think Objective-C is actually pretty beautiful. Maybe I'm crazy.

* NSInvocation should serve the same purpose in most cases.

* I find the block syntax atrocious if compared to Lisp lambdas. It's not that bad. Blocks are objects, so you're creating an object, with all the same predictable retain/release semantics. Maybe a few gotchas if you're not reading the documentation and realize you should avoid retain loops. Hardly different from Java, only it's easier to miss it in Java, because you never release, anywhere.

~~~
mattgreenrocks
The lack of namespaces seems silly to me: NSThis, NSThat.

It isn't that Obj. C is a bad language, it's just it doesn't feel like a more
modern language, and yet it gets used because of the possibility of $$$. I do
understand that you can come to love a language after a period of using (and
understanding) it. And I do think a systems-level language should be used for
apps on mobile devices, but we don't have to continue to be mired in
implementation details that were an artifact of a language from the seventies.

I need to play with it more to get a better feel for it.

------
jinushaun
Based on the comments, seems like most people's objections of Objective-C are
really objections about C: header files, manual memory management, function
pointers, strong type system, too low level, no native string object, etc. I
grew up with C, so learning Objective-C took maybe 10 minutes because it's
basically C with some extra syntax for OOP. In general, one only encounters
the "strange" syntax when dealing with methods. I personally love the method
syntax because it's basically self documenting.

Which leads me to wonder, how many programmers both on HN and in general know
C? I'm too young to already be a dinosaur in this industry... Where did all
the C programmers go? Seems like programmers nowadays started learning how to
code with Java or Ruby/Python and expect all other languages to be just as
high level. Objective-C _is_ low level, which makes it harder, but doesn't
make it suck.

As a language, I think Objective-C is a fine one, but I must admit that it is
a "dinosaur". The real problem is OOP paradigm. Remember, back in the late 70s
and early 80s, OOP was new and exciting and C was the dominant language.
People were trying to figure out what OOP _should_ look like and how to make C
more OO. NextStep (Apple) just happened to bet on the wrong horse. Obj-C went
with Smalltalk syntax, while the rest of the world went with C++ syntax and
ultimately the Java style syntax we know and love today. Seems like some
developers can't wrap their heads around a non-Java syntax for OOP.

All that said, Objective-C survives only because Apple hasn't chosen another
language to replace it for Mac and iOS programming.

~~~
schrototo
> Obj-C went with Smalltalk syntax, while the rest of the world went with C++
> syntax and ultimately the Java style syntax we know and love today.

It's more than just a syntactic difference. Objective-C implements true
_message passing_ which is not the same as "method calling". You can send
messages to a nil object, or have an object dynamically respond at runtime to
a message it didn't declare at compile time etc.

Some seem to think the brackets are just some kind of whimsy, but it's
important that sending a message is not to be confused with calling a
function.

------
mirkules
Why it survives in a world of alternatives? There are no alternatives if you
want to distribute on the most popular mobile platform. Personally, I _really_
dislike Obj-C, but since I want to create apps on the iPhone I have no choice.
Unfortunately, making a good business decision sometimes means going against
your personal feelings. I think that's how a lot of other people approached it
too. If the iOS platform changed overnight to Lisp, we would see articles
titled "Why Lisp survives in a world of alternatives"

~~~
cppsnob
> There are no alternatives if you want to distribute on the most popular
> mobile platform.

Symbian, Blackberry and Android don't support Objective-C as far as I know.
Only iOS does, which is far from the "most popular" mobile platform,
especially if you look outside Silicon Valley just for a minute.

[Edit] Also, for the record, you can program in C++ and distribute on iOS with
minimal Objective C. I thought I'd point this out given my login name.

~~~
sigzero
I think you both are arguing from different sides of "popular". You are
stating popular by sheer numbers while he was stating it from a 3rd party
developer prospective. I believe he was right in what he said.

------
allenbrunson
I've been using objective-c since 2001, when I made the switch from BeOS to
Mac OS X. It's not horrible. I don't have any real problems with it. But I
think its replacement is long overdue.

Given that Apple has a long history of ditching huge swaths of its technology
in favor of more modern alternatives, no matter if their userbase screams
bloody murder or not, I'm surprised it hasn't happened already. This would be
a good project for those billions they've got sitting in the bank.

I think it would be great if they would anoint some successor as their new
systems language, then port Cocoa to it. Programmers could use either
objective-c or the new systems language for a few years, just as we used to
decide between Cocoa and Carbon. Then objective-c could gradually fade into
the past.

~~~
cubicle67
that's fine, but what would they replace it _with_?

Java? C#? not likely. C/C++? well, you can use them already

I think MacRuby is the closest we have atm to something being groomed as a
successor to Obj-C. It's got a way to go yet, but it's already at the stage
where it's viable for smaller projects and there's a (small) number of MacRuby
apps available on the OSX app store.

~~~
noarchy
Any idea how much investment is taking place in MacRuby? If they're really
interested in grooming a successor, I'd figure that there would be some
serious work going on, behind the scenes.

With the success of the platforms on which Obj-C is used, I don't know if a
successor will be another language. An update to Obj-C itself might make
perfect sense.

~~~
danieldk
Well apparently, MacRuby is already a private framework in Lion, so it serves
some purpose in the eyes of Apple.

[http://merbist.com/2011/03/07/hey-apple-please-be-nice-
and-s...](http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-share/)

------
Argorak
meta tl;dr:

The blog post talks about interesting runtime properties of the
Objective-C/Cocoa runtime that differentiate it from C and C++/Java.

Hacker News mostly rants about the Smalltalk-like syntax.

------
jshen
I wish Objective-C were more popular on linux, I like the way I can mix
message passing style OO with C code.

~~~
rchowe
There aren't really any good libraries for it. You can compile straight ObjC
on linux fairly easily with gcc or clang (use -lobjc), but the thing is
without NSString and all of the foundation you'll end up doing a lot of work.

And yes, you can get into GNUStep, but that's a whole nother ballgame.

------
njharman
> Objective-C remains an impediment for many programmers

Really!? If that's such an impediment maybe "many programmers" need to look
for a new career. Or, go back to copy pasting PHP / hiding their schlubness
amongst the other cogs in some Enterprise Java machine.

------
cageface
Obj-C, at least in the last few generations of mobile hardware, is a
competitive advantage for Apple. It makes it easy to write fast, low-level
code in C, and then to move transparently up to a much higher level of
abstraction for non-critical code. With the relatively underpowered processors
of today's mobile devices, this kind of control is important.

However, Obj-C completely falls on its face for anything of real algorithmic
complexity. Working with complex, nested data structures and more
sophisticated algorithms is _very_ awkward, and manual memory management only
clouds things further. In the longer run this may become a liability for
Apple.

~~~
zoul
I fail to see how manual (or, in this context, _explicit_ ) memory management
could “cloud things”. (It seems to me simply like many programmers can’t be
bothered to invest the afternoon it takes to learn Cocoa memory management.)
Also, could you elaborate why Objective-C makes it hard to work with nested
data structures and sophisticated algorithms? In fact, I am struggling to find
an example of at least a single general-purpose language that makes working
with ”sophisticated algorithms” hard.

~~~
cageface
The kinds of algorithms you can express very cleanly in a functional language,
like Haskell, for example, are a lot more awkward when you have to worry about
managing memory at each intermediate step. Look at all the monkeying around
you have to do with __block declarations etc. For typical Obj-C code, where
you're just gluing together bits of the Cocoa API, I agree that Obj-C's memory
management isn't too bad. When you're trying to work at a higher level of
abstraction, it's a distraction.

Writing complex algorithms in Obj-C is a pain because of it's incredibly
clumsy syntax for collections and the manual coercion of elemental types back
and forth to objects. Look at an implementation of a neural net or something
as simple as k-means clustering in Obj-C, then C++, then Scala or Haskell to
see how poor Obj-C is for this kind of thing.

For example, imagine how much worse this would be in Obj-C:
[https://github.com/cageface/brains/blob/scala/src/main/scala...](https://github.com/cageface/brains/blob/scala/src/main/scala/brains/clustering/KMeans.scala)

Admittedly, Scala is particularly nice for this kind of thing, and Java is no
better than Obj-C, but even C++ gives you much better tools for abstracting
this kind of code.

~~~
zoul
Thank you, that’s helpful.

The algorithm is a bit above my head to rewrite in Objective-C on Sunday, but
from my superficial understanding of it the Objective-C version wouldn’t be
really ugly. Yes, it would be wordier and clumsier, but tolerably so (for me).
After all, it’s precisely these things where functional languages shine.

I seldom find I have to monkey around with __block. Manual boxing/unboxing
sucks, yes. It can be alleviated by a simple macro where this really matters,
but I can see such and argument is like pouring petrol into the fire when
compared to functional languages :)

Now I understand what was meant by “sophisticated algorithms”. Yes,
Objective-C is not perfect for those – first class collections are a great
convenience here. But I certainly do not see that as a future “liability for
Apple” or a huge drawback for the language ecosystem. It’s a niche.

~~~
Dn_Ab
Its a niche for now. But local intelligence in mobile software is going to
matter more and more as ad hoc and sensor networks become more common -
otherwise the explosion of data might as well not have happened.

~~~
cageface
And this is just one domain in which Obj-C falls short. For another example,
compare doing linear algebra for graphics in Obj-C vs C++ with a nice matrix
library.

------
killerswan
With early iOS they were talking about a pretty serious use of JavaScript. I
wouldn't be surprised if they pushed that more in the future...

I've heard there is a lot of work being done to make Haskell play nicely with
Xcode [1]. I don't know if Apple is experimenting with that, but they're
probably kicking a lot of options around.

[1] <http://hackage.haskell.org/platform/mac.html>

~~~
pohl
Did you paste the link you intended to? I don't see how it supports the idea
that there is work being done to make Haskell place nicely with XCode.

~~~
killerswan
Work being done by Haskell people, if not Apple people.

~~~
pohl
I'm not even getting that from the link. To me, the link only shows that I can
download The Haskell Platform for my Mac.

The only thing there related to XCode is that one needs to have it installed
as a prerequisite for running the haskell platform's installer.

This is no surprise because the installer wants to have the "unix development
support" package available (it contains gcc, header files, misc command line
tools in locations where run-of-the-mill Makefiles can find them...) and it's
just incidental that one needs to run the XCode installer in order to get
these basic unix amenities on the system.

------
zmitri
After starting to read a bunch of objective C, I have to say there are some
constructs that are very nice compared to an OO language like java -- for
example, selectors and the target action design pattern. There's definitely
some nice dynamic properties, but at the same time, some of the basic
"methods/messages" for the Foundation APIs aren't very convenient to write and
are strangely named. For example, compare NSString to strings in Java, Python,
Ruby, etc.

------
stcredzero
_This makes the following situations possible:

1) You want to add a convenience method to someone else's object (a quick
search of my own posts reveals that about a dozens of my own posts involve
adding convenience methods to Cocoa classes, e.g. Safely fetching an
NSManagedObject by URI).

2) You want to change the behavior of a class you didn't (and can't) allocate
because it is created by someone else (this is how Key-Value Observing is
implemented in Cocoa).

3) You want to treat objects generically and handle potential differences with
runtime introspection.

4) You want to substitute an object of a completely different class to the
expected class (this is used in Cocoa by NSProxy to turn a regular object into
a distributed object)._

One can do all of the above with the Go language. In addition, one could also
write a reasonably performant compiler in it. (Also JIT dynamic language VMs
are good enough now, that I've seen dynamic language parser/compiler
implementations perform as well as a naively written Lex/YACC C
implementation. And yes, companies paid money for the latter!)

------
veyron
Has anyone used pyobjc or some other interface between objective-C and another
language? Thoughts?

~~~
orangecat
I used PyObjC a few years ago, and enjoyed it much more than straight
Objective-C. Far less boilerplate, and the transparent mapping between Python
lists and dicts and Cocoa's NSArray and NSDictionary is great.

------
ignifero
The title of the post is very misleading: Obj-C would crash and burn if there
were native, supported alternatives in OSX, it survives exactly because there
are no alternatives.

~~~
ryannielsen
Ok, that's simply not true. On Mac OS X, you're welcome to use any language
and runtime you wish for your application. Hell, if you want to use a non-
Objective-C language and still present a native experience, use PyObjC,
RubyCocoa, MacRuby, or any other language that shims into the Objective-C
runtime and get access to all of Apple's Cocoa frameworks in the language of
your choice.

The same is possible on iOS as well, with the (significant) condition that
Apple must first explicitly approve your use of a non-Objective-C runtime
before your app can be posted to the App Store.

But in direct response to your post, Obj-C has a rather level playing field on
OS X and still survives vs. the alternatives.

~~~
blub
Welcome to use it, except:

* it's not officially supported by Apple

* it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs)

* you can't use it on iOS

* you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language

~~~
ryannielsen
> * it's not officially supported by Apple

MacRuby is an Apple project.

PyObjC isn't, but ships in Mac OS X. That's rather officially supported.

> * it binds to Cocoa (and if you're lucky it's even up to date and doesn't
> have that many bugs)

Not true. MacRuby is a prime example of a language that taps directly into the
Objective-C runtime, eliminating the need for a bridge. And PyObjC is a great
example of a mature bridge – it's been around and robust since the NeXT era.

> * you can't use it on iOS

[http://mobileorchard.com/announcing-iphone-wax-native-
uikit-...](http://mobileorchard.com/announcing-iphone-wax-native-uikit-iphone-
apps-written-in-lua/)

> * you can't get a job doing X instead of Obj-C because almost everyone just
> uses Obj-C, the Apple supported language

You can't get jobs programming Ruby, Python, C#, Lua or any other language?

------
ignifero
Let's face it: in 2011, Obj-C has the sex appeal of COBOL.

I think it's primarily a strategic decision: Just like apple likes to lock-in
its customers with itunes, so it does with developers, locking them behind an
unpopular language with a slow learning curve.

~~~
bonch
Ignoring the disputable claims that it's unpopular or has a slow learning
curve (you can describe Objective-C's additions to C in a single page),
there's no evidence to claim that Objective-C is about customer lock-in,
especially when you can use so many alternatives including the Apple-funded
MacRuby.

Apple uses Objective-C because they have a lot of code written in it, and it
has served them very well. iOS is the most popular mobile platform for third-
party development. The dynamic nature of the language has enabled the
implementation of some useful features like key-value-observing, while the
ability to drop to C retains the flexibility of system-level programming.

Even the memory management criticism is overblown. You merely have to follow
an easy list of four ownership rules. That's if you're not using the garbage
collector that came out four years ago with Leopard.

~~~
nupark2
If you follow those "easy rules," how do you handle race conditions between
weak references held to avoid retain cycles and the execution of those weak
reference's -dealloc methods? There's nothing to stop the weak reference's
-dealloc from racing with messages to that weak reference.

Or, how do you handle the fact that -dealloc can be called on whatever thread
calls the last -release, even if you make an effort to only send messages to
an object on the main thread (Which will trigger implicit retain/release
unless you're incredibly careful). Almost all of the GCD examples out there
are subtly broken because of this.

As for GC, I look forward to actually being able to use it on iOS.

~~~
xsmasher
I can't address your first point because I haven't used GC yet, but your
second seems like a contradiction. If you're releasing from a background
thread then you are sending messages from a background thread. You can easily
put code in our object's release method to fix that, though. "If not main
thread, call self on main thread."

~~~
nupark2
This is a hack, not a general purpose solution, as it requires modifying the
class, and and still must be done carefully to avoid accidental
retain/release.

Calling retain/release from a background thread will happen simply by using
blocks, gcd, or performSelector: APIs, as designed, to attempt to schedule
execution on the main thread. Avoiding the issue requires exquisite care,
unless you actually want to modify every single class that you may access an
instance of from a background thread (such as GCD).

As to the first point, it applies in a NON-GC environment, where you hold weak
references to delegates a(nd deregister them in dealloc.)

~~~
xsmasher
Sorry, the term "weak reference" threw me. So you mean you have pointers to
objects you have not retained, and you "deregister" (set them to nil?) in your
dealloc? I don't see how that can trigger a race condition or call anyone
else's dealloc.

You may have a valid point but I don't grasp it.

~~~
nupark2
Think delegates, or observers. There is a race condition between calling the
delegate and deregistration of the delegate. Once an object's dealloc method
has been called, you must not resurrect it, but there is a race between the
execution of -dealloc, the de-registration of the delegate, and the dispatch
of messages to the delegate.

~~~
xsmasher
So you're setting threadedObject.delegate = nil in your delegate object's
dealloc, but the threadedObject is sending subsequent messages to your
delegate? The doesn't sounds like a retain-release problem. Wouldn't the same
thing happen when setting threadedObject.delegate=foo? Messages could still
get send to the old delegate if you haven't done your synchronization right.

~~~
nupark2
Missing the forest for the trees. The problem is that the old delegate will be
invalidated before it deregisters itself, because it will not deregister
itself _until_ it is invalid (during -dealloc)

