How bluepill is OOP?

How bluepill is OOP?

It's a great tool when used correctly, and will turn you program to shit if you use it incorrectly (See "enterprise grade software").

What is the correct way to use it? Making everthing in your software a class and encapsulating as much as possible? Putting every single data type in it's own file?

OOP is great when you deal with multi-user scenarios, where you have different departments writing different parts of the software. OOP allows you to serve the API to another group, and have them work on it as a "black box" scenario, where they just know how to interact with your module, not how it works behind the scenes.

However when you start using OOP for shit that should be a struct or enum or even just a single variable, or start using OOP redundantly (Eg. FactoryFactory) that's when performance takes a big dump on your carpet.

...

Why can't you do the same with any other programming paradigm? Just give them your functions and data types with docs and they can use them without looking into them.

Use it when it will make your program easier to understand and modify. If you have classes that are duplicated many times with minor changes OOP is a good style to use.
The easiest example would be a game, where all the player characters and enemies are based off of the same base class that allows movement, inventory, animations, etc. Items can based off of a single base class and spawned with different attributes.
This approach applies to a lot more than games but it's super obvious how you would use OOP in vidya dev.

OOP is great if you want to write large monolithic programs and you want to cleanly separate different parts. It's like applying the Unix philosophy inside the program's source instead of at the OS-level. Of course there is the question of whether you should be writing large monolithic programs in the first place, but that's another topic.


No, this is the sort of thing that leads to OOP-spaghetti. What about enemies that don't move? What about power-ups that do move? What about power-ups that can hurt you as if they were enemies, unless a certain condition is met?

What you instead have a "components". An entity in the game is usually just a way of telling a bunch of components "you guys belong together" while the components do the heavy lifting. There can be a "spatial" component that gives the entity a position. There can be a "hit-box" component that allows for collision detection. There can be a "health" component that allows entities to take damage or get targeted. An enemy like a Goomba in Mario is then just a particular pre-defined collection of components we perceive as a Goomba, but there is nothing in the game code that explicitly makes it a Goomba.

That's all fine and dandy for "first generation" programmers who either wrote the functions themselves or are in direct contact with the ones who wrote the functions.

What happens when you pull in your 49th Pajeet and tell him to use all these functions though? OOP isn't about being the most efficient way to get things done. It's about being the simplest, most scalable way to get things done. It offers almost no advantages to single programmers and solo projects, because it's designed from the ground up for corporate programming environments.

If they were well documented, appropriately named and do one thing well, why should the 49th Danesh have more problems than the first one? Also why would Neerav have any more problems with functions and data structures than methods and classes Sahil left him with?

And then there's the spaghetti to handle components that get in each others way.

Sure feels nice getting shit done while you faggots are too busy being autistic over utterly irrelevant tech autism.

great post

I don't think you have the IQ necessary to program. You can barely communicate as is.

OOP was a mistake. The only useful function it has is to group related functions in a discoverable way and shorten names but the design does so at an unnecessary structural cost at runtime and is very limiting. If you write a lot of C this becomes very apparent to you, as it also does when you're forced to mix OOP and data-driven code and they mesh like oil and water.

Unnecessary structural cost at runtime?
I thought that languages like C++ provided "cost-free" abstractions.
I've heard people say that properly written object-oriented code will compile to the same, or almost the same assembly as well written procedural code.
This has been by experience thus far.

That's just plain not true. There's plenty of cost, it's just hidden well. Barring things like virtual functions that create implicit vtables and usually many small allocations with large overhead and looking only at things you can't avoid you'll still have unwind tables or SEH headers depending on the ABI of the system you're compiling for, as well as many more compiler-specific requirements of the runtime library such as per-TU ctors running before main requiring at least in part a dynamic linker.
There's also RTTI which will litter your binary with dynamic type information and the use of the standard library or indeed any templated abstractions will insert massive amounts of code, exploding your text segment.
The language also promotes a coding style that constantly allocates very small (1-4 ints in size) chunks on the heap, which is obscenely slow and has lots of dynamic overhead as a single allocation can and will take a global lock and probably reserve at least 32 bytes for that one 4 byte integer, and if malloc doesn't take a global lock you can be damn sure free will (new/delete are calling malloc/free, presumably to avoid fucking up the brk when C code gets involved). But perhaps more importantly this tends to fragment the data leading to worse cache performance and fewer vectorization opportunities, which is why any performance critical code is always written with contiguous memory and very data-oriented code.
Ultimately writing what amounts to idiomatic modern C++ code is like writing abysmal C code, only with more compiler-required dependencies and a lot of garbage you don't really want in there. To GCC's credit it's pretty good at proving by way of static analysis that something is never used and thus can be removed, and you can turn a lot of things off and kill the dependencies with stubs, but that's very non-portable and frankly ridiculous - plus you'll probably break some library you're using by doing so.
If you want to be really pedantic you could also argue that the compile time overhead is a significant abstraction cost, albeit not a runtime cost. By placing so much code in headers you're compiling a lot more code than you otherwise would and it takes an unholy amount of time.

OOP IS PAJEET
>MFW HASKELL IS REDPILL

...

Adding muh and writing with poor grammar doesn't make the argument any less valid

But user, OOP isn't the right tool for any job

Thank you user, you make Holla Forums worth looking at.

Haskell is the tin foil hat of ideas.

Check out the Common Lisp Object System for good OOP.

Put an S at the end, and now you know the answer!

Shut up

You make Holla Forums not worth looking at.

...

That actually describes OOP most accurately.

meme()

The trick is, it's not an obscure meme, so you can use it to impress people other than us.

I know your native language is Holla Forumsmeme and all, but come back when you can speak English.

...

OOP is actually pretty great... when done right. Spend some time learning Smalltalk and you will see it in a completely different light.

Smalltalk's message-passing model that NEETs love wanking about is formally equivalent to method-calling.

muh right tool for muh right job indeed

An approach I like to use when deciding whether I should try to stick with an OO or a functional approach, is instinctively sketching out my program on a piece of paper.

If the resulting drawing mostly consists of actors, then OOP it is, if actions take most of the space, FP.

In reality I always kind of mix the two.
The trick when designing object methods to be used in functional programs is to ask yourself, "is this behavior really specific to my data type?", if not, get it out of your object. Methods should only be a lightweight interface to your object's internal structure, any more advanced behavior should be in a function.


Yes, method-calling is message-passing. The idea is that instead of having a function handle multiple data types, you call a name and pass in some arguments and the object can do whatever it wants with it.

...

Smalltalk is pure OOP unlike the oop+imperative abominations of C++, Java, C# and the like.

Thank you for proving my point. *tips MAGA hat*

gettin' real tired of these reruns tbh fam

...