A love letter to Objective-C

https://thoughtbot.com/blog/a-love-letter-to-objective-c

by ingve • 3 years ago

62 92 3 years ago

It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem]

And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing.

It's all so deeply entrenched - the hardware, abstraction layers, languages, culture - that it's difficult to imagine ever being able to extricate ourselves from this mess.

We need another 'quantum leap' in technology, or some new paradigm...

bsaul2• 3 years ago

i don't like to be overly enthusiastic, but an obvious instrument i see right now that would be capable to refactor 30 million lines are LLM. They might be a good tool to provide superhuman code simplification.

eska• 3 years ago

I don’t think that throwing even more complexity at not only our problems but also our solutions is the lesson from that.

Someone• 3 years ago

It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem]
And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing.

I’m not going to watch an almost two hour long video to check whether it supports that claim or not. Can you elaborate, especially on the “directly” and “insanity” parts?

mpweiher12• 3 years ago

Hmm...Objective-C is exactly the kind of language that helps you prevent 30 million line problems.

Of course it doesn't do this by itself. If you insist on using it like a C++ or a Java, you will get the same 30 million line problem, slightly worse, because Objective-C is not a good C++ or Java. But if you can use it right, as the good folks at NeXT did, then you can work magic (aka. a sufficiently advanced technology).

fractallyte2• 3 years ago

Here's a summary of the video:

Casey Muratori makes the point that we've had phenomenal growth in hardware power, but our software is not correspondingly better. Computers should be much more pleasant to use. We all know what he's talking about: laggy software, crashes, updates, driver issues, etc.

Things are no longer coded from scratch - we pile code on top of code on top of code. Features accumulate, together with complexity - and bugs.

How many lines of code does it take to read a text file, in a web browser? Across the whole stack - browser, website, OS, router - he estimates 56 million LoC.

The OS alone takes 30 million lines of code!

And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions.

But as hardware developed, the manufacturers removed that access, forcing developers to work through abstractions. A SoC is a super powered 1980s home computer, but we can't actually reach that hardware.

And it's up to hardware people to start taking this problem seriously.

And now my comments:

Apple is one of those manufacturers.

This article hit a nerve with me, because I dumped iOS development; because of the complexity and insanity. Swift is a sprawling behemoth of a language now, hugely complex, full of gotchas. In some senses, it has to be - because it's a reflection of the hardware.

I'm not going to elaborate more. Quite simply: you can't program your iDevice, EVER, without going through Apple's prescribed programming language(s), frameworks, libraries, LLVM, and hardware drivers.

That's Apple's fault. Computing should not be like this.

flohofwoe8• 3 years ago

And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions.

That was possible because the hardware was essentially a "game engine API" (e.g. the hardware was designed to be conveniently used directly, and was also designed with game requirements in mind).

Whether that's good or bad is definitely debatable, for instance on the Amiga the need for hardware backward compatibility because of popular games that directly accessed the hardware was definitely stalling the Amiga's progress in the 90's.

I don't disagree with most of your points though. We're definitely in an age of unnecessary software bloat, but I think the answer isn't to go back to accessing hardware directly. A lot can be gained by just applying some common sense when writing code.

PS: Apple or the iPhone definitely isn't at fault though. The mess already started with the PC and Windows (but this mess also gave us increadibly fast hardware progress in the second half of the 90's by allowing hardware to evolve faster because of driver abstraction layers).

Apocryphon3• 3 years ago

Mobile development, let alone iOS, is a substantially small amount of programming. Bizarre to blame Apple specifically, let alone Objective-C. It seems like you would just as easily be unhappy with web development or Android development as you would be with iOS development.

orasis3• 3 years ago

I’ve written a lot of Objective C.

It is by far the worst language I’ve used professionally.

While I don’t love Swift it is still a breath of fresh air compared to ObjC.

buzzert• 3 years ago

Care to elaborate?

Objective-C's simplicity and minimalism is what makes it one of my favorites.

pavlov3• 3 years ago

I like Objective-C too. It's just C with a very good lightweight abstraction layer for modeling GUI apps.

I'm enough of a purist to think Obj-C 2.0 (introduced around 2007 at the same time as iOS) was mostly a mistake. In old Objective-C, it was absolutely clear when you were sending a message. You couldn't mistake a line of C code for an Obj-C message call.

But Obj-C 2.0 lets you use the same syntax for message calls and struct member access, as in:

  foo.view.bounds.size.width

Two of these dots are expensive virtual message calls. The other two are practically free stack pointer offsets. It's not in good C spirit to introduce this kind of confusion about performance impact. (However it's very much in the worst C++ spirit of frivolous overrides.)

And the benefits were mostly meaningless because the old way (which still works) was barely any longer to type, especially with IDE autocomplete:

  [[foo view] bounds].size.width

orasis3• 3 years ago

There is nothing simple or minimalist about C style separate header files with hacked on property synthesizers. The language is an aggregation of hacks.

starbugs2• 3 years ago

What languages have you used?

orasis3• 3 years ago

C, C++, Java, Kotlin, JavaScript, Python, Ruby, Objective C, Swift

flohofwoe8• 3 years ago

What are your complaints specifically? In the beginning I also hated it (mainly because it was on a platform I didn't care much about). But the more I wrote ObjC (mainly in context of Metal) the more I started to appreciate the "minimal elegance" which is the complete opposite of C++ - I don't appreciate the fact that every object access is a dynamic method call though ;) (but that's where C comes in)

Typically I wrap the ObjC code which needs to call into system framework in subsystems which then expose a simplified C API (same with C++ libraries, wrap the C++ shim under a simplified C API), so that most platform- and library-agnostic code is written in plain C.

ObjC never got in the way though, and the nice thing is that (unlike C++) it supports the latest C features.

pjmlp8• 3 years ago

On my case, plenty of @ [] to type.

C++ already supports more C than it should.

waffletower3• 3 years ago

I have written a lot of Objective C. I don't use it much anymore, except to maintain some existing applications. That said, I still believe my time with it was much more ergonomic for my applications than Swift -- particularly its ability to act as a system language -- given it is a strict superset of C. Further, with the introduction of Swift I chose to change career direction, perhaps somewhat literally because of my dislike of the new language. I chose to go deeper into dynamic languages and now use Clojure, and to a much lesser extent, Python, professionally.

waynecochran2• 3 years ago

No mention of smalltalk? Essentially Objective-C was smalltalk message passing bolted onto C. Then you had Objective-C++ which allowed a whole new language rolled in. I still find myself writing MacOS apps in Objective-C/C++ which allows me to use all the fantastic C++ libraries and frameworks that exist. No doubt Swift is a better language that gives you strong typing and functional constructs, but I’ll always have a place in my heart for Objective-C.

pasc1878• 3 years ago

Ruby is also based on Smalltalk. The author is just showing ignorance of where things come from.

mhoad• 3 years ago

Thoughtbot is famously a Ruby shop since their inception, I don’t know that this detail just happened to slip their mind due to ignorance.

halogen64• 3 years ago

Why would they mention smalltalk? The article is framed from the writer's specific experience with both languages, not as a historical deep dive into the progenitors of Objective-C.

Granted these historical details are super interesting, but feels far from the intent of the article.

waynecochran2• 3 years ago

Because that is in essence why Obj-C works the way it does -- e.g., has all the square brackets. Obj-C is the child of smalltalk and C. It wasn't created in a vacuum.

mhd• 3 years ago

The language has respectably reached that level of maturity and support that allows it to just continues on, quietly running in the background.

Didn't Apple tinker with Objective-C a lot during its runtime, or am I just concentrating on the bumps? I remember reading the Cox book ages ago, where you basically had a simple SmallTalk-ish message syntax on top of plain old C. NeXt you got protocols etc.

Over the time of it being heavily used on OS X and especiallly iOS (where a lot of new and fledgling programmers came in), all kinds of stuff was added. Properties, various memory management experiments etc.

Sure, after Swift was introduced, that seemed to have calmed down a bit. But "mature"?

And no, it's not like other languages fare reasonably better, now that most of them are handled like products.

gilgoomesh• 3 years ago

Apple added a lot of sugar to different parts of Objective-C and a few side features – dot syntax, synthesised properties, blocks, etc. They're still adding tweaks like nullability, generics and other Swift-compatibility features. And they were continually changing things like NSString and NSNumber internal representations and allocation patterns to avoid actually allocating.

They really only changed the runtime once – Objective-C 2.0 – which they mostly hid behind the transition to 64-bit. This introduced layout resilience (so they could add fields to objects without breaking compatibility) and tagged pointers (so the reference count could be stored inside the pointer).

pjmlp8• 3 years ago

There have been a couple of more runtime changes, for performance reasons, and better integration with Swift.

seydor2• 3 years ago

Nobody loved objc. Apple forced people to do so. Sometimes people get Stockholm syndrome

Conscat• 3 years ago

Probably nobody has ever gotten Stockholm Syndrome, including the hostages in Stockholm.

pavlov3• 3 years ago

In a Babylon 5 episode (set a few centuries in the future) they call it the Helsinki Syndrome, which I thought was a clever little nod by the writer to remind us how a legend continues to mutate.

__d• 3 years ago

What about those of us who liked it before Apple touched it?

seydor2• 3 years ago

It was a figure of speech. You were a tiny minority

https://www.researchgate.net/figure/Popularity-Trend-of-the-...

mpweiher12• 3 years ago

I bought a NeXT because, among other reasons, it had Objective-C.

pjmlp8• 3 years ago

My graduation thesis was porting a particle engine from Objective-C/OpenGL into C++ on Windows, because NeXT's future was uncertain and my thesis supervisor wanted to get rid of his Cube.

zer0zzz13• 3 years ago

It’s probably easier to use than COM on windows. The other interesting thing about it was that because of the message passing and easily inspectable objc_methname sections in the macho it was probably super easy for those early iPhone app coders to write some early apps before apple even shipped their first AppStore and iPhone OS 2.0 sdk.

pjmlp8• 3 years ago

COM is great as idea.

Unfortunately WinDev is so siloed into their way of thinking that never managed to create productive tooling.

The exceptions being VB 6, .NET Native and C++/CX.

It is somehow tragic that Delphi and C++ Builder are the most long lived toolchains that offer usable productivity with COM, and Microsoft itself is unable to keep productive tooling for COM going.

another2another2• 3 years ago

NeXT loved it, and produced an amazingly ergonomic and productive application development experience on the back of it.

In the early days of NeXT (legend, and youtube videos have it) they wanted to address some of the shortcomings of Mac, and some of the most consistent feedback was that it was so "darned hard" to program the Mac, so Objc (along with IB, etc) was the answer.

pjmlp8• 3 years ago

They actually did.

When OS X was being developed, Apple was unsure about Objective-C potential adoption, so it made Java a tier 1 language, with an Objective-C bridge, just like Swift nowadays.

When it was clear that the Mac OS community, raised in Object Pascal and C++, had no issues with Objective-C, Java Bridge was dropped from OS X, and Apple contributed their JVM implementation to Sun.

tymscar2• 3 years ago

Wow, never heard about this. Do you have more info?

EGreg• 3 years ago

It’s not just objective C but the entire Apple ecosystem that grew up around it is a tangled ball of mess.

bowsamic• 3 years ago

I love both Objective-C and Swift. I prefer the former simply because it feels quite novel and interesting in 2023

zer0zzz13• 3 years ago

Objective-C is probably the worst language I’ve ever encountered (speaking as a compiler guy).

A language where you can’t prove anything is dead, where you can’t make any changes to the runtime to deal with the dynamic semantics is not great.

ObjC did one neat thing by having language level runtime type resolution address the component oriented programming and Abi stability issues present in c++ and later addressed by things like COM. But at the cost of some seriously bad performance characteristics.

mpweiher12• 3 years ago

Yeah, compiler people hate it. Because there's very little for them to do.

The question is whether programming languages exist to make the compiler (people) happy, or to enable programmers to build great software.

I'd argue the latter.

Apple has now accepted the former.

zer0zzz13• 3 years ago

They have done some nice stuff recently with objc_direct. The minute you can annotate away the dynamism it’s much better. Question is what’s the best way to do this? Lots of folks have been investigating analysis of entire apps either at the source level or some ir (maybe mlir some day).

zer0zzz13• 3 years ago

Also my answer to your question is: I think both. If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software. I’d also argue that apple did not do the former in regards to memory safety, rust did.

pavlov3• 3 years ago

That “one neat thing” was absolutely huge for APIs and applications. Much more significant for a platform than any feature of C++ ever, for instance.

The performance wasn’t a real problem because you could always use C types for data on performance-sensitive paths. Nobody does Obj-C message calls to iterate over audio samples.

zer0zzz13• 3 years ago

Yep. I think right now we just have too much objc code written that doesn’t need any of the parts of objc needed for frameworks.

flohofwoe8• 3 years ago

The other thing that ObjC does right is that it builds on top of an unmodified C (unlike C++ which went full in, messed everything up and now needs the C++ standard to change to integrate new C features, which then usually ends up as half-assed and incomplete attempt - see designated initalization). C and ObjC can be improved independently from each other, and combining them "just works" without "harmonization efforts" by language committees.

Also, doesn't the existance of ARC mean that ObjC supports better "static lifetime analysis" than C++? Or is C++ just behind the curve there?

jb19912• 3 years ago

ARC is runtime reference counting. How does that offer static lifetime analysis? C++ also has a form of ARC in the form of shared pointers, the only difference is that in C++ it's opt-in while in ObjC/Swift ARC it's just the way it is.

chunkyguy2• 3 years ago

But as an app developer, I love using Objective-C because it lets me build beautiful things without worrying about making the compiler happy.

grishka• 3 years ago

One terrible thing about ObjC is that it considers it valid to call methods on null pointers. It just does nothing and returns 0/false/nil. This leads to especially frustrating bugs.

atombender• 3 years ago

So much negativity in this thread. I, for one, absolutely loved working with ObjC. I no longer do any macOS programming, but when I did, it was magical.

Is the syntax weird and crazy? No doubt. It is, however, an extremely pragmatic approach. It's completely unique in that it offers a dynamic, very-high-level OO language on top of C, giving you a way to work on both levels. C (or C++) for the performance-sensitive parts and integration with C libraries, and ObjC for the glue that orchestrates the application. ObjC isn't without its faults, and if was starting to show its age, so it makes sense for Apple to develop Swift, though between the two languages, I think ObjC is the more innovative one.

It's a lot like having a scripting language around a C core, though ObjC has stronger static typing. Dynamic dispatch, late binding, and interfaces (protocols) results in a super rich, dynamic ecosystem of objects all interacting with each other, fulfilling the promise of Smalltalk better — in the sense of being the basis for real, mainstream products, including macOS itself — than any implementation of Smalltalk ever did.

Brian_K_White• 3 years ago

Vala

uranusjr• 3 years ago

I rooted so much for Vala when it first came out. Such good idea to bring the same good ideas to GLib. Alas it was not to be, the (irrational IMO) negativity around this approach killed it before it had a chance.

waffletower3• 3 years ago

I like many of the highlights of the article. I found it odd that Objective-C was described in terms of Ruby, rather than the reverse given that Objective-C was initially developed more than a decade earlier than Ruby. I do understand that the author came to the language Objective-C after a long history with Ruby.

lapcat• 3 years ago

It’s really a testament to the Objective-C runtime (and Ruby C extension API) that while much of the original code was written in 2001, an incredible amount of it runs unchanged over 20 years later on modern versions of macOS and Ruby.

This is one of the things I love. Starting in 2014 with the introduction of Swift and continuing to the present, I've heard people claim that every line of Objective-C code you write is technical debt, but the opposite turned out to be true: any Swift code you wrote in the early years is now completely unusable. Apple even removed some Swift version migration tools from Xcode. Meanwhile, old Objective-C code still Just Works™. I continue to write ObjC today, with no regrets.

Another thing I love is that you can import open source C projects with no changes whatsoever.

Compiling is much faster. The debugger actually works (though Apple has been making it worse lately). There are so many practical advantages to Objective-C, even if it's not the most "beautiful" language. Objective-C has always valued pragmatism over idealism, as the marriage between high level object-oriented programming and low-level systems programming.

chunkyguy2• 3 years ago

I don't miss Objective-C because I still use it on daily basis. I also like Swift, I use it daily at work but I don't see the point of using Swift when working on solo projects.

ObjC is fast, fun and I personally feel very productive in it.

A love letter to Objective-C

Related Stories