
Will Apple ever replace Objective-C with another language on their platforms? - barredo
http://www.quora.com/Will-Apple-ever-replace-Objective-C-with-another-language-on-their-platforms-If-so-what-when-and-why-If-not-why-not?srid=z47
======
frou_dh
John Siracusa has done a couple of articles and a podcast episode on this
subject:

<http://5by5.tv/hypercritical/14>

<http://arstechnica.com/staff/fatbits/2005/09/1372.ars>

[http://arstechnica.com/apple/news/2010/06/copland-2010-revis...](http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars)

The question should clearly be _when_ , as, like the guy on Quora says, "ever"
is a long time.

------
makecheck
Aside from all other issues (sheer volume of APIs to port, people depending on
it, etc.) it's hard to imagine using another language with Cocoa unless it
also chose "theSame:kindOf:calling:convention:".

Objective-C just looks weird when you try to call it like you would a C
function, because arguments are almost always intended to be preceded by
names. So how would old APIs be invoked? They may _work_ , but it'd be a very
awkward transition.

~~~
jcizzle
I'm not sure what you are saying. Sending a message in Objective-C just
compiles down to a C function. Syntax has absolutely zero to do with the
language choice or transition to another language. It sounds like you think
adopting another language means you tack some different syntax on top of
Objective-C and call it a day. This is incorrect.

Furthermore, when I hear a programmer make disparaging remarks about a
language because of its syntax (or really any reason), I immediately know not
to hire this person or trust any of their opinions; an experienced, rockstar
programmer would never even hint at this sort of sentiment.

~~~
makecheck
What disparaging remarks? I'm only stating exactly how Objective-C looks. It
is a syntax I happen to like, too. Not sure how you thought otherwise.

Yes, when calling Objective-C, it compiles to C. But since the article talks
about the idea of moving _away_ from Objective-C, the only thing that matters
is how source code currently is. The millions of Cocoa-dependent projects
aren't using just C functions (even if they're compatible), their API calls
follow Objective-C style. So, it is _those_ calls that need to transition.
It's not impossible, but it would be inelegant to move those API calls to a
language that is significantly different than Objective-C style.

[Just so you know, I've been programming for over 20 years. I have years of
experience with Objective-C on both Mac and iOS and dozens of projects under
my belt, both for companies and open-source. I have used many different
programming languages and know their strengths and styles very well. But
you're right, you would not be hiring me...because I would definitely choose
not to work for you.]

~~~
jcizzle
Every Objective-C class/object is a C structure. Every Objective-C message
send is actually a C function call (objc_msgSend). Every Objective-C method is
actually a C function definition. So, to the contrary, every Cocoa project is
just using C functions, types and using the ObjC runtime.

The point you are trying to make is that porting an ObjC application to
another language would be difficult because of the syntax of the language,
notably, the interspersing of arguments within the method name. My point is
that this has zero relevance to adopting a new application-level API.

An application-level API hooks into OS-level calls (which are not ObjC), which
gets turned into assembly, which gets turned into machine code. The only way
Cocoa applications would no longer run is if the Cocoa library could no longer
bridge the the operating system or if they intentionally did not ship the
Cocoa library. Thus, creating a new application-level API would deprecate
Cocoa, but wouldn't render those applications useless.

Clearly, a company would have to transition to the new language/API. However,
once again, the syntax of ObjC would not make it any more difficult or easy to
make this transition compared to any other language. And this did not stop
Apple 10 years ago, so I don't envision this stopping them again (C Carbon ->
ObjC Cocoa; note that you can still make Carbon calls on Mac OS X).

~~~
makecheck
All kinds of things compile down to assembly. Binary compatibility between two
programs doesn't say anything about how easy it would be to translate their
designs into other languages (which is often a new way of thinking), or
different standard libraries. Many approaches are _possible_ , few are worth
the effort.

If Apple proposed a new language that didn't support message-passing syntax,
and the only way to keep Cocoa dependencies working was with a pile of
objc_msgSend() calls and other low-level wrappers, developers would just laugh
at them. A _single line_ of Objective-C often contains 3 or 4 pairs of square
brackets, and objc_msgSend()-ifying that alone would be a nightmare even in
the short term and even with a code generator.

That's why I said, the new language has to follow the same calling
conventions. Fundamentally, whenever I see "setFoo:x toBar:y withBaz:z", I
should be able to either _leave that alone_ or do _very little_ to that line
of code.

Carbon-to-Cocoa was feasible because Objective-C is a superset of C (plus the
libraries did share some things, like free casting between the CFStringRef and
NSString* types). Not only that, but there's a compiler for Objective-C++. It
was very easy to adopt.

So to follow the Carbon-to-Cocoa model, Apple needs a new language that's a
superset _of Objective-C_. And that's actually something I'd like to see.

