/tech/ - Technology

Unless you are really good at coding, avoid the tricks that reuse code, it causes "spaghetti code problems". If you make changes to code that is reused, it will break shit in places you have forgotten about. Write code that easy to read and fix.

It's generally useful for business and user-focused applications. Which are the majority out there.
For some things, yes, it's not necessary but there's a reason why it has been around for so long. It provides some kind of basic structure to the code and once you become comfortable with it, it will more-or-less work well enough for most of the applications you write.

It doesn't really matter. It's not "amazing" nor is it the devil. It's nothing more than a convention. Sometimes that convention is applied to an entire language (Java, C#, Smalltalk, JavaScript), sometimes that convention is applied to most if not all of a software project, sometimes that convention is applied partially, to various components, of a software project (common in C++ software projects). Personally I think it makes sense to use OOP when designing the GUI component of a program, especially when you start implementing callback functions when continuously checking onclick, onmouseup or onhover events in a program loop.
There are a few hazards to look out for in OOP though, such as inheritance hell, design patterns, CPU cache unfriendliness and dynamic/virtual dispatch performance overhead. Inheritance hell can be mitigated by preferring composition over inheritance. Rust for example doesn't support inheritance for this reason. Design patterns are thankfully out of fashion and largely made obsolete by functional programming features added to all the major languages so no one wastes their time memorizing that stuff. The last two hazards only really matter in low-latency programs like video games and high-frequency trading, but the way you'd deal with them is by writing structure-of-arrays instead of array-of-structures and banning virtual dispatch (no virtual function/method calls allowed).

>>8384
You mention games in your post but funnily enough the entire games industry has moved away from OOP for a while now, not least because of the performance costs it inevitably incurs.

>>8390
Great post.
I personally limit myself to a single layer of inheritance max on my projects and it works fine. But even then I use it sparingly and favor composition wherever possible.

I would say that inheritance has its place, but the philosophy of OOP is actually harmful in its dogmatism and disregard for how actual CPUs behave. I didn't actually enjoy programming until I untethered myself from this over-hyped, all-encompassing philosophy. Good on OP for having the nose to sniff it out.

>>8391
There was actual research into making hardware that would better fit objective oriented code, we could have had it, but unfortunately at that time improving the hardware for C was still easy and more profitable. Today, after decades of trying to fit the processor to C, every architecture has its own unportable extensions to it because C was made for the processors half a century ago and has a complete disregard to how actual processors today behave.

I'm sure we will all agree that functional programming languages are the "flat Earthers" of microarchitecture, with their linked lists and obsession with immutability.

>>8391
>I would say that inheritance has its place, but the philosophy of OOP is actually harmful in its dogmatism and disregard for how actual CPUs behave. I didn't actually enjoy programming until I untethered myself from this over-hyped, all-encompassing philosophy.
I'd say that apply to all programming paradigms. These are just tools, you can use them right or wrong, and they have good use case and bad use case, dogmas are always shit when you deal with real world, and there's a good reason most language now feature all at once composition, inheritance, lambdas, and functional features.

>>8384
If you want a job, you must know it.

If I had to stop using it, it wouldn't be the end of the world, but god generics are just too good.

>>8398
But it is trendy to hate OOP because it is mainstream. Even thought to this day Smalltalk is still the best programming language in existence.

Imagine adopting a philosophical platonism in your code lel
It does have use in GUIs (imagine having to recreate the functionality of buttons for every clickable element on the UI) and arguably games. But the last one is a bit contentious because getting too OOP in your game engine causes issues with caching because your data won't be performant in cache lines.

>>8390
> Personally I think it makes sense to use OOP when designing the GUI component of a program, especially when you start implementing callback functions when continuously checking onclick, onmouseup or onhover events in a program loop.
never understood this argument. you can just use multi threading and multiprocessing for things like this.

>>8401
Small talk is not modern OOP.

>>8422
Oh now it has to be "modern"?

>>8423
do you agree that when someone says OOP in 2021 they are talking about something which is distinct from Smalltalk?
no it doesn't have to be modern, I don't think people are against OOP for abstract reasons, but against OOP as it's implemented in Java and C++.

>>8424
No, /tech/ have conclusively demonstrated that they don't know what they are talking about. Smalltalk is thoroughly OOP, you can't get any more OOP than it, and most of the criticism in this thread applies to it. It has deep hierarchies, dynamic dispatch (which imho is the defining feature of OOP), a complete disregard for how CPUs work (no wonder it pioneered virtual machines and JIT), etc. You will have to make up your mind about what you hate in Java and C++, is it the OOP? The imperative? The mixture of the two? But you can't just excuse Smalltalk because it is a hipster language unlike Java and C++ which are preferred by the unwashed programmer masses.