The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025

[-]

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

Because that is maybe the least useful feature of OOP. I’d say encapsulation is the most useful.

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!

[-]

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

In C you could do something a bit like encapsulation in C yes. Early C++ compilers generated C, so obviously it’s possible. C didn’t "have" it, you could bring it with you.

C had it, you didn't have to "bring it". Strong encapsulation was there since C89: It's a common myth.

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.

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

Pascal was used to teach encapsulation, via Abstract Data Types. This was literally part of my university curriculum in 1995, in a module called Abstract Data Types.

Googled and found this on a UCSD page.

One of the shortcomings of standard Pascal is that most standard Pascal compilers do not have built in facilities for defining Abstract Data Types (ADTs) in a way that uses accepted principles of information hiding. …

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:

"Turbo Pascal has features which make it a good tool for introducing important concepts in CS1 and CS2 classes. These concepts include procedural and data abstraction, information hiding and data encapsulation."

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

ADTs are weak encapsulation. What do you imagine amounts to "strong encapsulation" in C89?

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.

You say that a shape should know how to draw itself like it's the only possibility.

No, I only said I disagree with his argument that you will need a switch statement when drawing shapes hierarchy.

But, why should a rectangle understand anything about say Vulkan buffers and shaders.

It's more than just a rectangle. Its a game object with behavior, momentum, hitpoints etc.

[-]

Dminik@reddit

It's more than just a rectangle. Its a game object with behavior, momentum, hitpoints etc.

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.

I just didn't like that his example involved the switch statement as something inevitable.

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 has its uses. Don’t go overboard.

[-]

lelanthran@reddit

It has its uses. Don’t go overboard.

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:

class IronMan {
  constructor(...) {
    this.name = ...
  }
}

class SpecialIronMan extends IronMan {
  constructor(...) {
    super(...)
    this.extraAbility = ...
  }
}

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

Nitpicking bad OOP examples from individual sources (some from decades ago)

The talk is about the history of OOP, influential sources from decades ago is literally the entire point.

using that to highlight how apparently all of OOP is bad

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?

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.