3 ms·

You are reading in to what I wrote something I did not say. I said that "OOP has become the foundation," not "OOP is the foundation." There is a very big, hist

You are reading in to what I wrote something I did not say. I said that "OOP has become the foundation," not "OOP is the foundation." There is a very big, historical, fact-based distinction between those two statements. Modularity and reuse are completely different things. A highly modular codebase is more amenable to write reusable code, but many modular systems have been written with very little concept and code reuse. Of course there was a measure of reusable code before OOP was a more formalized language for discussing it. But to say "you can do these things without OOP" is like saying you don't need structured programming to write maintainable systems. And it's like "ok, but you're still using "if," possibly "return," and you know... functions." Essentially the exact same ideas that the paradigm gave formal language to. I think people who say that OOP wasn't responsible for the understanding of modern paradigms haven't read much of the theory behind it and have hyper focused on the poor series of books and articles that came out from the 1980s through about 2010 that encouraged hidden state ownership and inheritance of state.

lll-o-lll 4y ago
Anyone who disagrees with you is simply poorly read and uninformed? You cannot separate theory and practice in the way you are attempting to. It’s not just “bad books” that lead to the abuse of inheritance that is so familiar, there were (and are) broken concepts that only became visible with time. I highlighted “module” for a reason, because one of the key mistakes of practitioners was to view the element of re-use as the “class”. In reality if we want to create a reusable component the boundary is much higher. We create an api and a library or some other component that can be distributed. Building a reusable component is much more work, and recognising when that is necessary and designing accordingly is an important engineering discipline. To finish with a snipe of my own; I think people who take an OOP is primary view of the world need to do a little more programming in lisp to properly understand the fundamentals.
- isityouyesitsme 4y ago
  Your straw men fall easily. But your "snipe" doesn't even apply. I spent the two years of my masters program editing a NASA-owned LISP codebase. it wasn't huge. Maybe 100kloc. But I'm definitely not ignorant or LISP. Look, you don't like OOP, who cares? I certainly don't. But that's different than trying to explain that you have a fundamental misunderstanding. Whether you accept it or not, it's in your head now ;)
  - lll-o-lll 4y ago
    I’m too old and tired for the insult slinging anyway. What’s my fundamental misunderstanding? What’s the straw man? Class == re-use? I don’t hate OO by the way, it’s just not the first, only, or in my opinion best way to think about or structure code. I do think the expectations that OO would bring increased productivity, code-reuse, etc were not realised and hence why I referred to it as a “failed paradigm”. Not because it is bad from a theory perspective, but because in practice none/few of the things it was expected to deliver actually materialised. And also that the real challenges with “code reuse” are different. I have read the bad books, but also the good books. I’ve done more OOP programming than anything else over my career, and it can be done well. I’ve also worked with and coded in extremely well written C code bases. I just can’t see the value that OOP provided over modular C. Perhaps you can enlighten me?
    - isityouyesitsme 4y ago
      I can agree with a lot of what you wrote, and especially outcome vs. the original OOP promises. They meant one thing, and it turned out that thing is actually an anti pattern (inheriting implementations and state, not merely inheriting interfaces), but then they also delivered on what they said, just in a different way. Example: "we will have reusable code!" What they meant was deep inheritance hierarchies where children just inherit their parent code and selectively override parts of it. What was delivered instead was a set of principles using the vocabulary of OOP to guide developers into designing interfaces that are highly reusable (SOLID). In terms of what this adds to C, I can only suggest that you study a large C project. I'd recommend the Linux kernel. You won't find first-class support for inheritance and polymorphism, but it's there. It is amazing how modifiable and extensible entire subsystems are, and when you examine it, you find the SOLID principles at work, which came from OOP study and practice. I don't really understand what you mean by the way OOP is "structured." If you're referring to deep object hierarchies like Java or Qt, I don't really disagree. They attempt to force an architectural unity through object hierarchies. But then on the other hand, if you're saying that it isn't helpful to contemplate an architecture through the lense of types, the types of transformations and operations that can be performed on them, and packaging these operators and transformers into a group that can be passed to code that calls them abstractly, then I don't agree. Amusingly, I don't think that second thing is what you're saying. But with your arguing against OOP, I don't really know how to interpret this. This is what OOP gave us language to describe. Of course some of these techniques existed before in LISP or C, but code bases of the day were largely NOT leveraging them in any large scale way. OOP gave us vocabulary for these concepts, as well as mainstreamed their use, similar to how functional programming mainstreamed the idea that a nonlinear or cyclic graph of executable functions must not allow shared state, even if hidden within objects, if you want to be able to maintain that code long term, and extend it. So it seems like you're arguing that OOP is bad, while neglecting the history that OOP brought us the common understanding of how modules should interact with each other.

lll-o-lll 4y ago

Anyone who disagrees with you is simply poorly read and uninformed? You cannot separate theory and practice in the way you are attempting to. It’s not just “bad books” that lead to the abuse of inheritance that is so familiar, there were (and are) broken concepts that only became visible with time. I highlighted “module” for a reason, because one of the key mistakes of practitioners was to view the element of re-use as the “class”. In reality if we want to create a reusable component the boundary is much higher. We create an api and a library or some other component that can be distributed. Building a reusable component is much more work, and recognising when that is necessary and designing accordingly is an important engineering discipline. To finish with a snipe of my own; I think people who take an OOP is primary view of the world need to do a little more programming in lisp to properly understand the fundamentals.

isityouyesitsme 4y ago
Your straw men fall easily. But your "snipe" doesn't even apply. I spent the two years of my masters program editing a NASA-owned LISP codebase. it wasn't huge. Maybe 100kloc. But I'm definitely not ignorant or LISP. Look, you don't like OOP, who cares? I certainly don't. But that's different than trying to explain that you have a fundamental misunderstanding. Whether you accept it or not, it's in your head now ;)
- lll-o-lll 4y ago
  I’m too old and tired for the insult slinging anyway. What’s my fundamental misunderstanding? What’s the straw man? Class == re-use? I don’t hate OO by the way, it’s just not the first, only, or in my opinion best way to think about or structure code. I do think the expectations that OO would bring increased productivity, code-reuse, etc were not realised and hence why I referred to it as a “failed paradigm”. Not because it is bad from a theory perspective, but because in practice none/few of the things it was expected to deliver actually materialised. And also that the real challenges with “code reuse” are different. I have read the bad books, but also the good books. I’ve done more OOP programming than anything else over my career, and it can be done well. I’ve also worked with and coded in extremely well written C code bases. I just can’t see the value that OOP provided over modular C. Perhaps you can enlighten me?
  - isityouyesitsme 4y ago
    I can agree with a lot of what you wrote, and especially outcome vs. the original OOP promises. They meant one thing, and it turned out that thing is actually an anti pattern (inheriting implementations and state, not merely inheriting interfaces), but then they also delivered on what they said, just in a different way. Example: "we will have reusable code!" What they meant was deep inheritance hierarchies where children just inherit their parent code and selectively override parts of it. What was delivered instead was a set of principles using the vocabulary of OOP to guide developers into designing interfaces that are highly reusable (SOLID). In terms of what this adds to C, I can only suggest that you study a large C project. I'd recommend the Linux kernel. You won't find first-class support for inheritance and polymorphism, but it's there. It is amazing how modifiable and extensible entire subsystems are, and when you examine it, you find the SOLID principles at work, which came from OOP study and practice. I don't really understand what you mean by the way OOP is "structured." If you're referring to deep object hierarchies like Java or Qt, I don't really disagree. They attempt to force an architectural unity through object hierarchies. But then on the other hand, if you're saying that it isn't helpful to contemplate an architecture through the lense of types, the types of transformations and operations that can be performed on them, and packaging these operators and transformers into a group that can be passed to code that calls them abstractly, then I don't agree. Amusingly, I don't think that second thing is what you're saying. But with your arguing against OOP, I don't really know how to interpret this. This is what OOP gave us language to describe. Of course some of these techniques existed before in LISP or C, but code bases of the day were largely NOT leveraging them in any large scale way. OOP gave us vocabulary for these concepts, as well as mainstreamed their use, similar to how functional programming mainstreamed the idea that a nonlinear or cyclic graph of executable functions must not allow shared state, even if hidden within objects, if you want to be able to maintain that code long term, and extend it. So it seems like you're arguing that OOP is bad, while neglecting the history that OOP brought us the common understanding of how modules should interact with each other.