A big idea of OOP is to allow components to evolve independently. Java ensures that today's code would run on next year's JVMs and class libraries. Your user's upgrade their OS and your app keeps running, and now supports dark mode. Rad, right?
But new languages like Rust/Go/etc have bincompat as a non-goal. A minor version bump means fix the compiler errors, recompile the universe, giant static binary, GtG. This is sweet for server deployments.
Meanwhile client-side has shifted in the other direction: it's harder than ever to launch a new programming language that runs on your user's computers. The major OS vendors now control the programming stack: ObjC/Swift, Java/Kotlin, etc. Supporting an alternative stack like React Native or Flutter requires enterprise-level investment. OS vendor tooling and APIs form an immense moat.
JavaScript is the exception that proves the rule. JS has its twisted take on objects, but supports enough dynamicism for reflection, polyfills, etc to permit backwards and forwards compatibility. This is where OOP shines! (Imagine replacing JS with Rust - it's absurd) But JavaScript is so hard to compete with on its turf - the web - that it sucks all of the oxygen out of the room. (WASM makes the problem worse, not better: there's zero plausible bincompat story for WASM APIs).
OOP is about enabling independent evolution of components: the OS, app, plugins, etc. all in a conversation. The modern computing landscape is about siloed software stacks on a client, and statically-linked megaliths on a server. The strengths of OOP can't be engaged now.
I agree with your thoughts on how everybody neglects the desktop, but an independent evolution of components can also be achieved without OOP. Also OOP doesn't guarantee future compatibility - it can make it easier, if implemented with that intention in mind.
However, it looks like ensuring backward compatibility is an enemy now: users are forced do upgrade, sometimes every day, so obviously in the eyes of those corporations backward compatibility can be completely ignored.
A big idea of OOP is to allow components to evolve independently. Java ensures that today's code would run on next year's JVMs and class libraries. Your user's upgrade their OS and your app keeps running, and now supports dark mode. Rad, right?
But new languages like Rust/Go/etc have bincompat as a non-goal. A minor version bump means fix the compiler errors, recompile the universe, giant static binary, GtG. This is sweet for server deployments.
Meanwhile client-side has shifted in the other direction: it's harder than ever to launch a new programming language that runs on your user's computers. The major OS vendors now control the programming stack: ObjC/Swift, Java/Kotlin, etc. Supporting an alternative stack like React Native or Flutter requires enterprise-level investment. OS vendor tooling and APIs form an immense moat.
JavaScript is the exception that proves the rule. JS has its twisted take on objects, but supports enough dynamicism for reflection, polyfills, etc to permit backwards and forwards compatibility. This is where OOP shines! (Imagine replacing JS with Rust - it's absurd) But JavaScript is so hard to compete with on its turf - the web - that it sucks all of the oxygen out of the room. (WASM makes the problem worse, not better: there's zero plausible bincompat story for WASM APIs).
OOP is about enabling independent evolution of components: the OS, app, plugins, etc. all in a conversation. The modern computing landscape is about siloed software stacks on a client, and statically-linked megaliths on a server. The strengths of OOP can't be engaged now.