[astrange]

Pink eventually collapsed under the weight of bad choices like "using C++" and "inheritance-based OOP". You can more or less tell it was going to fail from this design document; it is just way too long and seems to have like 5 years of work pre-planned.

The Unicode stuff did live on as ICU (https://icu.unicode.org) after being rewritten into Java and then back into C again.

[randomifcpfan]

I don’t think C++ and inheritance based OOP inherently doomed Pink. BeOS was also C++/OOP, and NextStep/macOS’s use of ObjectiveC/OOP is very similar to C++/OOP, since pre-ARC Objective C is similar to C++ with a slightly more dynamic way of making late-bound function calls.

Pink was doomed by inexperienced and optimistic technical leadership, partly caused by the original Pink/Blue split combined with the NeXT brain drain.

[Reason077]

> "I don’t think C++ and inheritance based OOP inherently doomed Pink. BeOS was also C++/OOP, and NextStep/macOS’s use of ObjectiveC/OOP is very similar to C++/OOP"

The use of C++ with inheritance based OOP was a huge technical limitation for BeOS at the time, because C++'s virtual method tables resulted in very brittle ABIs. Just about any changes to the virtual method definitions in a base class (even as simple as adding a new method!) could break code compiled against the old version. BeOS had all sorts of "placeholder for future function" nonsense in their headers to try to work around this, but it was very ugly.

This wasn't an insurmountable problem, because eventually it could have been solved with some sort of C++ aware dynamic linker. But at the very least it would mean an ugly ABI-breaking change at some point requiring all apps to be recompiled.

Objective C was quite different from the start because it's "message send" mechanism shifted virtual call resolution to runtime, making the whole programming environment more dynamic. Crucially, as long as function names don't change, old compiled apps can basically keep working forever.

[astrange]

Objective-C still had the "fragile base class" problem because its classes' ivar offsets were known across library boundaries, so they couldn't be changed, but C++ had (and still has) this for code with vtables as well. It was finally fixed with the x86-64 ABI.

[eschaton]

Taligent had their own compiler and used something similar to what the ObjC 2 ABI uses for ivars for all member variables and functions to eliminate the fragile base class problem. “Using C++” may have been part of their problem, but not for the same reasons as it was for BeOS.

[pjmlp]

In addition to siblings comment COM and OLE are pretty much alive to this day on Windows, being the main way of accessing the platform since Longhorn ideas were ported from .NET into COM in Vista.

WinRT for all its flaws, is basically COM with an additional base interface (IInspectable), .NET type system metadata instead of TLB, and application identify.

Then Android has similar ideas via Android IPC (and Binder).