Oop sucks. hate thread

Check'd

>muh polymorphism
>implying you need oop garbage to do this

void (*interface)(void) = & implementation;

The biggest problem is OOP is constantly shoved into solutions for problems it offers no real benefits in solving. I feel like Java and academia is mostly to blame for this. I think there are some areas where it is useful, particularly when you have to represent and manipulate a lot of state. Things like GUI programming or scientific simulations seem like applications that can actually benefit from OOP. However, it feels like most of the time when using OOP programmers waste so much time trying fit everything in some forced and almost hierarchy and other OOP practices instead of actually just focusing on the problem at hand.

Attached: connect_port.jpg (500x519, 54K)

oopajeets can't defend this
in real world applications, oop isn't even any easier for a human to structure or conceptualize than procedural code, unless you're a brainlet

*Sips cup*
*Ahem*

You should try 'butts' the language if you don't like OOP. Butts will get you into places and no need to learn such a complex thing that is object oriented programming. Try butts now!

Attached: java.png (1200x2195, 116K)

>oop sucks. hate thread
Are we supposed to be hating oop, or hating "oop sucks" people/message?

>humans can't get fleas
Throw this design out and start over

learn how to properly design software, you moron.

The advantage of polymorphism is that it's much easier to bind data to function pointers. It's basically just a macro for convienience.

Composition doesnt really have anything to do with encapsulation.

>doesn't know you can pass around references instead of copies
>thinks OOP has anything to do with heap usage

OOP is in fact very similar to procedual code, you just replace a struct passed into a function with an implicit "this" pointer.

>Angry unemployed codelets thread

Attached: 40EF9AB9-E4ED-4AED-9028-EC35435F47AB.jpg (1440x795, 122K)

The only thing that works from oop is the dot notation for calling methods.

>tfw when you have to use java and c# for work

>The advantage of polymorphism is that it's much easier to bind data to function pointers. It's basically just a macro for convienience.
oop polymorphism notation might be slightly more convenient than function pointers, but at what cost?

>Composition doesnt really have anything to do with encapsulation
correct
the point is that, if you're avoiding encapsulation, all your objects will be composed of is pure data
a c style struct works for this, you don't need oop

>doesn't know you can pass around references instead of copies
if you're passing a reference to a global object that can be modified by others, then your code is no longer encapsulated

>thinks OOP has anything to do with heap usage
objects which mix data stored on the heap and logic are inherently going to have said data located further apart, which is a cpu cache nightmare
im not talking about stack vs heap usage, just that heap usage with an oop model is extremely inefficient

check back in a few hours and i'll post an example

>complain that c makes you declare shared functions in header files
>c# compiler is much more intelligent

later...

>IManager.cs
>IDataContext.cs
>IEventArgs.cs
>Manager.cs
>DataContext.cs
>EventArgs.cs

C would be perfect if it was Rust.

If you are binding data to a function pointer polymorphism is much more than "slightly more" convienient. To do this in C you have to use void pointers and a ton of opaque boilerplate. I know how to do it, but polymorphism totally removes the need for that.
I use C structs for my data, and I pass it around by reference to my classes. I treat classes as functions with bound data. It works well i think. Generally my classes have just one public function, so they might as well just be functions to the caller.
Passing references to an object doesnt break encapsulation. I'm not sure what you think encapsulation means so I don't even know how to refute that. Also - I dont think you need OOP for encapsulation.
My design is like this. I have a data object (C-struct) and an algorithms object (class). I put both in the same class/struct and allocate them as a group on the heap. There is only one big heap allocation for all the data and classes. The algorithm object accepts the data object as a reference in the constructor and mutates it through the public functions. I think this is probably a sort of FP style, but I've never studied FP, I just gravitated to this style over time.

Right side of OP image is literally "properly design software" you moron.

Way to assert that you're a brainlet by somehow thinking two unrelated concepts are the same.
If you wanted to do vtables and interface-like constructs in C you would end up with the same amount of classes AND you would still have to deal with header files.

Biggest problem with OOP is idiot cargo cult programmers that parrot advice like "program to an interface not an implementation", without any understanding of what it really means (protip: using the "interface" keyword doesn't mean it's a good interface). The fact that you don't seem to see anything wrong with a file called IEventArgs.cs probably means you can't write OOP either.

You know that design patterns aren't only about inheritance but composition

Attached: brainlet.jpg (1024x576, 121K)

from where? show me a single OOP design reference that properly addresses "cross cutting concerns". It's like OR impedance mismatch on it's own bullshit

Guys I think he meant OP sucks, hate thread.

>
THis seems like the perfect thread to post about this.

Is there any modern language
modern procedural language
that is like C / assembly++
but better?

Better in what way?

none of the legacy baggage,
i dont care about embedded for this lang

Go/Julia/Rust

why would you reply to my post with those languages?

Literally
>none of the legaccy baggage
>shit at embedded compared to C

How are they like C and/orassembly but better?

You can write programs in them, just like C and assembly, but none of the legacy baggage, and they are shit at embedded.

>you can write programs in them
>you can write programs in them
>you can write programs in them
gave me a laugh thanks

I never understood why OOP was supposed to be particularly good at code reuse.

Anything with clearly defined set of responisbilities and a clearly defined interface can be reused as a library regardless of programming paradigm.

Code re-use isn't even hard
just use ctrl+c ctrl+v
or if you cant even bother with that, just inline it.

Obviously creating abstractions for value objects is retarded, but when the dude is conflating the verbosity of header files with interfaces it's the least important thing in his post to address.

anything OOP can do, structured/imperative/procedural/modular programming does better.

>brainlet: the post

I agree, but that has absolutely zero to do with what I posted. OOP being a honeypot of pitfalls doesn't stop C header files from being retarded and it also doesn't stop interfaces/traits/type classes/vtables from being useful concepts.

That's like saying
>imaginary numbers suck, they are too complicated
Sure you can hate them, but at the end of the day if you want to do maths you need to know them

my get will prove this is absolute truth

>brainlet tries to make an argument

OOP makes it easy to make abstractions for enabling easy extending or modifying the logic

Attached: fizz.png (963x666, 53K)

OOP is good for GUI code or gamean