3 ms·

People forget what the intent of OOP originally was. OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't ha

by urthor 5y ago

People forget what the intent of OOP originally was. OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't have half the tools for hiding context that we do now. Micro-services and micro-kernels are far far far more prevalent these days. Garbage collection was also far less of a thing in that era, as all programmers were squeezing every last iota out of the hardware. Hence rogue pointers were far more of a risk. Multi-core? Haha. I know this is not particularly relevant to the original article, but if you don't know the history and the intent behind why something exists, you are reasonably likely to misapply it. Most of the mistakes of OOP are from a lack of understanding of why things got invented in the first place.

beders 5y ago
The original intent had nothing to do with "many contributors". The main ideas: encapsulation, message passing and late binding i.e. dynamic binding.
- Zababa 5y ago
  You're talking about solutions when they were talking about problems. What problems does encapsulation, message passing and late binding solve?
BoiledCabbage 5y ago
Also, the article does a really poor job of describing any drawbacks of Data Oriented Design. It's a real pet-peeve of mine. > Drawbacks of Data-Oriented Design Data-oriented design is not the silver bullet to all the problems in game development. Ok, they don't view it as a silver bullet. This seems promising for an evenhanded discussion. I'm curious what the author thinks the drawbacks are. > The main problem with data-oriented design is that it’s different from what most programmers are used to or learned in school. So the first drawback is that nobody knows your silver-bullet? That's a cop out. > Also, because it’s a different approach, it can be challenging to interface with existing code, written in a more OOP or procedural way. And the second drawback is that code was written without using your silver-bullet? Seriously? If the only two things you believe are drawbacks about your tech are that not enough people know it, and not enough people are using it then it's not an even handed discussion of your tech. Discuss the actual trade-offs you've learned from using it. Not nonsense like nobody knows how wonderful it is, nor is using it. And that's coming from someone who agrees that OOP has huge flaws and with the most common applications of inheritance creates many flawed program architectures.
Zababa 5y ago
> OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't have half the tools for hiding context that we do now. > Micro-services and micro-kernels are far far far more prevalent these days. I think that's a good analysis. If OOP was a solution to an organization problem, then microservices are the "new" way to do it. Microservices respect late binding, message passing, encapsulation. I don't really know how inheritence would fit into the equation, as I don't know exactly how companies with hundreds of microservices do it. And since we don't care about what's inside the objects (services), we're now free to write them in Java, C++, Smalltalk, Erlang, Haskell or Pascal.
AdieuToLogic 5y ago
> People forget what the intent of OOP originally was. Not really. > OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't have half the tools for hiding context that we do now. No, the purpose of "OOP" is specifically for "hiding context" by encapsulating implementation logic exposed via a collaboration contract. > Micro-services and micro-kernels are far far far more prevalent these days. Non-sequitur. > Garbage collection was also far less of a thing in that era, as all programmers were squeezing every last iota out of the hardware. This literally has nothing to do with a programming paradigm. > Hence rogue pointers were far more of a risk. > Multi-core? Haha Again, this literally has nothing to do with a programming paradigm. > I know this is not particularly relevant to the original article, but if you don't know the history and the intent behind why something exists, you are reasonably likely to misapply it. This is a wise statement, one which I hope you say aloud whilst reading this reply. > Most of the mistakes of OOP are from a lack of understanding of why things got invented in the first place. A programming paradigm is not the source of mistakes. Its practitioners certainly can be however.

by urthor 5y ago

beders 5y ago

The original intent had nothing to do with "many contributors". The main ideas: encapsulation, message passing and late binding i.e. dynamic binding.

Zababa 5y ago
You're talking about solutions when they were talking about problems. What problems does encapsulation, message passing and late binding solve?

BoiledCabbage 5y ago

Also, the article does a really poor job of describing any drawbacks of Data Oriented Design. It's a real pet-peeve of mine. > Drawbacks of Data-Oriented Design Data-oriented design is not the silver bullet to all the problems in game development. Ok, they don't view it as a silver bullet. This seems promising for an evenhanded discussion. I'm curious what the author thinks the drawbacks are. > The main problem with data-oriented design is that it’s different from what most programmers are used to or learned in school. So the first drawback is that nobody knows your silver-bullet? That's a cop out. > Also, because it’s a different approach, it can be challenging to interface with existing code, written in a more OOP or procedural way. And the second drawback is that code was written without using your silver-bullet? Seriously? If the only two things you believe are drawbacks about your tech are that not enough people know it, and not enough people are using it then it's not an even handed discussion of your tech. Discuss the actual trade-offs you've learned from using it. Not nonsense like nobody knows how wonderful it is, nor is using it. And that's coming from someone who agrees that OOP has huge flaws and with the most common applications of inheritance creates many flawed program architectures.

Zababa 5y ago

> OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't have half the tools for hiding context that we do now. > Micro-services and micro-kernels are far far far more prevalent these days. I think that's a good analysis. If OOP was a solution to an organization problem, then microservices are the "new" way to do it. Microservices respect late binding, message passing, encapsulation. I don't really know how inheritence would fit into the equation, as I don't know exactly how companies with hundreds of microservices do it. And since we don't care about what's inside the objects (services), we're now free to write them in Java, C++, Smalltalk, Erlang, Haskell or Pascal.

AdieuToLogic 5y ago

> People forget what the intent of OOP originally was. Not really. > OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't have half the tools for hiding context that we do now. No, the purpose of "OOP" is specifically for "hiding context" by encapsulating implementation logic exposed via a collaboration contract. > Micro-services and micro-kernels are far far far more prevalent these days. Non-sequitur. > Garbage collection was also far less of a thing in that era, as all programmers were squeezing every last iota out of the hardware. This literally has nothing to do with a programming paradigm. > Hence rogue pointers were far more of a risk. > Multi-core? Haha Again, this literally has nothing to do with a programming paradigm. > I know this is not particularly relevant to the original article, but if you don't know the history and the intent behind why something exists, you are reasonably likely to misapply it. This is a wise statement, one which I hope you say aloud whilst reading this reply. > Most of the mistakes of OOP are from a lack of understanding of why things got invented in the first place. A programming paradigm is not the source of mistakes. Its practitioners certainly can be however.