[redwall_hp]

In the context of the time, C++ didn't exist yet. Objective-C was actually introduced just prior to C++, and both languages were effectively solving the same problem in different ways: C was the dominant language, and both language designers were trying to graft the OOP paradigm onto it.

Objective-C is a thin-layer on top of C, adding Smalltalk-inspired object support. That's pretty much all there is to it. C, with some new syntax for objects. In the context of a world where C is the norm, that's pretty appealing. This is before Java existed, too.

The "NSWhatever" stuff, as far as I'm aware, isn't part of the language. That's all in the frameworks Apple/NEXT developed for Objective-C. (Note that the base object is called Object, not NSObject, and the integer class is Integer.) NSString is probably named that way because Objective-C doesn't include a string class (nor does C, as a string is just an array of bytes until you write a wrapper to get fancy) and NEXT made one. They were just namespacing the NEXTStep classes.

[astrange]

> Note that the base object is called Object, not NSObject, and the integer class is Integer.

Objective-C actually doesn't require a base object (although these days it essentially does), but Object and NSObject are both examples of root objects. IIRC, reference counting is not in Object and was a NeXT invention.

[yawaramin]

I'm curious--what happened to Objective-C in that fight with C++? Why didn't people go for its simplicity?

[pjmlp]

As usual, platform languages win.

C++ was born at Bell Labs and quickly integrated into their workflows as C with Classes started to get adopters.

This raised the interest of the C compiler vendors, so by the early 90's, all major C compiler vendors were bundling a C++ compiler with them.

Additionally, Bjarne got convinced that C++ should follow the same path as C and be managed by ISO, so the C++ARM book was written, which is basically the first non-official standard of the language.

So C++ had ISO, the same birthplace as C and love of C compiler vendors, while Objective-C was initial a work from a small company and later on owned by NeXT.

So, naturally Apple, Microsoft, IBM decided to go with C++, and everyone else followed.

Here is an anecdote for Apple fans, Mac OS was written in Object Pascal + Assembly, when market pressure came adopt C and C++, the MPW was born and eventually a C++ framework that mimic the Object Pascal one (there is a longer story here though, ending with PowerPlant framework).

Copland was based on a C++ framework, and Dylan team eventually lost the internal competition to the C++ team regarding the Newton OS.

Apple was one of the major OS vendors that never cared much about C for OS development, only the NeXT acquisition ended changing it. And even then they weren't sure about C and Objective-C, hence the Java Bridge during the first versions.

[microtherion]

> Apple was one of the major OS vendors that never cared much about C for OS development

It's true that MacOS Classic kept providing Pascal headers for most of its APIs for a long time (I don't recall whether they ever stopped), but internally, they started switching to C by the late 1980s (as an external developer, I could tell by one bug which would never have made it through a Pascal compiler, but was typical for the kind of bugs that wouldn't get caught by a K&R C compiler), and by the late 1990, it was all C and C++, just with Pascal calling conventions for all public facing APIs. In my time at Apple, I never encountered a single line of Pascal code.

[pjmlp]

I bet it was actually C++ with extern "C", which was my point, specially given the MPW and PowerPlant frameworks.

I never knew anyone doing bare bones C on classic Mac.

[microtherion]

There was a lot of extern "C" (and there still is a lot of that), but there also was a lot of extern "Pascal" back then, I seem to recall.

There was a quite a bit of regular C in classic MacOS, though there was also a good deal of C++. You're right that MacApp (Which I think is what you're referring to with "MPW", which was an IDE) and PowerPlant were written in C++, but I'm not talking about the clients of the MacOS APIs, but about the implementations of those APIs.

[pjmlp]

Faire enough, but sure it wasn't C++'s C subset?

[bboreham]

I tried out both Objective C and C++ in 1988, when neither were popular though C++ was more talked about.

What I remember was that with Objective C you needed to track all intermediate values and release them, so you couldn’t write an expression like [[objectA someMessage] anotherMessage] - you had to capture the intermediate in a variable so you could release it at the end.

So this was annoying and I didn’t like Objective C at the time. (25 years later I wrote several iOS apps in it)

C++ let you manage memory and temporary values though constructors and destructors, which was much more appealing, though pre-templates it was quite constrained.

[jfb]

Part of it was licensing. Probably more of it was the personalities involved at e.g. Microsoft or SGI.

[PaulDavisThe1st]

Objective C loses to C++ for performance if you really start exploiting OOP a lot. The fact the you can swizzle methods in ObjC says a lot about the "weight" of the underlying implementation ("it's all messages") compared to C++.

[neverartful]

The fact that you can swizzle methods also says a lot about its power and flexibility. When Steve Jobs was at NeXT, he was quoted numerous times bashing C++ as having 'dead objects' while pointing out that ObjC objects were 'alive'. One seldom needs to make use of swizzling, but when you do need it, it's an awesome capability.

As prabhatjha pointed out in another comment in this thread, swizzling was used to automatically capture networking calls just by adding our framework to your app and initializing it. You could then log into our app's web-based dashboard and see stats about networking calls (counts, latency, errors, etc.). This simple and elegant solution would not have been possible with C++. We also supported Android at the time (Java), and the developer was required to change his code to call our networking wrapper calls to get the same tracking for their Android apps.

[PaulDavisThe1st]

Absolutely. I've used swizzling myself to fix issues with audio plugin's GUIs (to limit how fast they are allowed to redraw themselves). It's very clever and sometimes very useful.

But the ability to do that comes with certain costs, and performance is one of them. The fact that these "methods" are dynamically dispatched sometimes matters, and you can't change that any more than you can swizzle in C++.

[PaulDavisThe1st]

> This simple and elegant solution would not have been possible with C++

Actually, it would, but not via any feature of the language. You can use features of the linker to accomplish this (particularly LD_PRELOAD). It's not the same thing, really, but it felt worth mentioning for the record.

[neverartful]

In our case, the LD_PRELOAD approach would not have worked because this was on iOS devices where you can't set that variable. However, I do appreciate you mentioning it because it too is a powerful mechanism that enables some creative and non-invasive solutions in some cases.

[pjmlp]

Here is how to do it in Windows.

https://www.microsoft.com/en-us/research/project/detours/

https://github.com/microsoft/Detours