Ask HN: Why do new(ish) programming languages eschew OOP features?

Python didn't beat R because it's OO. It won because of its existing popularity (with many people learning it in their intro programming class) and the massive amounts of open source software built for it.

> People just don't have enough experience with Functional Programming to really know how awful it is

This is just anecdotal, but I've used a FP language full-time for the last two years with several other engineers and ramped others up on the codebase. It has its own challenges but it's significantly easier for me to reason about than OOP - less bugs, easier to maintain, easier to parse. I can't see myself ever willingly going back.

It might be helpful to know what problems you think FP has, if you have a significant amount of experience with it.

This raises the question: how have we concluded that these parts are bad? Inheritance is the easiest one - it tends to dramatically increase the surface for coupling, which is why composition is recommended over inheritance. Classes is more subtle; I would say the issue with classes is that they strongly encourage you to couple various aspects, as classes are a single programming construct with which you do data representation, data specification, interface declaration, interface implementation, code organization, plain old logic, state management, and sometimes types declaration and concurrency control.

It takes discipline and awareness to resist the temptation of baking many aspect of a program into one class (even more so when you have to come up with a name for each class - naming is costly!), whereas it's natural in a language where each of these aspects is addressed by a different language feature. Finally, this temptation is made even stronger because class hierarchies feel so elegant - you spent a lot of time designing your class hierarchy (deciding where each part of the logic goes, choosing if methods were public of private and so on, applying various design patterns, etc.) so that MUST mean you've produced quality code, right? We love to tell ourselves this story, when the truth is we wasted a lot of time on non-essential decisions.

So many programmers don't resist the temptation, and end up with a tangled inflexible mess.

Don't take my word for it - try a variety of 'OOP' and 'non-OOP' languages! You can't achieve a good understanding of this unless you have empirical perspectives from both the inside and outside.

One thing that doesn't help is there isn't an agreed-upon clear definition of OOP. There was one made by Alan Kay, but the mainstream language we call OOP are very far from embodying it. So OOP is more a fuzzy cultural notion: "this cluster of mainstream languages that use classes." I think it would by much easier to discuss all of this if we separated the notions of 'OOP' and 'class-based programming'.

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.

1. OOP is technically unsound

2. OOP is philosophically unsound

3. OOP is methodologically wrong

4. OOP is a hoax

[1] http://www.stlport.org/resources/StepanovUSA.html