The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025
Posted by esiy0676@reddit | programming | View on Reddit | 44 comments
Posted by esiy0676@reddit | programming | View on Reddit | 44 comments
SauntTaunga@reddit
Did not watch the video, but does it focus mainly on overuse of inheritance? Because that is maybe the least useful feature of OOP. I’d say encapsulation is the most useful.
lelanthran@reddit
How is encapsulation a feature of OOP? That's like tyres are a feature of SUVs - you're ignoring that almost all other road vehicles also have tyres.
It's hard for something to be a feature when it's standard on every item in its class!
SauntTaunga@reddit
When I learnt about it, way back when OOP was the hip new thing, the 4 fundamental principles of OOP are encapsulation, abstraction, inheritance, and polymorphism. This was when Smaltalk was the big example and C++ and Objective-C were new. The commonly used languages back then Pascal, C, BASIC (aaaa!) had none of these features. Yes, there were a few niche, now forgotten, languages that did not use them all, like ADA and Modula. Mostly we did not use "road vehicles", we dragged sleds around.
lelanthran@reddit
Both Pascal and C had encapsulation. Basic and COBOL did not, though.
SauntTaunga@reddit
In C you could do something a bit like encapsulation in C yes. You can put function pointers in a struct. Functions would be defined elsewhere outside the struct’s scope so you would have to invent some naming convention to associate them with the struct and need an explicit instance pointer. It’s pretty clunky.
I struggle to see how you could make it work in the original Pascal, you could pass functions as function parameters, but function variables or record members were not possible. Of course Object Pascal and Delphi had it.
lelanthran@reddit
C had it, you didn't have to "bring it". Strong encapsulation was there since C89: It's a common myth.
Pascal was used to teach encapsulation, via Abstract Data Types. This part of my university curriculum in 1995, in a module called
Abstract Data Types.They didn't have objects, but they certainly had encapsulation, and strong typing on those created types.
They still do.
SauntTaunga@reddit
I wondered about his
Googled and found this on a UCSD page.
Yes, they still tried to teach it using Pascal, because what else are you going to do in 95.
lelanthran@reddit
Instead of citing a source that you cannot link to, here is an actual peer-reviewed paper from 1989 that says:
So, yeah, encapsulation was table stakes for languages prior to OO getting popular, was taught using Pascal, was available in a stronger form in C than many modern languages... since the 80s.
You can disagree all you want, but peer-reviewed papers beats your "I reade it somewhere but I can't give you a link".
SauntTaunga@reddit
Turbo Pascal is not Pascal. It’s one of several proprietary non-standards, easy to leaning for those already familiar with Pascal, that has fixes for some of Pascal’s many shortcomings, like full support for OOP or encapsulation.
The inventor of Pascal did not propose fixes to it, he designed Modula and Simula instead.
My quote was from here:
https://cseweb.ucsd.edu/~savitch/books/pascal/adts.html
SauntTaunga@reddit
ADTs are weak encapsulation. What do you imagine amounts to "strong encapsulation" in C89?
lelanthran@reddit
Who said anything about strong encapsulation vs weak encapsulation; I just wanted to point out that encapsulation is not a feature specific to OO languages, and has not been since at least the mid-80s. Other than BASIC, almost all languages since the start of my career (mid 90s, sometime) had encapsulation.
The opaque datatype is a stronger encapsulation than C++ classes; the fields within an opaque datatype are completely invisible to the human user because the fields in the struct only exist within the implementation, not in the header.
In C++, even private fields are visible to the user of the encapsulation, because the encapsulation is defined in the header file, not the implementation.
SauntTaunga@reddit
Access specifiers are not enough for "strong encapsulation", neither are ADTs.
cdb_11@reddit
No. It's about the history of OOP. And the actual take of the speaker is where exactly do you draw the lines dividing objects.
azhder@reddit
I can’t remember everything, saw it a while back, but it’s not what you expect it to be. Inheritance and encapsulation are both concepts orthogonal to OOP and you can use them without OOP.
SauntTaunga@reddit
Turbo Pascal is not Pascal. It’s one of several proprietary non-standards that has fixes for some of Pascal’s many shortcomings, like full support for OOP or encapsulation.
My quote was from here:
https://cseweb.ucsd.edu/~savitch/books/pascal/adts.html
Zilka@reddit
I didn't understand the example with shapes and how its bad because we will need a switch statement when drawing them. Ofcourse we won't. Every shape should know how to draw itself. Then when we need to draw all the shapes we just treat them as (superclass) shapes and then each shape just correctly draws itself thanks to method override/inheritance/polymorphism.
I successfully used this approach to make a whole game and it worked just fine.
Dminik@reddit
I find this take interesting. You say that a shape should know how to draw itself like it's the only possibility.
But, why should a rectangle understand anything about say Vulkan buffers and shaders. Is this really the right way to abstract data and behaviours?
Zilka@reddit
I just didn't like that his example involved the switch statement as something inevitable.
As for your point, I'd say it depends where more complexity lies. In my case most of the complexity came from geometry, rotation calculations, etc. So it was convenient to be right where the state of the shape/object was. Plus I was able to double dip when I did a similar thing with update loop(cycle). As for drawing complexity, pass paint and canvas, and then call various draw, path, setColor, etc methods. I even had dynamic shading based on gyroscope readings.
If I start working working on a project where most of the complexity lies with manipulating GPU and complexity of manipulating shape/object state(vertices, rotation,shading) pales in comparison, I will likely use a different approach.
No, I only said I disagree with his argument that you will need a switch statement when drawing shapes hierarchy.
It's more than just a rectangle. Its a game object with behavior, momentum, hitpoints etc.
Dminik@reddit
I think going with an OOP style like that has some interesting implications.
You start with some pretty simple stuff. Each entity needs to know how to update itself and draw itself. Then, there might be collisions. And then each entity needs to know how to take and deal damage. And then each entity needs to know how to parhfind, and then ...
And in games, you usually only work with the base Entity. Your update loop doesn't really know which entity is which. So the base class bubbles and grows.
The end result usually ends up with a god base class which knows how to do everything. Really, an opposite of what good OOP classes should be.
Obviously, I can't speak for Casey, but my impression wasn't that you will inevitably end up with a switch.
That being said, I think that the switch example is still OOP, even if you don't use inheritance (or encapsulation, or whatever). This may not be received the best, but I feel that mistake people make (including me) is forcing a design of a system, where there are distinct things, which interact with each other.
It's very intuitive way to design and think about stuff, but it tends to break down once you discover that these things weren't that distinct after all. It's not quite how the real world works either.
azhder@reddit
Once in a while, this video pops up. Let's see if and what kind of discussions it will bring.
Gooeyy@reddit
What kind of bot comment is this
hurbunculitis@reddit
It's a legitimate observation, and is true. What registers as "bot comment" about that to you?
Gooeyy@reddit
You used 19 words to say nothing
ChemicalRascal@reddit
Bro if you think they said nothing you need to work on your reading comprehension
Gooeyy@reddit
Enlighten me - how did it contribute to meaningful discussion?
stanpascal@reddit
What have you done to contribute to discussion?
Gooeyy@reddit
I rest my case
stanpascal@reddit
I accept your concession.
SauntTaunga@reddit
It has its uses. Don’t go overboard.
lelanthran@reddit
Well, yeah. The poison is the dosage, not the substance.
Even water will kill you at specific doses.
sidneyc@reddit
Words to live by.
AlternativePaint6@reddit
I hate straw man talks like this. He's nitpicking bad examples from individual sources and using that to highlight how all of OOP is bad. I don't care if OOP is bad or not, but this is not how you discuss it.
One of the examples he used was something along the lines of:
Like, what are we even talking here? This code does not actually tell us anything about any real world OOP example. What is "Special Iron Man" class supposed to be? This is not a realistic example we can analyze for mistakes.
alfguys@reddit
I teach CS and one of my ongoing annoyances with the College Board’s stubborn commitment to Java is exactly due to code like this. It’s contrived and requires a lot of syntax for minimal payoff. I know Java, and OOP, can be very powerful, just not within the scope of a high school classroom.
I think in turn this leads to takes like the one above. As people have been saying here, OOP is a tool like any other and knowing when to deploy it is a skill in and of itself. There is unfortunately a lot of cs education/training that just focuses on one language.
Blue_Moon_Lake@reddit
Remind me of my own time getting CS degree.
They could have taught us C++, but no... had to be dead languages like Pascal because the teacher had not dusted his knowledge for 30 years.
cdb_11@reddit
The talk is about the history of OOP, influential sources from decades ago is literally the entire point.
It's been a while since I've watched it, but I do believe he specifically said that "all OOP bad" isn't necessarily what he means. Maybe next time try to actually listen to what the person has to say before commenting on it.
Blue_Moon_Lake@reddit
If FP dominated and as many bad devs had done decades of trash code with FP instead of OOP, we would have hours long video about FP being trash.
To everyone:
OOP, FP, they're tools. Use the right one without commiting to using only that one.
You don't use a hammer for both nails and screws, you switch between tools to build what you need.
EliSka93@reddit
In the real world, a mix of both is perfectly fine.
In .Net I use OOP a lot but I would hate not having the FP based LINQ.
read_at_own_risk@reddit
But can we articulate what the right use cases for OOP are and how it should be applied?
In my experience, OOP works well for building state machines and creating computational abstractions. It sucks when used to model a business domain when you're building anything other than a simulation, and it sucks doubly when used to model a taxonomy. I build information systems, and my rule of thumb is that class names should consist of a noun and a computational verb (e.g. EmployeeInserter, PayslipRenderer, etc) to define a valid use case and responsibility.
bytesbits@reddit
I think he is a game developer
lIIllIIlllIIllIIl@reddit
I do believe it's important to disprove the idea that OOP was "discovered" because it is the natural best way to write software and every other paradigm is flawed and doesn't scale in large-scale serious enterprise™ codebases.
OOP is just ideas that a few guys cobbled together for a bunch of different reasons.
Once you "de-mythify" the origins of OOP, it's a lot harder to justify doing things the OOP-way over other methods.
I never understood people who religiously exercise OOP, but they do exist.
GoTheFuckToBed@reddit
sad that Casey has adopted the angry men persona, instead of teacher with his handmade project
Skriblos@reddit
How has he adopted the angryman persona?
Frolo_NA@reddit
As always its because he didn’t see it in smalltalk before c++
klavijaturista@reddit
OOP has its place. Everything has it's place if applied judiciously. The problem is, people act religiously and self-righteous (patterns and solid), add layers and layers of abstractions to fix the previous abstraction, and just shovel code and fail to improve. It doesn't depend on the paradigm - every single paradigm will be misused. It only depends on the programmer being wise. And, in corporations, having authority to force decisions on the team of self-righteous, zealous coders.