[ncmncm]

Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented. Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good, generating spurious conflict.

The fiction has largely dissipated, except among pundits and the aggressively ignorant. Meanwhile, a backlash insisting OO is a fundamentally mistaken design element arose among some loud users of not-OO (not to say not-good!) languages. Even among users of what were called OO languages, C++ particularly, the relative importance of OO techniques has fallen off as other language facilities and conventions surfaced.

C is just not adequately equipped for what is formally defined as OO. You can cobble up a dodgy simulacrum of it, with enough effort, but what is the point? Other languages make it easy, and can invariably be used in place of C if you really feel like you want OO.

If you are coding C++, you probably long ago graduated from the notion that "OO" has any particular merit as an organizing principle, and simply use language features to achieve your goals. Some part of any big-enough system will look OO, more or less, if you care. Few working C++ programmers do.

Some languages, Java particularly, aggressively try to horn everything into the OO shoe. The result is that if what you want to do doesn't fit, you must abuse what features the language offers to achieve what you mean to do, typically with some violence to OO norms. There's nothing wrong with that. It was, rather, wrong for the language to provide you with only OO facilities to the exclusion of all else.

[crtc]

> Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented, and anything good had therefore to be called OO. Saying something was not actually OO (as we find here) was taken to mean it was not good, generating spurious conflict.

A similar thing happened with functional programming.

[dustymcp]

thank you, it doesnt matter what brand of hammer you use aslobg as the quality is sufficient.

[pjmlp]

https://microsoft.github.io/microsoft-ui-xaml

> WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease.

Apparently Microsoft does care about OOP in C++.

As does Apple,

https://developer.apple.com/metal/

https://developer.apple.com/documentation/driverkit

And Google,

https://github.com/google/oboe

https://www.tensorflow.org/api_docs

Maybe modern C++ is safe from OOP, so lets look into ranges,

https://en.cppreference.com/w/cpp/ranges

So we have factories, adaptors, concepts (aka interfaces/traits in other languages), std::ranges::view_interface as base class mixin, all stuff I can find on the Gang of Four book.

[ncmncm]

I wasted time looking in those links. The WinUI page does not mention base classes (or prototypes), inheritance, or any sort of runtime binding. A "highly-optimized C++ core", in particular, does not imply OO. The std::ranges view_interface template is not OO; it uses concrete inheritance purely as a notational convenience.

Likewise the others, with one exception. The Apple driverkit page does mention base classes.

Factories, adaptors, concepts/traits/interfaces have nothing to do with OO, beyond that OO designs often also use them. OO designs define functions, too, but functions do not imply OO.

It is, in any case, meaningless to trot out apparatus system-vendors oblige programmers to use to access proprietary facilities, and equate that to programmers' interest in whatever tech is used for them. Programmers are interested in using the facilities, and are glad when whatever they are obliged to use works at all; too often it doesn't.

[pjmlp]

WinUI uses COM/WinRT, COM is an OOP ABI, and WinRT is basically COM v2, with TLB libraries replaced with .NET type system and types must support IInspectable in addition to IUnknown. Are you going to argue .NET isn't OOP?

As for the rest, OOP doesn't imply inheritance, BETA and SELF are good examples of OOP without inheritance.

[ncmncm]

Nobody uses Beta or Self. And, no matter how much alphabet soup MS throws at its long, rolling UI debacle, it demonstrates nothing about general programmers' current level of interest in OO.

[pjmlp]

Arguing against industry usage of OOP, including C++20 own standard library, trying to fit one's little window of the world, also doesn't help.

[_old_dude_]

OOP is great when you write APIs/libraries (your examples), but is useless or even counter productive when writing applications, where encapsulation or inheritance just obfuscate everything.

My main grip with Java is that everything is by default a library.

But there is hope, recent changes in Java, records and pattern matching move away from that idea.

[kitkat_new]

saying OOP is only useless and counter productive is as short sighted as saying it is the golden hammer for everything.

PS: WinUI apps use plenty OOP

[_old_dude_]

It's not what i've said, OOP is great for creating APIs like WinUI, not great for writing applications

[jcelerier]

In which universe an application which uses mainly OOP APIs isn't itself OO.

[_old_dude_]

What OOP is good at is maintenance over the time by making clear what is API and what is implementation.

My point is that when you develop an application, you only need strawman OOP i.e. calling methods.

You don't need class inheritance if you can pass functions as parameters, you don't need encapsulation given all your pieces co-evolve at the same time (if it's not split than part into a library).

[kitkat_new]

and WinUI apps are applications, and - as said - OOP is used by them, see e.g. the reference architecture guide

[vbtemp]

> Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented. Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good, generating spurious conflict.

Excellent point, and I think in our contemporary age something similar is happening with "Agile". It has ceased to become a project management technique useful for a certain class of products. It has instead become redefined to mean "good" - for example, in popular imagination, if a team is not "Agile" then they are somehow backwards or out-of-the-loop. Now teams, products, and situations where Agile is not appropriate are finding themselves having it forced upon them, or spinning what they do as agile.

[ctrlp]

Agile has meant 'bad' for years now ever since Agile processes were formalized and adopted by big orgs. At least that's how I've thought of it: 'Agile' means the worst of all worlds. Run if you can.

[vbtemp]

Well it's become the exact corporate management hell that the original manifesto authors sought to fight back against. I personally avoid joining teams or companies that drank the kool-aid, and additionally find agile to be a particularly counter-productive way to deliver value to customers quickly. About 7 years or so ago I had the first inkling things were wrong when "Agile Coaches" appeared who were not developers.

It does, at least, facilitate micro management and burnout.

[ByteJockey]

The rule of thumb I've noticed.

If they use "agile" as a noun, they generally have no idea what they're talking about and you should be careful.