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.<p>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.<p>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).<p>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.<p>[0] <a href="https://harmful.cat-v.org/software/OO_programming/why_oo_sucks" rel="nofollow">https://harmful.cat-v.org/software/OO_programming/why_oo_suc...</a>
[1] <a href="http://stlport.org/resources/StepanovUSA.html" rel="nofollow">http://stlport.org/resources/StepanovUSA.html</a>
Today we have no interoperability compared to 20 years ago (that existed in Windows or Macos applications).<p>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.
> 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.<p>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 <i>this</i> definition of objects).<p>So the follow-up question becomes "What's so special about about languages which brand themselves as OOP - as opposed to another paradigm?"
Good to read alongside William Cook's On Understanding Data Abstraction <a href="https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf" rel="nofollow">https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf</a>
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.