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:
1 Comment 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.
