A love letter to Objective-C

Vala

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

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.

Care to elaborate?

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

What languages have you used?

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.

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.

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.

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.

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?

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

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).

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

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

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

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.

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.

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.

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.

> 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?

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).

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.