
A Eulogy for Objective-C - AlexeyBrin
https://realm.io/news/altconf-aaron-hillegass-eulogy-for-objective-c/
======
noobthenoon
I really miss the dynamic features of objective c in swift. Writing a JSON
mapper or serializer is really simple if you learn the run time.

You can't do that in swift.

Objective C was a compromised version of small talk. And swift is a
compromised version of a true modern language.

I'd much prefer a non compromised small talk.It's better for medium size
mobile apps.

And until the rest of the libraries are in swift it doesn't feel very
different.

It's like you're writing Python but you're forced to use Java libraries and
Java style apis.

I hope apple doesn't ram it down our throats. Well their own frameworks depend
on its dynamism and In many ways in my limited opinion objective c is better
for developer happiness.

~~~
fleitz
Yup, ObjC is light and scripty. Whenever you don't like what it's doing you
just make it do what you want, categories, cast to id, swizzling, respondsTo,
NSSelectorFromString, etc, and when it's too slow you write those functions in
C/C++ which it integrates well with.

Swift you're always contorting yourself to express things in a way that the
language wants, it reminds me of writing java, it worships far to heavily at
the altar of type safety as if type safety was a goal in and of itself.

ObjC is practical, Swift is academic.

~~~
Alphasite_
That seems the opposite, very few things need those dynamic features and those
that do can be special cased, which makes Objc the more pure but equally more
academic language to me.

~~~
TheOtherHobbes
It's the difference between a language that trusts you not to be a fool, and a
language that assumes no one should ever be allowed to use dynamic runtime
features.

I've enjoyed my time with Objective-C very much. For consumer coding, I think
it's very close to the safety/expressiveness sweet spot.

~~~
themartorana
Agreed. When I first started out I never could have guessed it would become my
favorite language. Apple did a lot of great things during my tenure writing
ObjC - GCD and ARC are probably the best. I couldn't believe how easy it was
to write performant code, both for powerful desktops and power-starved mobile
devices.

It was the first place (pre-ARC) that I learned to manage my own memory, and
the first (pre-GCD) that I learned to be as safe as possible in a multi-
threaded environment.

If in fact Swift is the death-knell of Objective-C, I will be sad. I've
written C and C++ and Python and Go and Scheme and Lisp and on and on (Java,
C#...) and it will remain one of my favorites for years to come.

------
chc
For anyone who isn't familiar, Aaron is one of the most venerable Objective-C
programmers out there. He worked at NeXT in the '90s and has been teaching new
Objective-C programmers since OS X was released.

------
waynecochran
Can I blissfully go on writing OS X and iOS apps in Objective-C (I spent 15+
years training brain cells in Obj-C)? Aaron H. seems to suggest I can -- Apple
isn't just pong to deprecate the entire language one morning in early June I
hope. I have learned just enough Swift to read it, but not ready to invest the
time to learn it well.

~~~
glhaynes
You're definitely safe writing your own apps in it for well into the
foreseeable future — there's not only way too much app code out there for it
to be deprecated soon, but the vast majority of the system and bundled apps
are in Objective-C.

I'd expect Objective-C jobs, though, to decline in number over time as Swift
jobs rise. If you're doing it professionally, not learning Swift is going to
increasingly limit your options, perhaps pretty rapidly — a few months ago, I
got turned down for a job in part because of lack of Swift experience. Ended
up landing a different job where we're writing a Swift app and step 1 for
everyone on the team was "learn Swift".

~~~
Spivak
However, as those Objective-C jobs decline their pay-scale will probably
increase as companies desperately attempt to find someone to maintain their
legacy apps.

~~~
tempodox
Not too improbable. I can still remember hand-wringing search quests for COBOL
programmers.

------
tempodox
ObjC is far from dead for me. And it will take Swift a long time (if ever) to
deliver what ObjC can do.

Swift is not completely bad per se, but it's far from being as approachable as
C. In C, you only need to read all the header files, then you “know
everything”. In Swift, there aren't even any files with declarations you
_could_ read. But then, a completely obscure language seems like a perfect fit
for a walled garden.

------
jasode
FYI for those who prefer to watch videos at faster speeds.

Instead of realm.io, I went to the youtube url instead:

[https://www.youtube.com/watch?v=2s7UR-
rNFss](https://www.youtube.com/watch?v=2s7UR-rNFss)

The notes say: _" THIS VIDEO IS NOT MEANT TO BE WATCHED ON ITS OWN. We went to
great pains to synchronize it with the speaker’s slides,"_

Well, the embedded youtube at realm.io only allows speed of 1.5x.

The direct youtube url has the speed option for 2x, so I watched it there.
However, before I saw it, I spent a few seconds to flip through the slides to
get an idea of what Aaron was speaking to.

~~~
morqon
It's pretty nice though, having the slides synchronised to the video. And on
realm.io, below the video, there's a transcript with linked resources :)

~~~
jasode
The text below was simply _excerpts_ instead of the full transcript. The
incomplete excerpts looked like snippets of context to guide people to the
middle parts of the video. You actually had to watch/listen to the video to
get the full text.

For example, at the beginning, he says the word "tricycle" and when I searched
for that word, it wasn't in the text below. That's when I knew it wasn't a
full transcript.

~~~
timanglade
True. We edit the transcript on purpose to make it more useful to people who
want to read it instead of watching the video. If you're looking for a full
word-for-word transcript, we have that through the subtitles available in the
video. We iterated towards this model after a lot of trial & error but we're
still looking for feedback on what people would prefer to see!

------
tolmasky
The developments that Facebook is working on with React Native are just so
much more exciting than another riff on C++. For most "utility" apps, I just
don't think performance is such an issue that the point of research should be
these (comparably) incredibly low level concerns.

When I see the bugs going on in iOS apps, it has to do with models that are
broken for what modern programs looks like today: things like asynchronicity.
Animation is still a mess to wrap your mind around when you have a series of
asynchronous events (animations, loads, what have you) that are tied together,
but can also be canceled half way through. This is why I can still break many
apps by just tapping all over the place (or clicking all over the place:
[http://tolmasky.com/letmeshowyou/Yosemite/Safari%20Animation...](http://tolmasky.com/letmeshowyou/Yosemite/Safari%20Animation.mov)
).

Combining the determinism of React style immediate mode drawing with JS
async/await is truly exciting for app development.

Now, of course the elephant in the room is that neither of these matter that
much when most the apps being written are games that will continue using C++
or Unity (if you _actually_ care about speed these are your best bet).
Especially with the work Apple is doing with Metal that will improve these
platforms as well.

~~~
kybernetyk
>I just don't think performance is such an issue that the point of research
should be these (comparably) incredibly low level concerns.

Yes. Performance maybe not. But power efficiency is. If your mobile app is
bloated and takes more resources than needed to perform its task then you're
wasting the user's battery.

------
aidenn0
Objective C: All the blazing speed of Smalltalk with the memory safety of C.

------
omarforgotpwd
I learned Objective-C from Aaron Hillegass's book many years ago. Pretty funny
to hear from someone who still loves the language.

------
masters3d
No language is perfect. If a language is not grounded to solve concrete
problems, then we just end up with a new c++.

"Swift is not the ultimate language, it’s not flawless, it is compromised
because of Objective-C interoperability."

------
fleitz
Read the eulogy when the base libraries are Swift...

When swift code that interacts with the base libraries is faster, and when
swift code compiles faster.

Swift so far is a language that over promises and under delivers...

~~~
saurik
Yeah... I'm pretty certain the only code in iOS 9 that is written in Swift is
the Calculator app, which was also the first app I remember Apple shipping
that actually used their public version of UIKit; until iOS 4, when Apple
dogfooding their library finally made UIKit "good", Apple was still using the
as-yet-much-better private UIKit they had written for iOS 1 that shared very
little... it even had its own UIScrollView called UIScroller and its own
UITableView called UITable. While I'm sure the language keeps getting better
as people provide feedback, the product isn't going to move past that "omg
this is amazing" threshold until Apple dogfoods it, and until then Apple is
just using everyone as guinea pigs ;P.

FWIW, I think Apple _can 't_ ship any base libraries that uses Swift until
they finish ABI-compatibility, as they need to be working off the same base
Swift runtime as the apps that would run against those libraries. Given that
for the last year people have been shipping apps that link against an old-and-
incompatible Swift runtime that Xcode bundles into your app, and given how the
runtime is "intrusive" (putting stuff into the global Objective-C namespace,
for example), it isn't even clear yet (so this may require more time on their
end to build out more infrastructure) how they will be able to pull that off
without saying "all Swift apps developed before now need to be reshipped or
they will stop working on iOS 10".

~~~
artmageddon
Oh goodness. Having written some small apps in both Objective-C and Swift, I'm
not even sure which language I should jump back into when I want to pick it up
again.

~~~
kenrikm
Objective C, it has a more clear path at the moment.

~~~
gress
What does that even mean?

~~~
kenrikm
Objective C has been around since the 1980s, it has a long history with NeXT
and Apple thus is very mature. Code you write in Objective C now can
reasonably be expected to stay very similar going forward. Swift however is
still very much in the wind where you run into "well this language feature has
not been implemented yet" and with each version that is released your code
needs to be migrated or changed to accommodate the changes in the language.
The path forward is clear with Objective C vs Swift where you just don't know
if some of the issues will even be addressed. I've been writing Objective C
since 2007 and Swift since shortly after it was released. Swift still has a
long way to go before I would use it as the starting language for a new app
that I expected to have users / maintain.

~~~
gress
Swift is moving fast as you say, and is clearly receiving Apple's favor and
attention. Any app that you start with objective-c today will end up with a
legacy codebase in the next couple of years.

------
johndpope
If I didn't have so much code in objective-c - I'd welcome the passing. Until
then - I've built a project to migrate objective-c code > swift en masse.
check out [http://objc2swift.io](http://objc2swift.io) for hockeyapp download.

------
kerusan
Awsome speach! When Apple dumped Objective-C in WebObject we at OOPS printed a
TShirt that we showed the crouds at WWDC. I can only repeat now what it read.
[objC retain] Kerusan, OOPS, Sweden

------
fithisux
One question. Why IOKit was not written in ObjC?

~~~
adamnemecek
ObjC has a pretty beefy (and therefore somewhat slow) runtime which is an
issue for kernel stuff.

~~~
speeder
Or explaining this better:

The objects of ObjC work very differently than C++ objects.

In Obj-C for example, there are no "methods" like C++, in C++ when you put a
method in a class, (although implementation details may vary) it works like a
function pointer in a C struct, and calling that method is just executing
whatever code that pointer points to.

In Obj-C in contrast, to call a function of a class, you actually pass a
message, that first must be interpreted, then the runtime that interpreted the
message find the correct function definition to use and run.

For most apps people don't care about this, but game developers for example
frequently make iOS and Mac games that in time-critical parts use pure C or
even Obj-C++ so that they can skip this messaging part (that can cause
significant performance problems sometimes).

Example: yesterday I was trying to figure why a open source game I like was
slowing down, I ran a profiler, and the most called function, and the one with
most execution time, was a simple "GetSomeRandomVar()" for spaceships (it is a
spacefight battle game), I looked in the source, and saw that every frame,
every spaceship call this at least once for every other spaceship, if the
spaceship has an AI it calls it many, many times, I inlined it and the code
became much faster.

I am very sure that if it was a ObjC call (with messaging) it would be so slow
that the original author probably would not even have uploaded that to github.
(by the way, the game IS an OSX game, but the original author wisely decided
to go with C++ instead of ObjC)

~~~
chc
I think putting it that way exaggerates the differences a bit. The message
doesn't really have to be "interpreted" in any meaningful way AFAIK. A message
consists of a selector (essentially a method name) and a receiver, then
whatever other arguments the method will take. The runtime looks up the
selector in the receiver's method table, much like with C++ virtual methods,
and then jumps to the implementation it finds. There is a _little_ more
fanciness (some method caching, and support for nil receivers), but I don't
feel like it's hugely dissimilar from virtual methods.

For anyone interested, here's a good analysis of Objective-C's message
dispatch machinery: [http://blog.zhengdong.me/2013/07/18/a-look-under-the-
hood-of...](http://blog.zhengdong.me/2013/07/18/a-look-under-the-hood-of-objc-
msgsend)

~~~
pcwalton
The vtable is a flat structure with known layout in C++. In Objective-C, it's
a hash table (with precomputed hashes and lots of other tricks—but it's still
fundamentally a hash table). There's a big difference between the two.

~~~
chc
There's a big difference between the data structures, yes, but the basic logic
for message sends is still pretty similar. They both boil down to a simple
lookup in a data structure and a jump. Would you really characterize the
difference between a vtable and a hash table as "you actually pass a message,
that first must be interpreted" in the case of a hash table?

~~~
fleitz
I think the biggest issue is that in a vtable you jump directly to the method
by index, and with objc_msgsend it looks up a string in a hash table.

Mostly the difference is ints vs. strings in my opinion.

As well in C++ if you don't mark your method virtual you can bypass all the
vtable crap.

I love ObjC but method resolution is far more expensive than in C++,
especially non-virtual methods.

~~~
astrange
Method selectors in Obj-C don't have to be strings, as long as you can turn a
string into one occasionally.

You do still need to do a hash lookup to get the method implementation, since
the selector table changes at runtime and objects have to safely respond to
unhandled selectors and all that.

~~~
fleitz
I meant string as in char* not NSString, selectors specifically the SEL
datatype are strings

They certainly don't have to be, however, they are.

    
    
        SEL selector = @selector(applicationDidBecomeActive:);
        printf("%s",(char*)(void*)selector);
        // Prints applicationDidBecomeActive:

------
KSS42
Blaine Guest? Typo?

~~~
glitch
Yeah, I noticed that too. I told them and they fixed that typo.

