OOP meme

So when did you grow up of OOP?

Other urls found in this thread:

codeofhonor.com/blog/tough-times-on-the-road-to-starcraft
twitter.com/NSFWRedditGif

when I looked at functional code and realised how retarded OOP was in comparison

There is no programming language, no paradigm, no framework, no methodology that is ideal for all projects.

OOP is perfect for certain projects, and useless for others. The same goes for literally everything else.

The only thing anyone needs to "grow out" of is the idea that they can pick and learn one language-to-end-all-languages, paradigm-to-end-all-paradigms, etc and do everything with that. You cannot. If you try- and many do- you will fail to produce a good, performant, readable, extensible, maintainable codebase.

I grew up out of programming in general.
Back in the days you had to be smart and knowledgeable but now we invented enough tool for monkies to program, so it's a job for monkies.

this

I was doing an animation library.
I started by setting up a clusterfuck of OOP hierarchies like I've taught all my life, but them something clicked inside my head, I trashed it all and rewritten it using only funcions.
The result was a clean, elegant, flexible, highly readable, highly testable awesomes with almost 10 times less sloc than the OOP bullshit.
Since then I'm hooked.

Give me an example where you think OOP is the best choice.

Every programming paradigm can be used in a poor and overly complex manner. It just so happens that most people who program in oop languages do it in a very poor way. Also, what this guy said

What programming language?

Game engine
Show me commercial game engine that is not build with OOP in mind from the ground up
Source: I am an engine dev for one of the biggest mmorpg developers.

>Source: I am an engine dev for one of the biggest mmorpg developers.
No you're not

Whichever.

I don't need to prove anything to some fucking NEET from the internet.

> I am an engine dev for one of the biggest mmorpg developers.
No you're not. Gamedev community is bashing OOP for the last several years, trying to move to things like EBD.

Yeah, you don't need to prove anything you can't prove. Nice assumptions too

Lol you're the one who tried to qualify your statement with some made up crap to impress anonymous internet people but somehow everyone else is the NEET. Sounds like you're projecting.

Yeah, when you present all the arguments to the oopfag's face he falls back to this position "well surely there's a domain where an OOP is the only possible solution"
Except no oop fag has been able to show me such a domain.

What's EBD?
I thought Entity Component System

>trying to move to things like EBD.
>trying
and where did you read about that? I'll give you a tip: Mike Acton does not speak for the whole industry. My company still develops using in-house made engine which makes heavy use of OOP and the previous gamedev company that I used to work at used UE which is not much different.

Call it Entity Oriented Programming or however you like, you understood what I'm talking about.
That's not the point, though. The point is that gamedev is actively seeking a way out of OOP.
I remember reading some years ago some article about a former Blizzard employee that coded Starcraft: BW, and he was telling how they did it in an OOP way because it was the hot shit at the time, and the disaster that ensued.
Let me try googling it.

I have never used OO. It is spaghetti code garbage used by idiot "code designers" that think abstract design is more important than simplicity and functionality.

There's much more "spaghetti code garbage" in non-OOP projects (like linux kernel) than there is in well-thought oop projects. Fucking semen, looking for an excuse for the messed up, unmaintenable shit they call code.

>linux kernel
If you think the Linux kernel is spaghetti code, you've never seen spaghetti code. Jesus, kids, please actually know your shit before commenting and pretending you do.

>EBD
>I don't know what I'm talking about so I will mention blizzard employee blog post about how they did fuck up by not knowing how to design and implement software in oop manner.
TOP KEK

>ITT : retards think the linux kernel is spaghetti code

>my company
Well let me take a wild fucking guess, it's a not a very successful company, is it?

>The more of an IT flavor the job descriptions had, the less dangerous was the company. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

Java is by far the worst OOP IN LOO language though.
At least use something decent as a comparison.

>Well let me take a wild fucking guess, it's a not a very successful company, is it?
Well you're wrong.

Which language has a good OOP implementation in your opinion?

Surely you can at least give your company's name? That won't deanonomize you. Or will you fall back to your
>hurr durr i don't have to prove shit herp derp neets derp derp
bullshit?

Plot twist: he's 15

Not him but Go has a pretty good one.
No inheritance, structurally typed interfaces, methods are merely functions attached to structs and work as special syntax for stateful operations, type embedding and only package-private encapsulation.
In Go people use OOP when state needs to be encapsulated, and that's about it. Not for everything, only for encapsulating state.

>Which language has a good OOP implementation in your opinion?
Python. Unfortunately people learn maybe 25% of the language and then conclude that it's shit.

There are a couple things I dislike about it (like how special method lookup ignores instance attributes, it does that for a reason but you'd think they could find a better way). But ultimately, things like metaclasses and descriptors really make it a good language.

>Linux kernel
>Spaghetti code
Kek

this

Why the fuck do you care so much about someone's job? Do you want to get to him to suck his fucking cock?

...

Nice b8

I never fell for it. I've fallen for the multi-paradigm meme though.

Encapsulating state is the first and biggest bullshit of OOP. With encapsulation you do not get rid of the state, you just make it less accessible, but you still have to worry about it. Whenever you send a message to an object you're potentially modifying state.

How is Python OOP different from Java? Multiple inheritance? You know not only multiple but regular inheritance is considered harmful and even OOP apologets advise to you the facade or some similar pattern instead of inheritance?

Nice samefagging, kiddo.

>OOP IN LOO

Majestic

>Whenever you send a message to an object you're potentially modifying state.
>what is const

I don't even...

clearly you don't

>you just make it less accessible
yes that's the point
you know why people tried to abolish state in the first place, right?
because firstly it's harder to follow control flow involving state (especially global state, local state isn't that much of an issue), secondly because state opens up lots of possibilities for invariances.
encapsulation reduces the damage of the second issue by encapsulating state in a way that reduces invariances for the public API.
when you've got scope in your language then that's some sort of encapsulation. scope reduces name collisions and possible invariances. EVERY relevant language has this, because working without *any* kind of encapsulation would be extremely painful.

of course you should reduce state as much as possible, but you cannot get rid of all state, "necessary" state (as defined by tarpit) exists.

I've noticed something funny.
About 90% of people that bash oop didn't even take part in development of anything larger than fizzbuzz-tier programs, they don't know how and when apply design patterns and are shit programmers overall.

Welp, I guess this description fits most of c programmers.

Yes, I know why people tried to abolish the state, my point is OOP doesn't simplify state, it often makes it even worse. And it's not as much state as its mutability.

Google Paul Graham's pyramid and take a wild fucking guess where exactly your post would be situated on it

Shouldn't both oHuman & oPet have ``legs = 0;''? I mean a oSnek has 0 legs, a oDumburd has 2, and a oMikeCoots has 1.
Is that the joke?

>How is Python OOP different from Java
Classes are first-class objects.
The can be modified on the fly like any other object, or generated dynamically.
Classes themselves have a class, called the metaclass. By default, it is 'type', but you can make a subclass of type and use that to construct a class. A common use of that would be to track every class and subclass made from that metaclass, so that a DB table can be made for each class you want to store instances for.

Instances are very bare. If you define something on the class, the instance doesn't actually keep track of that. A variable only gets put in the instance dictionary once the instance assigns a value to it. This allows for things like modifying class attributes after creating instances, or even changing existing instances to other classes.

Descriptors are also nice. Everyone uses descriptors without even knowing it, since that's how object methods are implemented. @property is the simplest one, which lets you convert a plain attribute to a getter/setter pair without breaking anything.

Then there's stuff like __instancecheck__ and __subclasshook__ that let you override the behavior of isinstance() and issubclass(), allowing you to do duck typing while still using the easier to read and understand inheritance-based typing.

There's a lot more. You can learn something about python every day but still never know it all.

Yepp, that's when your manager tells you you need to implement the feature ``oSnek'', and you realize you'll have to rewrite the whole fucking hierarchy to make it happen. That's basically OOP in a nutshell.

Encapsulation can only ever be sufficient to control state if you also have linearity, where every object is owned by at most one other object (or the main function). This forces you to structure your entire program as a tree, where objects have to propagate messages up and down the tree in various ways to get anything done. So why not just have a linear type system in the first place, but make it more powerful, in that you can have either a unique, mutable reference (or the object itself) or N immutable references, like in Rust?

OOP failed at what it was designed to do: control mutation of state. It might still be alright as an abstraction tool in rare cases, but it's not something that needs to be a "paradigm" anymore.

It's all just syntactic sugar. I thought you'd bring up something like Eiffel, or Smalltalk, or even CLOS.

what you're saying is absolutely unrelated to mutability, though
encapsulation is useful in *any* regard, especially to reduce name collisions
it allowing you to reduce mutability state invariances for necessary state is just a strong bonus

sure, when people start applying OOP to everything it's gonna be shit because they're intentionally causing state where none needs to be, but that's the fault of education trying to force OOP into every problem, not of encapsulation

You're basically describing modules. No one is arguing against modules, they're just common sense. No one in their sane mind would put state in their modules, though.
Well, maybe except for Java developers, takes a special kind of retard to decide that module = class and design a whole fucking language around that idea.

Well, I guess
>The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.

The only time I would say OOP is alright for a game engine is having an interface like IVertexBuffer and then implementing it with D3DVertexBuffer, GLVertexBuffer, etc. Because you won't be using the different implementations at the same time, the cost of virtual method calls is avoided through branch prediction.

Otherwise, no, OOP isn't any more useful for game engines than it is anywhere else. And it's not very useful anywhere else. I guarantee that if you started writing in something like Rust, which solves the problem OOP tried to solve (control over state mutation) in a much better way, while having niceties like a decent module system and method syntax for procedural programming, you'd never go back.

the underlying implementation doesn't matter. do you even abstraction mate

Encapsulation doesn't have anything to do with name collisions. It's about hiding the field or method, not putting them in a "namespace".

was:
>int a
became
>class Bullshit{
>private int a;
>public set(){}
>public get(){}
>}

Hey, everybody! I've just solved our state problem!

Java

If you find the article, I'd like a link.

>take original picture
>copy it over
>add a bunch of THROW THROW THROW EXCEPTIONLOGGING
>call it what OOP really looks like

So you're saying OOP users claim to never use exception handling when they actually do?

How would you build a module in ?Java without classes? Not trying to call you out, just genuinely curious

Does you boyfriend like to fuck you in the eyesockets? Didn't you notice anything else except the throws?
Exceptions are an exception-ally(get it? get it?) bad idea, too, but that's another matter.

mate you forgot to implement the IBullshit interface

when I realized what OOP backwards spells

Lotsa ISomethingable and duck typing is the best way.

OOL NI OOP!!!

I'm sure you know more about big projects than Mike Acton :)

#define private public
#define protected public
Thank me later.

Found it! codeofhonor.com/blog/tough-times-on-the-road-to-starcraft

Well it is Pure Object Oriented Programming, better known by its acronym

You can't. That's my point.

You can't.

You can VERY LOOSELY think of a module as a class with only static members that can't be initialized into an object. They're more powerful than, say, a namespace in C++, though, because they can be used to encapsulate as well. Languages like OCaml have metaprogramming with modules too, but I won't get into that.

Java pleb here again

How do other languages organize modules, aside from classes?

What do you mean ``organize''? A module is usually just a file hidden from outside world and you specify what to export(show to the outside world) from it.
Check Haskell, ELM, Python, even JS has them now.

structs?

Because he's using his job to lend weight to his point.

Kek, you're right. Also BullshitChangeListener

I said "organize" but it just as well could have been create, implement, etc, I'm sure you get the picture.

That makes more sense now, I think I get your OP. Java forces modules to dress as classes whether it really is necessary or not. I can understand why that is a disadvantage

Yeah fuck OOP so much.

I'm doing an employee management system for school. This MVC shit is a mess.

Yes, that's what I meant. I also leads to one-method ``doer'' classes, like MessageSender, BullshitDoer, onShitHappennedListener which shouldn't be classes in the first place.

Condolences, bro. I like how the industry is just trying to patch this OOP bullshit with patterns, which only makes it worse, instead of just acknowledging the fact that the King is naked.

That's more a failure of nominal typing vs. structural typing. Interfaces are really just types, and an object that "implements" the interface inhabits the type (with its full type as a subtype of the interface). Just look at how OCaml does its OOP.

I've made classes like that too many times to count. I thought the single-method megaclasses from our Panjeets were bad, but now I realize my code is shit too. I think you just redpilled me on my choice of language and by extension the basis of my career

No, I meant like classes-classes, not interfaces. How many times did you find yourself doing something like:

>BullshitDoer bullshitDoer = new Bullshit()
>bullshitDoer.doBullshit()

That's what I call one-method ``doer'' classes.

Oh, I see. Yeah, the fact that Java has lambdas but you still have to use them with "functional interfaces" is just silly.

this

Try Haskell, Erlang, Elixir. If it's too unusual try ELM, it's like Haskell-lite.
But those languages are virtually unemployable, you'll have to write/maintain OOP for a living and wait about 5-10 years until FP becomes the mainstream for the industry.
You can decrease the entropy by opting for the FP paradigm instead of OOP paradigm if you're writing in a multi-paradigm language. You can even do FP in JS, lol.
I Java, though, it's either OOP or procedural programming, some people told me even procedural programming is better than OOP, but I'm not that sure.

Interesting read I guess

A python module is basically just an object, and every variable defined in the module becomes an attribute of that object.
However, a module can find its own entry in sys.modules and replace that with an object of its choosing, allowing a module to expose itself as something other than a module.
In NodeJS, you have to manually export stuff, by stuffing it into module.exports.

>OOP
>Literally poo spelled backwards
I still struggle to find a practical use for it.
Are there even any?

Did you even read the article? He was complaining about the implementation

Yes, I've read it, but it was a long time ago.

Looking over it he doesn't sound like he is complaining about oop, but how the teams implemented inheritance.

I do C, mainly C++, and little C# at my job working with backend and custom raid servers, coming from a C only background. The company is very strict about how we code and I feel the C++ is very well done and have few complaints about oop. This is purely anecdotal of course

Yes, I know, but he describes a lot of OOP related problems, only that he offers workarounds instead of just trashing OOP altogether. He didn't take the red pill, obviously.

this

But that's a good thing. What if you want to change the implementation of doBullshit()? If you don't have a class, you'd have to replace every single call to it in every single class that uses it. With a Bullshitter class, you just change a few lines in that class and every class that uses a Bullshitter will use the new implementation.

What if you add new arguments to Bullshiter constructor? Or to the doBullshit method?

the new constructor is easy. Just add a second constructor, and modify the original constructor to call the second constructor with a default value for the new argument.

The new doBullshitter is more difficult. I can't think of a solution - but it'll still take about as much work to change as it would if you had that method implemented in each class that uses it. Maybe even less, depending on how complex the implementation is.

>you had that method implemented in each class that uses it
Who the fuck said anything about implementing it in each class that uses it?

If you don't have a separate class for it, where else are you going to implement it?