The Subjective Charms of Objective-C
To argue that Objective-C resembles a metaphysically divine language, or even a good language, is like saying Shakespeare is best appreciated in pig latin. Objective-C is, at best, polarizing. Ridiculed for its unrelenting verbosity and peculiar square brackets, it is used only for building Mac and iPhone apps and would have faded into obscurity in the early 1990s had it not been for an unlikely quirk of history. Nevertheless, in my time working as a software engineer in San Francisco in the early 2010s, I repeatedly found myself at dive bars in SoMa or in the comments of HackerNews defending its most cumbersome design choices.
[…]
I saw how objects and messages take on a sentence-like structure, punctuated by square brackets, like
[self.timer increaseByNumberOfSeconds:60]. These were not curt, Hemingwayesque sentences, but long, floral, Proustian ones, syntactically complex and evoking vivid imagery with function names likescrollViewDidEndDragging:willDecelerate.[…]
But the longer I spent writing Objective-C, the more I felt it hid rather than revealed. Long, sentence-like function names buried the most pertinent information under a fog of dependent clauses. Small features required long-winded pull requests, making it easy for engineers to get distracted during reviews and to miss bugs. Objective-C’s excess words, multiplied across thousands of files and millions of lines of code, made for an exhausting codebase.
I did not find this to be a problem, but neither am I really nostalgic for Objective-C, except when calling lower level C APIs and when recalling the fast compilation and small binaries.
My own experience with Objective-C has been very different. I wonder if that’s because I work as a solo developer, and the architecture of my apps has always been stable?
[…]
To me, Objective-C has always felt expressive and capable, doubly so when I first started using it. After coding in Java for years I felt like I could fly.
Swift is the thing now, and both Acorn and Retrobatch use it for parts. But Swift is a heavy and unsettled language, not to mention extremely slow to compile.
After Swift became popular, I felt kind of guilty still using Objective-C so heavily, but I’m over it. Micro.blog for Mac is all Objective-C. I did two new releases this week.
For real though, it seemed like ObjC and Apple’s frameworks really caught lightning in a bottle. Swift has gains sure, but they’re trades that place different burdens on the developer… ones personally I wouldn’t take. But also, maybe because my brain is very SmallTalk oriented, I am indeed fighting Swifty ways, and not flowing, like I did back with ObjC.
Previously:
8 Comments RSS · Twitter · Mastodon
Obj-C is the Snow Leopard of programming languages: no new features! But just like SL, that's not true, it usually does get an obscure internal feature or change every year.
Obj-C is basically learn-once and use-forever. It doesn't require a yearly upkeep of books and courses to stay relevant. This makes it very practical and discourages churn (an under-appreciated feature of its code bases). This also prevents mental fatigue (whereas Swift is a constant treadmill of FOMO and trends copied from hotter languages).
Critics cite Obj-C being a strict superset of C as a weakness, but they ignore its benefits. C has great tooling. Obj-C you wrote 20 years ago likely still compiles, runs, and builds fast (unlike Swift code). But the best trait of C is that it keeps the Swifties and their broken philosophy OUT. C is the antidote to Swift nanny-state programming. Your Obj-C code won't break every year because a manager far removed from app dev decided to chase a new theoretical boundary of safety (or whatever) and impose it on your code.
The best UI frameworks that exist remain written by and for Obj-C. AppKit and UIKit operate seamlessly with Obj-C, whereas calling them from Swift may result in unnecessary copies/performance issues, impedance mismatches, or impose a variety of dumb keyword and header demands. Meanwhile, with all the marketing in the world, Swift's very own "native" SwiftUI (a Watch-first UI framework) promises to one day scroll a list on M5 Macs without stuttering. Maybe they'll add a new .NSCell modifier or something.
“ But the longer I spent writing Objective-C, the more I felt it hid rather than revealed. Long, sentence-like function names buried the most pertinent information under a fog of dependent clauses.”
What nonsense. What is he talking about
What’s the swift way of:
stringbyreplacingoccurrencesofstring:withString:
And how does the ObjC version hide pertinent information
@Hammer
Just make sure to never check if the old good AppKit and Foundation you are calling from Objective-C is actually still Objective-C or Swift ;)
@galad
It does not matter if the underlying implementation is in Objective-C, C++, C, or Swift.
As long as: it's not slower, does not consume more memory and the API stays the same in Objective-C.
Crazy that Wired actually published this “article.” One of the dumbest things I ever read. Is Josh Schaff bribing websites to trash objc
I too get annoyed by Objective-C's long-winded method calls, but at least it has named parameters. I started learning Swift, but after hearing the experiences of the commentariat for this blog, I've decided to just stick with Objective-C.
There's one other charming thing about Objective-C that I lament is missing with Swift: it was easy to reverse engineer and patch. All of the classes and method names were right there to be read in the binary, and its runtime made it easy swizzle a method, even when injecting into another process. It allowed clever hackers to change existing macOS features or add new ones in. (I did this with my "forceFullDesktopBar" app that brings back the Mission Control behavior of macOS 10.7 - 10.10. This is a tangent, but that was one of the first stupid and regressive UI changes that heralded Apple's decline.)
So far with Swift I haven't found any tool or method for doing the same, though do tell if there's one there.
Objective-C is a superset of C, but nobody got the memo, so now we have Swift. (Those that did get the memo were simply dismissed as far-eyed reactionaries more concerned with theory than practice.)
FWIW I am a C man and I find all these "modern" languages tedious but I accept that Swift was necessary and inevitable. Apple have always been mad enough to control the whole widget, and let's face it, that had to include the programming language. ObjC was an aberration just waiting to be eliminated, almost a freak historical accident.
“ But the longer I spent writing Objective-C, the more I felt it hid rather than revealed. Long, sentence-like function names buried the most pertinent information under a fog of dependent clauses.”
I don't get this at all. I looked at Swift, but its such a bad language, especially from readability (var vs let what). Objective-C is so much more readable and maintainable. I have stuck with it for my own apps, and will continue to do so.
