7 ms·

> Please, try not to be too dismissive to the things you do not understand. I never said it's impossible to do method polymorphism in C, I said nowhere in that

> Please, try not to be too dismissive to the things you do not understand. I never said it's impossible to do method polymorphism in C, I said nowhere in that article method polymorphism is implemented. You obviously did not read what I wrote at first place, only saw what you wanted to see to make some kind of (bad) rebuttal without a single concrete implementation as an example. Of course it's possible to implement method polymorphism in C, which is what I said, the article linked isn't doing that anywhere, quite the opposite. So no, C structs are not equivalent to Java classes, at all.

kitd 4y ago
I said nowhere in that article method polymorphism is implemented. Well, not quite. You said that it isn't OOP without method polymorphism. So no need to fly off the handle and accuse others of misreading something you didn't write.
- throw_m239339 4y ago
  > Well, not quite. You said that it isn't OOP without method polymorphism. So no need to fly off the handle and accuse others of misreading something you didn't write. I said > This isn't OO until you implement some form of method polymorphism. which means the article didn't implement method polymorphism. > So no need to fly off the handle and accuse others of misreading something you didn't write. So you need to pay attention at first place instead of "flying off the handle" yourself and then accusing others to do so in a useless comment.
lll-o-lll 4y ago
Yes, the article is terrible as it does not show any polymorphism. Also, yes, doing genuine polymorphic OO in C ends up horrible because you invent a new language. (Source: many years working on a truely evil code-base of OO C. Originally the work of one twisted genius. Brilliant, but evil). OO was just a failed paradigm anyway, I’m amazed anyone would try and shoe-horn it into C in the modern day.
- isityouyesitsme 4y ago
  I don't think OOP has failed at all. It has become the foundation of all reusable code in every language. What failed was the idea that internal state can be managed and shared with derived classes. The key to OOP is extracting the idea of types/concepts into interfaces that may have different implementations. You don't even need a language that supports polymorphism as a first-class concept in order to do this, though it is certainly much safer. Python chooses duck typing, modern C++ uses "concepts," etc. You can do SOLID under any of this. Some languages or frameworks take it too far and think of everything as an instance of a base object, for no great reason. I guess a summary of my thesis is that the "L" in SOLID is what makes an architecture OOP.
  - lll-o-lll 4y ago
    Eh, this is a very separate debate. You don’t need OO for modularity. This should be obvious. You need an API/Contract and for re-use you need a “module” (such as a dll or a web interface). For example something like: int CreateTheStatefulThing(blah* thing); DoStuffWithThing(blah* thing); void CleanUpThing(blah* thing); To suggest OOP is the foundation of reusable code is simply wrong.
    - isityouyesitsme 4y ago
      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.

kitd 4y ago

I said nowhere in that article method polymorphism is implemented. Well, not quite. You said that it isn't OOP without method polymorphism. So no need to fly off the handle and accuse others of misreading something you didn't write.

throw_m239339 4y ago
> Well, not quite. You said that it isn't OOP without method polymorphism. So no need to fly off the handle and accuse others of misreading something you didn't write. I said > This isn't OO until you implement some form of method polymorphism. which means the article didn't implement method polymorphism. > So no need to fly off the handle and accuse others of misreading something you didn't write. So you need to pay attention at first place instead of "flying off the handle" yourself and then accusing others to do so in a useless comment.

lll-o-lll 4y ago

Yes, the article is terrible as it does not show any polymorphism. Also, yes, doing genuine polymorphic OO in C ends up horrible because you invent a new language. (Source: many years working on a truely evil code-base of OO C. Originally the work of one twisted genius. Brilliant, but evil). OO was just a failed paradigm anyway, I’m amazed anyone would try and shoe-horn it into C in the modern day.

isityouyesitsme 4y ago
I don't think OOP has failed at all. It has become the foundation of all reusable code in every language. What failed was the idea that internal state can be managed and shared with derived classes. The key to OOP is extracting the idea of types/concepts into interfaces that may have different implementations. You don't even need a language that supports polymorphism as a first-class concept in order to do this, though it is certainly much safer. Python chooses duck typing, modern C++ uses "concepts," etc. You can do SOLID under any of this. Some languages or frameworks take it too far and think of everything as an instance of a base object, for no great reason. I guess a summary of my thesis is that the "L" in SOLID is what makes an architecture OOP.
- lll-o-lll 4y ago
  Eh, this is a very separate debate. You don’t need OO for modularity. This should be obvious. You need an API/Contract and for re-use you need a “module” (such as a dll or a web interface). For example something like: int CreateTheStatefulThing(blah* thing); DoStuffWithThing(blah* thing); void CleanUpThing(blah* thing); To suggest OOP is the foundation of reusable code is simply wrong.
  - isityouyesitsme 4y ago
    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.