3 ms·
Perhaps your request for clarification was added after I replied, or perhaps I just missed it. Charity urges me to accept the fault as mine, so please accept my
by dventimihasura 3y ago
Perhaps your request for clarification was added after I replied, or perhaps I just missed it. Charity urges me to accept the fault as mine, so please accept my apology for overlooking what surely could not have been an after the fact revision. In any case, what I was saying was that in my experience, often OOP is applied where it isn't suited, particularly in the application layer between a client and a relational database, and this is the source of much of the criticism of OOP which the OP is trying to deflect. In that case, it isn't OOP critics who don't understand OOP, but rather OOP practitioners who don't understand OOP well enough to know when not to use it. I believe a close reading of my comment reveals that this is what I was saying, so that a clarification isn't strictly needed though it's happily provided.
- randomdata 3y ago> often OOP is applied where it isn't suited, particularly in the application layer between a client and a relational database What it is about the OOP paradigm that you find does not fit this client->relational database application? The idea behind OOP is that you send a message out into the world, and maybe another actor can make something of it. You don't really know or care about the other actors are out there. If an actor hides a relational database behind closed doors, so be it. Not your problem. That's outside of the concern of OOP. On the flip side, we have active record, which imagines a way to try and marry relational databases to an object-based (not oriented) model. Here you will regularly find criticism about "impedance mismatch" and where things like constraints should be handled. This still reads like what you are talking about, but has little to do with OOP. Conceivably you could use that pattern to implement the local retention of an actor. Is that where you find applicability to OOP? OOP doesn't speak to the underlying actor implementation, though. It purposefully doesn't speak to the implementation as not having knowledge of actors is kind of OOP's whole deal. If you need to know things about other actors, you can't just throw a message out there. Because of the similar names, those who don't understand OOP oftentimes confuse it with object-based programming. Perhaps this is what you are trying to speak to, using a 'database layer' as an example of object-based programming as seen in the wild? Admittedly, I still don't fully understand the link you are making between relational databases and OOP.
- dventimihasura 3y ago> What it is about the OOP paradigm that you find does not fit this client->relational database application? It's not me who finds that OOP is a mismatch with relational systems. It's me and many other people. Ted Neward talked about this 20 years ago. Jeff Atwood talked about it 18 years ago. Martin Fowler defended OOP from this criticism but at least he also talked about it, 12 years ago. There's a Wikipedia page on the subject and many related articles over the years. This is well-trod ground. Now. Does this mean we critics are right? No. It doesn't mean that. It means that this is well-trod ground. It is the topic of a healthy debate that generates one line of criticism of OOP. Functional programming--which I haven't mentioned in this thread until now--is another source of OOP criticism. What's interesting to me at this particular moment is not the substance of these debates ("is the object-relation impedance mismatch real? is mutable state really bad?") or who's right. What's interesting to me is that author of Sigma's Blog doesn't address any of this. I claim that these two topics--the ostensible object-relational impedance mismatch and the mutable state bugaboo of functional programming--are of such primary importance in generating criticism of OOP that any author who sets out to defend OOP from its critics must address these topics in order to be taken seriously. And yet, all this author says is It seems like a lot of people dislike Object Oriented Programming They don't say who these people are, what their reasons are for disliking OOP, or why things seem this way to the author. They just accuse unnamed "people" of not understanding OOP and then dive into a bog-standard description of OOP which is well-understood by all the relevant programmers that I know. None of that answers your questions on the topic of the object-relational mismatch, of course, but then I never promised to explain that topic to you. I might, but then again I might not. If I don't, there are plenty of resources online that you can study for yourself. If you form a killer argument that addresses all issues once and for all, perhaps you should write your own blog post. Surely such a groundbreaking achievement would be worthy of making it all the way to the front page.
- randomdata 3y ago> It's not me who finds that OOP is a mismatch with relational systems. It's me and many other people. Great, but what is the mismatch you speak of? > Ted Neward talked about this 20 years ago. Jeff Atwood talked about it 18 years ago. Are you referring to the "The Vietnam of Computer Science"? It is about active record and object/relational mapping. OOP, despite the poorly chosen name (which Kay regrets), isn't about objects at all. As is defined, OOP is about "messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." But perhaps there is some other work by these people that I'm not familiar with that speaks to OOP? > It seems like a lot of people dislike Object Oriented Programming Sure. I expect all people dislike object-oriented programming in practice, which is why you never truly see it. Sending a message and maybe getting a response (i.e. extreme late-binding) is cool on a theoretical level, but not exactly practical when it comes to real applications that want to have certain guarantees. The rising love for statically typed languages highlights that people want such guarantees. Ironically, OOP probably only shines for things like client->relational database systems that cannot guarantee the state of the database at compile time. At least the paradigm gets you thinking about what to do when an actor doesn't respond to your message.