3 ms·

It's pretty clearly not bad, given how many successful languages use it. Java, C#, C++, Kotlin. Windows, macOS, KDE, GNOME. They're all mainstream OO and for go

It's pretty clearly not bad, given how many successful languages use it. Java, C#, C++, Kotlin. Windows, macOS, KDE, GNOME. They're all mainstream OO and for good reasons. Fragile ABI is basically a C++ problem. Java has had a stable OO ABI for 25 years now. The .NET ABI has gone through a few iterations, but is stable now. Of course Microsoft also had COM, which is/was a stable OO ABI accessible to many languages including C++ and was arguably just a subset of the C++ ABI without templates. In the AOT compiled work Swift now has a stable OO ABI (sort of). Rust is interested in getting one. Lack of a stable ABI is not an OO problem but more a problem of languages that are designed to compile ahead of time to native code and use native formats as their primary artifact format. Most features OO has reduce complexity and bugs, that's why people use them. There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon.

pjmlp 6y ago
> Of course Microsoft also had COM, which is/was a stable OO ABI accessible to many languages including C++ and was arguably just a subset of the C++ ABI without templates. Why the past tense, when COM is the main way Windows APIs have been introduced since Windows Vista, as COM took over Longhorn OO ABI ideas? Nowadays we just call it WinRT.
- thu2111 6y ago
  Right, Microsoft don't talk about COM anymore. I haven't kept up much with Windows programming so lost track at some point of what their current-gen tech is and how it works. WinRT isn't just COM is it. It's custom languages, new app metadata formats and stuff. I don't see IUnknown in any modern Windows code samples.
astrange 6y ago
> It's pretty clearly not bad, given how many successful languages use it. Java, C#, C++, Kotlin. Windows, macOS, KDE, GNOME. They're all mainstream OO and for good reasons. C++ is more of a multi paradigm language where the designers (eg Alexandrescu) actually publish books telling you to focus on algorithms and generic programming rather than object trees. KDE/Qt reinvent messaging on top of the default OO, don’t they? There’s something about slots. > There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon. Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented. There were actually several attempts to replace Carbon with more OO APIs, that used heavy implementation inheritance, like Taligent and MacApp and they failed because they were too complicated. Cocoa succeeded by using messaging and composition instead like Alan Kay wanted.
- thu2111 6y ago
  Slots isn't a messaging system in the way Objective-C or Smalltalk define it. Slots are what GTK calls signals, if I recall correctly, and are more often called event handlers. They're ways to register a set of callbacks on a single emission point. Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented. Honestly I don't know of anyone, including the people who defined those APIs, who would call them object oriented. POSIX functions aren't even namespaced and routinely don't even take a struct as the first parameter. Implicit state is everywhere in POSIX, Win32 and I think also Carbon. Cocoa succeeded by using messaging and composition instead like Alan Kay wanted. Cocoa "succeeded" by being the official API of the first non-failed attempt at resurrecting macOS. On Windows, the API that "succeeded" was .NET which is a classical C++ type of OO. In practice, Objective-C caused a lot of problems for Apple. They would have junked it years earlier but Steve Jobs was wedded to it and couldn't understand why anyone wanted anything else. The moment Jobs died Swift was started as a project, and Swift does not have objc_msgSend at its centre, at least not if I understood the Swift ABI correctly. The "messaging" concept caused problems in the following ways: * Performance, despite objc message sending being heavily optimised. * Bizarre semantics that led directly to horrible bugs, like sending a message to null being "valid" but returning junk if the return value was meant to be a struct. * Difficult to optimise due to the dynamic language features, which are nonetheless hardly used (e.g. ability to redefine methods on the fly). The latter problem is shared with languages like Ruby.

pjmlp 6y ago

> Of course Microsoft also had COM, which is/was a stable OO ABI accessible to many languages including C++ and was arguably just a subset of the C++ ABI without templates. Why the past tense, when COM is the main way Windows APIs have been introduced since Windows Vista, as COM took over Longhorn OO ABI ideas? Nowadays we just call it WinRT.

thu2111 6y ago
Right, Microsoft don't talk about COM anymore. I haven't kept up much with Windows programming so lost track at some point of what their current-gen tech is and how it works. WinRT isn't just COM is it. It's custom languages, new app metadata formats and stuff. I don't see IUnknown in any modern Windows code samples.

astrange 6y ago

> It's pretty clearly not bad, given how many successful languages use it. Java, C#, C++, Kotlin. Windows, macOS, KDE, GNOME. They're all mainstream OO and for good reasons. C++ is more of a multi paradigm language where the designers (eg Alexandrescu) actually publish books telling you to focus on algorithms and generic programming rather than object trees. KDE/Qt reinvent messaging on top of the default OO, don’t they? There’s something about slots. > There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon. Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented. There were actually several attempts to replace Carbon with more OO APIs, that used heavy implementation inheritance, like Taligent and MacApp and they failed because they were too complicated. Cocoa succeeded by using messaging and composition instead like Alan Kay wanted.

thu2111 6y ago
Slots isn't a messaging system in the way Objective-C or Smalltalk define it. Slots are what GTK calls signals, if I recall correctly, and are more often called event handlers. They're ways to register a set of callbacks on a single emission point. Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented. Honestly I don't know of anyone, including the people who defined those APIs, who would call them object oriented. POSIX functions aren't even namespaced and routinely don't even take a struct as the first parameter. Implicit state is everywhere in POSIX, Win32 and I think also Carbon. Cocoa succeeded by using messaging and composition instead like Alan Kay wanted. Cocoa "succeeded" by being the official API of the first non-failed attempt at resurrecting macOS. On Windows, the API that "succeeded" was .NET which is a classical C++ type of OO. In practice, Objective-C caused a lot of problems for Apple. They would have junked it years earlier but Steve Jobs was wedded to it and couldn't understand why anyone wanted anything else. The moment Jobs died Swift was started as a project, and Swift does not have objc_msgSend at its centre, at least not if I understood the Swift ABI correctly. The "messaging" concept caused problems in the following ways: * Performance, despite objc message sending being heavily optimised. * Bizarre semantics that led directly to horrible bugs, like sending a message to null being "valid" but returning junk if the return value was meant to be a struct. * Difficult to optimise due to the dynamic language features, which are nonetheless hardly used (e.g. ability to redefine methods on the fly). The latter problem is shared with languages like Ruby.