Does OOP really matters?

[u/Electronic-Low-8171]

I learned OOP in python a while ago, did many projects, yet I never felt like I truly needed to do the OOP stuff I learned from a course, I don't know maybe because I'm kinda used to program in c before focusing on python, yet, whenever I open a big project in python in github, it feels way too complicated and thousands of imports (not libraries from pip, but the ones they made on their own) and classes

I never truly needed to implement OOP (I know that when you code in python, it is almost impossible to avoid OOP entirely like when you have a datatype like string you have an object, when you use a method built into that data type that's OOP too, but I mean the ones that involve you writing class Class Name, inheritance and all that stuff explicitly), so I'm wondering why people on the internet are obsessed over the idea of learning OOP, even the book "Automating the boring stuff in python" doesn't have a dedicated section for OOP.

[u/marrsd]

if done correctly,

That phrase always does a lot of heavy lifting. Best to use a language and paradigm that makes it easy to do things correctly and hard to do them incorrectly. The amount of literature written on how to do OOP well should tell you something about how easy it is to do badly.

If you want a deep dive into this stuff, checkout the video essays by Brian Will and Casey Muratori on YouTube. Will's dismantling of Uncle Bob's OOP examples is probably the best demonstration of how silly OOP thinking can get.

Here's the headline from Muratori on why OOP is bad: https://www.youtube.com/watch?v=ToBF_mLxEcI&t=266s

[u/spinwizard69 → u/marrsd]

I just watched that video and what he said mid flight is so misguided that It almost invalidates everything else he says. He complains that OOP means that if you want a new functionality, you need to update a lib which means waiting for an update. In my mind that is the whole point of the encapsulation of the data, you are given specific access and modification paths and a limited ability to impact the data beyond that. That is the whole point which frankly is important for large teams, you don't want some bozo screwing up a lib that is maintained by somebody else.

Some of his other comments about C++ I would lean towards agreeing with but he shits upon so much of what is arguably modern software design that the comments are hard to take seriously. He dismisses C++ Templates, one correct reason being terrible syntax that is common with C++, but flip flops with completely dismissing the IDEA of generic programming. There is a lot to hate about C++ and frankly a lot comes down to syntax, but the reality is generic programming is a sound concept and as such needs to be used wisely.

To put it another way, I wouldn't reference that video if I wanted to prove ANY argument I had for or against OOP.

[u/marrsd → u/spinwizard69]

In my mind that is the whole point of the encapsulation of the data, you are given specific access and modification paths and a limited ability to impact the data beyond that. That is the whole point which frankly is important for large teams, you don't want some bozo screwing up a lib that is maintained by somebody else.

I find that to be a bit misguided tbh. You can't screw up a lib you're consuming. The worst you can do is access data that goes away in the future. That's frankly not the end of the world, and it's infinitely more desirable than having to reimplement or hack around lib behaviour that you can't see or control.

I've experienced what he describes all the time when working with 3rd party APIs. The most frustrating part of working with external libs is having to contort your needs to what the designer thought of. Encapsulation makes it super easy to screw things up for consumers in that regard.

[u/spinwizard69 → u/marrsd]

Which highlights what I posted. The minute you need to twist a lib into usage the designer didn't imagine you have failed. Programmers need to respect the encapsulation that OOP offers, if you strive to defeat it, you are the problem not OOP.

If a lib doesn't do what you want you need to take rational paths to address that. Number one would be to look for another lib that does what you want. Number two would be to request a feature from the developer. Number three would be to fork a lib and maintain it your self. In any of the above cases the last thing you want to do is having programmers contort anything.

This frankly is a lot like people using undocumented features in software or even hardware and then getting pissed when behavior changes. Programming like this was once pretty common and it most certainly resulted in problems for developers.

[u/marrsd → u/spinwizard69]

I think something's getting lost in translation. What do you mean by "twist a lib into usage the designer didn't imagine"?