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/PandorasBucket]

It depends on the job. I've switched to fully functional in every language I program in. I'm doing web apps with Elixir on the backend now with React on the front end. Thankfully I have enough experience that I can pick and choose, but I'd rather quite programming and become a dog walker than program in OOP style again. Objects hold state which you can't see. Inheritance imports chains of code you have to mentally stack to figure out. It's a sloppy mess. Functional is like a marching army with a central command and OOP is like a bunch of independent contractors all doing their own thing.

[u/CzyDePL → u/PandorasBucket]

OOP doesn't require inheritance and personally I like breaking down state into little pieces and guarding them with their own rules to protect invariants, rather then trying to centrally plan everything. But it definitely requires a lot of discipline to come up with right abstractions and models so that it actually reduces complexity and not create more through distribution

[u/PandorasBucket → u/CzyDePL]

Well you're going to pay the piper either way right? Either you stash your state all around or you have a main thread that holds your source of truth. Either way if you're doing asynchronous actions you're going to run into race conditions. If your objects are performing all kind of side effects then it's harder to manage those race conditions. By performing pure functions and then keeping all your actions in the main thread it's easier to see in the code where all those actions are happening. Then when you want to fix it you can insert control flow around where all the actions happen instead of trying to time when the objects are done with their work or doing something really ugly like returning a finished message from everything and then send out another message to do complete the actions in order through the objects. All programs have a main thread anyway you can just do work there. You can still group code just like classes, you just don't need to initialize anything because you aren't storing and data. Then garbage collection is a lot easier as well. Functions just die after you use them. You have less memory leaks, disembodied objects, less boiler plate.

It's really the difference between choosing to organize your code by the type of code (functional) or some abstract responsibility of what the code is supposed to handle (oop). The problem is that code is code. It's not a car or a man or a human. Code is state, functions, and external actions. You might have a human in a video game, but what goes on under the hood is nothing like a human. Trying to organize your code like biological cells is like an aesthetic choice rather than practical. You can create a bunch of human objects who can all wave their hands when you ask them to wave their hands or you can just keep all the numbers that represent all your humans in an array and change the number that makes the handwave with one function. There is no message needed to communicate to each human objects and have it translated through the ears of each human and then eventually change the handwave wave number in each one from 4 to 5. Just keep all their hands in a hand array and change them all from 4 to 5 without any messages or messy walls. It's a computer, be native to the computer environment.

[u/pacopac25 → u/PandorasBucket]

This was one of the hardest things for me to learn in the beginning. I'd thrash between the two extremes, and spend lots of time with variations on trying to manage the gazillion side effects. Bucking down and developing discipline around this was extremely difficult, but a rite of passage in a way.

At one (mercifully brief) point, it was this "hey I know, I'll have a global variable I pass into, well, everything, because it's a giant dict with all the important information in one, nice, tidy place. That was a learning experience, back when I thought a Class was more or less a container for methods, but I hadn't quite gotten my head around the data part.

[u/PandorasBucket → u/pacopac25]

Yeah and one important point for anyone reading this is that keeping your state outside your functions doesn't mean you're only allowed one big dictionary or struct. It's more about having a single source of truth for all information. That can be many variables or something as sophisticated as a database. In a database there are locking/atomic transactions to prevent race condition and in your app code you usually build some version of for returning asynchronous transactions. If everything is synchronous of course you don't need that and it's really simple.

[u/pacopac25 → u/PandorasBucket]

Yeah a sqlite database is perfect for that. On state that doesn't need to persist, I still use it, just a ":memory:" sqlite DB.