I find it sad that this paper mentions two valid critiques of OOP[0][1], yet makes no effort to engage with their specific criticisms. Also, citing Microsoft's COM object system as _the_ example of OOP's great success must mean that the authors are simply ignorant to how bad COM is and why Microsft has ceased anything beyond legacy support for it.
Ultimately, I find the thesis of the paper fundamentally wrong for presuming that OOP is somehow more beneficial than other approaches to dynamic dispatch. Moreover, the use of interfaces in thr paper are more restrictive to code structure, and in turn, are more likely hurt code reuse than help it.
Interfaces are an inherently weaker form of the age old Operation Code and data packet paradigm. Take the Widget interface the paper gives as an example (page 5). This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change. This is because all code using the old interface will have to be updated and recompiled to satisfy the new interface requirements (even if a widget won't functionally change from using said new interface). Meanwhile for code using op codes, a new op code value is defined and nothing in the old code is required to change. (This assumes that this old code will perform a no operation for the new opcode, which historically has been the case for systems that use this method).
In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success. They have regularly extended their existing code without breaking backwards compatibility of older versions. The longevity of code in typical OO systems pales in comparison.
I find it sad that this paper mentions two valid critiques of OOP[0][1], yet makes no effort to engage with their specific criticisms. Also, citing Microsoft's COM object system as _the_ example of OOP
> why Microsft has ceased anything beyond legacy support for it
That is not true at all. DirextX is COM, UWP was COM based, WinRT is still COM, WinUI and the Windows App SDK is again based on COM. C++, C#, Python and Rust are all supported programming languages for the Windows App SDK thanks to - you guessed it: COM. The C++, C# and Rust language projections for it are still being constantly updated: https://github.com/microsoft/xlang
When they started Project Reunion (code name for Windows APP SDK) back in 2021, just before Windows 11's release, they decided to double-down on COM. Like hard.
> Practically speaking, any language & runtime that can handle COM objects can support Windows App SDK
miffy900
That is not true at all. DirextX is COM, UWP was COM based, WinRT is still COM, WinUI and the Windows App SDK is again based on COM. C++, C#, Python and Rust are all supported programming languages fo
> Interfaces are an inherently weaker form of the age old Operation Code and data packet paradigm.
Only if the language in question doesn't allow something like `interface MyNewInterface extends MyOldInterface { ... }`.
I'm not too clued up on state-of-the-art for OO languages, but my understanding is that this is a practical approach in the mainstream languages that support OO.
For your [0] link, I'm familiar with those arguments, but I believe that this is very subjective. For example, in a modern context, I'd probably use interfaces, which makes all those arguments, except for the state argument, moot.
For the [1] link, I've not read that before but it is a very long interview and I am in disagreement with the general thrust that the argument is "generic programming" vs "OO patterns". If all the facts were forced into that argument, then sure, there might be a point to the criticism, but the fact is that it is possible and simple to use both at the same time.
IOW, they are not in competition with each other, so presenting one as superior to the other is pointless.
lelanthran
Only if the language in question doesn't allow something like `interface MyNewInterface extends MyOldInterface { ... }`.
I'm not too clued up on state-of-the-art for OO languages, but my understanding
> This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change
This is the expression problem[1]. There is an inherent tension between simplicity of extending the number of operations and simplicity of extending the number of types acted on.
This is the expression problem[1]. There is an inherent tension between simplicity of extending the number of operations and simplicity of extending the number of types acted on.
[1] https://en.wikip
This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change.
The idiomatic way to deal with this is to add a new interface with the extensions. This not only prevents old code from breaking but also gives you compile-time assurance that your clients and objects know how to communicate with each other.
kitd
This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change.
The idiomatic way to deal with this is to add a new
>> This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change.
> The idiomatic way to deal with this is to add a new interface with the extensions.
I also found that particular criticism weird in the GP, considering that the paper itself, with the widget example cited by the GP, performs the `extend` on an interface to add to existing interfaces without breaking existing code.
IOW, it uses the widget example, quoted by GP, to demonstrate how to add to an interface without breaking changes.
lelanthran
I also found that particular criticism weird in the GP, considering that the paper itself, with the widget example cited by the GP, performs the `extend` on an interface to add to existing interfaces
You can take a look at this discussion[0] where Casey Muratori designed something like that where communication is done by opcodes, and packets instead of vtables.
Note: search for "raw_device_operation" if you want to get to the code, but reading the whole thing is very worth it.
[0] https://github.com/cmuratori/misc/blob/main/cleancodeqa-2.md
tacitcoder
You can take a look at this discussion[0] where Casey Muratori designed something like that where communication is done by opcodes, and packets instead of vtables.
Note: search for "raw_device_operatio
While I also don't know what this "packets and opcodes" thing is, it certainly sounds a lot like, for example, Smalltalk-72. And vtables are certainly not a requirement, more of an anti-pattern for object-orientedness.
mpweiher
Hmm...what's your definition of "object oriented"?
I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind
-- Alan Kay, OOPSLA '97
https://www.youtube.com/watch?v=oKg1hTOQXoY
"So, the important thing here is that I have many of the same feelings about Smalltalk
…
Part of the message of OOP was, that as complexity starts becoming more and more important, architecture's always going to dominate material.
…
I have apologized profusely over the past 20 years for making up the term object-oriented because as soon as it started to be misapplied I realized I should have used a much more process-oriented term for it.
…
If you had to pick one cause of both particular difficulty in our field, and also general difficulty in the human race, it's taking single points of view and committing to them like they're religions. This happened with Smalltalk."
igouy
and the very next sentence Alan Kay said was:
"So, the important thing here is that I have many of the same feelings about Smalltalk
…
Part of the message of OOP was, that as complexity starts becoming
Which is why I question the "OO means it has a vtable" stance that seemed the promulgated here. While "packets and opcodes" is a bit non-specific, it does not appear to be incompatible with OO, and, for example, Smalltalk-72 seems very similar to "packets and opcodes"...though, again, it's not really specific enough to say with any certainty.
mpweiher
Yes, I tend to quote that second part as well. In fact, I keep that link ready as well:
https://www.youtube.com/watch?t=653&v=oKg1hTOQXoY
Which is why I question the "OO means it has a vtable" sta
“In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success”
Win32 is not exactly easy to work with though.
rqtwteye
“In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success”
Win32 is not exactly easy to work with though.
Today we have no interoperability compared to 20 years ago (that existed in Windows or Macos applications).
Most applications people use are on the web or mobile today. Every application on the web or mobile (Figma, Notion, ...) is basically a silo or one way street.
KingOfCoders
Today we have no interoperability compared to 20 years ago (that existed in Windows or Macos applications).
Most applications people use are on the web or mobile today. Every application on the web or
> 3). Alternative mechanisms can provide interoperable extension only by using service abstraction themselves—and thus are equivalent to what we consider the essence of objects.
Since virtually any language can delegate behaviour this way, the above claim is really saying that every language carries the essence of objects. (And I agree - for this definition of objects).
So the follow-up question becomes "What's so special about about languages which brand themselves as OOP - as opposed to another paradigm?"
mrkeen
Since virtually any language can delegate behaviour this way, the above claim is really saying that every language carries the essence of objects. (And I agree - for this definition of objects).
So t
Objects are whatever dangles at the interior other end of interfaces. And interfaces are just plugs. Plugs can have sub plugs, etc.. If you explain object orientation with its realworld engineering equivalent it becomes much more obvious.
Log_out_
Objects are whatever dangles at the interior other end of interfaces. And interfaces are just plugs. Plugs can have sub plugs, etc.. If you explain object orientation with its realworld engineering eq
I find it sad that this paper mentions two valid critiques of OOP[0][1], yet makes no effort to engage with their specific criticisms. Also, citing Microsoft's COM object system as _the_ example of OOP's great success must mean that the authors are simply ignorant to how bad COM is and why Microsft has ceased anything beyond legacy support for it.
Ultimately, I find the thesis of the paper fundamentally wrong for presuming that OOP is somehow more beneficial than other approaches to dynamic dispatch. Moreover, the use of interfaces in thr paper are more restrictive to code structure, and in turn, are more likely hurt code reuse than help it.
Interfaces are an inherently weaker form of the age old Operation Code and data packet paradigm. Take the Widget interface the paper gives as an example (page 5). This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change. This is because all code using the old interface will have to be updated and recompiled to satisfy the new interface requirements (even if a widget won't functionally change from using said new interface). Meanwhile for code using op codes, a new op code value is defined and nothing in the old code is required to change. (This assumes that this old code will perform a no operation for the new opcode, which historically has been the case for systems that use this method).
In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success. They have regularly extended their existing code without breaking backwards compatibility of older versions. The longevity of code in typical OO systems pales in comparison.
[0] https://harmful.cat-v.org/software/OO_programming/why_oo_suc... [1] http://stlport.org/resources/StepanovUSA.html
> why Microsft has ceased anything beyond legacy support for it
That is not true at all. DirextX is COM, UWP was COM based, WinRT is still COM, WinUI and the Windows App SDK is again based on COM. C++, C#, Python and Rust are all supported programming languages for the Windows App SDK thanks to - you guessed it: COM. The C++, C# and Rust language projections for it are still being constantly updated: https://github.com/microsoft/xlang
When they started Project Reunion (code name for Windows APP SDK) back in 2021, just before Windows 11's release, they decided to double-down on COM. Like hard.
https://github.com/microsoft/WindowsAppSDK/blob/main/docs/fa...
> Practically speaking, any language & runtime that can handle COM objects can support Windows App SDK
And, I believe, the entire .NET CLR infrastructure is essentially an extension of COM technologies.
Not really. You can use and author COM components in .NET, but most developers use the platform more like Java.
> Interfaces are an inherently weaker form of the age old Operation Code and data packet paradigm.
Only if the language in question doesn't allow something like `interface MyNewInterface extends MyOldInterface { ... }`.
I'm not too clued up on state-of-the-art for OO languages, but my understanding is that this is a practical approach in the mainstream languages that support OO.
For your [0] link, I'm familiar with those arguments, but I believe that this is very subjective. For example, in a modern context, I'd probably use interfaces, which makes all those arguments, except for the state argument, moot.
For the [1] link, I've not read that before but it is a very long interview and I am in disagreement with the general thrust that the argument is "generic programming" vs "OO patterns". If all the facts were forced into that argument, then sure, there might be a point to the criticism, but the fact is that it is possible and simple to use both at the same time.
IOW, they are not in competition with each other, so presenting one as superior to the other is pointless.
> This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change
This is the expression problem[1]. There is an inherent tension between simplicity of extending the number of operations and simplicity of extending the number of types acted on.
[1] https://en.wikipedia.org/wiki/Expression_problem
This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change.
The idiomatic way to deal with this is to add a new interface with the extensions. This not only prevents old code from breaking but also gives you compile-time assurance that your clients and objects know how to communicate with each other.
>> This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change.
> The idiomatic way to deal with this is to add a new interface with the extensions.
I also found that particular criticism weird in the GP, considering that the paper itself, with the widget example cited by the GP, performs the `extend` on an interface to add to existing interfaces without breaking existing code.
IOW, it uses the widget example, quoted by GP, to demonstrate how to add to an interface without breaking changes.
> I think that object orientedness is almost as much of a hoax as Artificial Intelligence
Oof, killing two hypes with one stone!
That interview is a couple of decades old, Stepanov is of course referring to GOFAI.
> age old Operation Code and data packet paradigm
Can you provide more info what you mean by this? Something message-passing like, where the receiver ignores unknown opcodes?
You can take a look at this discussion[0] where Casey Muratori designed something like that where communication is done by opcodes, and packets instead of vtables. Note: search for "raw_device_operation" if you want to get to the code, but reading the whole thing is very worth it. [0] https://github.com/cmuratori/misc/blob/main/cleancodeqa-2.md
Hmm...what's your definition of "object oriented"?
I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind
-- Alan Kay, OOPSLA '97
https://www.youtube.com/watch?v=oKg1hTOQXoY&t=634s
While I also don't know what this "packets and opcodes" thing is, it certainly sounds a lot like, for example, Smalltalk-72. And vtables are certainly not a requirement, more of an anti-pattern for object-orientedness.
and the very next sentence Alan Kay said was:
"So, the important thing here is that I have many of the same feelings about Smalltalk
…
Part of the message of OOP was, that as complexity starts becoming more and more important, architecture's always going to dominate material.
…
I have apologized profusely over the past 20 years for making up the term object-oriented because as soon as it started to be misapplied I realized I should have used a much more process-oriented term for it.
…
If you had to pick one cause of both particular difficulty in our field, and also general difficulty in the human race, it's taking single points of view and committing to them like they're religions. This happened with Smalltalk."
Yes, I tend to quote that second part as well. In fact, I keep that link ready as well:
https://www.youtube.com/watch?t=653&v=oKg1hTOQXoY
Which is why I question the "OO means it has a vtable" stance that seemed the promulgated here. While "packets and opcodes" is a bit non-specific, it does not appear to be incompatible with OO, and, for example, Smalltalk-72 seems very similar to "packets and opcodes"...though, again, it's not really specific enough to say with any certainty.
Fitting, because Stroustrup didn't have Smalltalk in mind. C++ descends form Simula (in addition to C of course).
“In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success”
Win32 is not exactly easy to work with though.
Today we have no interoperability compared to 20 years ago (that existed in Windows or Macos applications).
Most applications people use are on the web or mobile today. Every application on the web or mobile (Figma, Notion, ...) is basically a silo or one way street.
They both have extensive APIs though?
> 3). Alternative mechanisms can provide interoperable extension only by using service abstraction themselves—and thus are equivalent to what we consider the essence of objects.
Since virtually any language can delegate behaviour this way, the above claim is really saying that every language carries the essence of objects. (And I agree - for this definition of objects).
So the follow-up question becomes "What's so special about about languages which brand themselves as OOP - as opposed to another paradigm?"
That you get language support for something you're going to be doing anyhow.
Good to read alongside William Cook's On Understanding Data Abstraction https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
Objects are whatever dangles at the interior other end of interfaces. And interfaces are just plugs. Plugs can have sub plugs, etc.. If you explain object orientation with its realworld engineering equivalent it becomes much more obvious.