Some people don't understand OOP, sure. That's the nature of things. However, many of us do understand. Consequently, nothing here comes as a surprise. And yet, we still think OOP has drawbacks where it's often applied, even if it has benefits in other applications. If nothing else, one benefit is that it helps us organize code segments and reason about function dispatch. One drawback is that it's not well-suited where it's often applied. This is the well-known "impedence mismatch." When that happens, it's worth asking if there are other ways to organize code segments and reason about function dispatch, which are better-suited so they don't experience these drawbacks. There are. Database constraints are one. Database triggers are another. They're not the only ones and they're not perfect, but then neither is OOP, and at least they have the virtue of being mated to the underlying data model perfectly.
Therefore, before we rush to say that other people don't understand OOP, perhaps we should consider the possibility that WE don't understand OOP if we insist on applying it where it doesn't apply.
I, for one, tried to read the comment. I got the impression it was trying to talk about the drawbacks of active record, echoing many of the common criticisms of active record, but which has little to do with OOP. Perhaps you could clarify what you were trying to say with respect to OOP?
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.
> 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.
> 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.
> 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.
Happy to, but it is not clear what I should study. You have not yet indicated what it is about OOP that you are talking about.
You keep pointing to the object-relational mismatch, which, while a thing, has no more to do with OOP than it does functional programming. It pertains to object-based programming. That is something else entirely.
Understandably, those who don't understand OOP often confuse OOP with object-based programming. Is that the problem here? Just that you don't understand OOP?
Fair that fluidity of language means that anyone can define OOP as they wish, and if they want to define OOP to be equivalent to OBP, good for them. They wouldn't be the first. And if we were discussing this topic in a vacuum we could set out a proclamation that defines OOP to be equal to OBP. However, OOP was already and explicitly defined by the article that setup the context for the following discussion, and the definition used is Kay's – the one that has nothing to do with objects. Other definitions for OOP would be clearly off-topic.
Perhaps it is that you are purposefully trying to go off-topic? Indeed, this thread started because someone (not me!) questioned exactly that.
If it is simply that you don't know how to clarify what you mean, why not just say so?
> Happy to, but it is not clear what I should study. You have not yet indicated what it is about OOP that you are talking about.
I don't have to. That's already explained in the standard literature on the topics of the object-relational mismatch and on functional critique of mutable state.
> You keep pointing to the object-relational mismatch, which, while a thing, has no more to do with OOP than it does functional programming. It pertains to object-based programming. That is something else entirely.
And I say that the object-relational mismatch does have more to do with OOP than it does with functional programming. If you want to make unfounded claims, two can play at that game.
> However, OOP was already and explicitly defined by the article that setup the context for the following discussion, and the definition used is Kay's
Point to the place on the doll where the article explicitly defines OOP and uses Kay's definition to do it.
> Perhaps it is that you are purposefully trying to go off-topic? Indeed, this thread started because someone (not me!) questioned exactly that.
And yet that person never came back. You can't rule out the possibility that this person was satisfied by my subsequent clarifications.
> If it is simply that you don't know how to clarify what you mean, why not just say so?
> And I say that the object-relational mismatch does have more to do with OOP than it does with functional programming.
Understood. You have asserted that many times now. But what you are trying to say has not been made clear.
Let's break this down. As defined by context, OOP means: messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. Indeed, there exist other OOP definitions, but that is the one that was defined here.
I think we can rule out "local retention and protection and hiding of state-process" from the discussion. Hiding means that even if there is some kind of relational database access happening behind the curtain, we cannot know about it. If we don't know about it, we cannot talk about it.
That leaves messaging and extreme late-binding. It is not clear to me what it is about messaging and/or extreme late-binding that is at odds with relational databases. This is where I seek clarification.
While you pointed to the work of Neward and Atwood, all I could find from them was discussion about the pitfalls of trying to model relational databases as a particular object model. They say nothing about messaging or extreme late-binding. Unfortunately, they were of no help here.
> Let's break this down. As defined by context, OOP means: messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. Indeed, there exist other OOP definitions, but that is the one that was defined here.
Point to the place on the doll where the article author defines OOP.
This has been covered several times. Seemingly in a way that I failed to make it clear, granted, but without any feedback in what you did take from it to determine where the need for further clarity remains, it is difficult to try to correct. Needless to say, I recognize that you are here in bad faith so I was never expecting you to work towards a mutual understanding, but I throw this out there anyway as the response to it will no doubt be hilarious.
Given that you don't know how to clarify your original message, perhaps we can still salvage something here? Let's assume that OOP is by another definition. Your choice. Define it however you please. Then explain how relational databases fit into that definition.
No, this has been covered exactly once. I asked 4 hours ago in this sub-thread this question, but you didn't answer it. I also asked again 3 hours ago in this sub-thread. I also asked a related question in another sub-thread 3 hours ago. You answered it one time 2 hours ago with "First thing you read. That's where definitions go." in the other sub-thread, then 1 hour ago in this sub-thread to its second query you said This has been covered several times which it absolutely not has been. THIS, dear readers, is what we call "bad faith."
> Given that you don't know how to clarify your original message, perhaps we can still salvage something here? Let's assume that OOP is by another definition. Your choice. Define it however you please. Then explain how relational databases fit into that definition.
Absolutely not. You have acted in bad faith, have been argumentative, have been snide, have been condescending, and have made things personal throughout these debates. I will absolutely not be corresponding with you in HN comments on this topic or on any other any longer. I would do so "in-person" in a Zoom call if you had the stones for it, but I doubt you do.
I count three times in this thread (plus apparently again in another thread, although that has no relevance to this one). I respect that I did not convey it in an understandable way. Communication is hard. But it is not clear to me what was interpreted instead, in order to allow me to turn the ship in the right direction.
> I will absolutely not be corresponding with you in HN comments on this topic or on any other any longer.
Because we wouldn't be able to figure that if you just stopped corresponding...?
> I would do so "in-person" in a Zoom call
Sure, I'll listen in if you want to expand upon how relational databases pertain to your definition of OOP. If you seek a debate, as suggested above, no thanks. High school debate club is best left for high school students. I did not engage in debate with you here for good reason, and I will not engage in debate elsewhere either.
I'm the author of the comment and yet I have never used ActiveRecord, which was coined by Martin Fowler 2 years after I was using iBATIS and was popularized by Ruby on Rails a year later. As the author of the comment, I can assure you the comment was not referring to ActiveRecord, a topic that was not mentioned either in the comment or in the original article.
Active record, with a space, not ActiveRecord. Not sure how you managed to jump all the way to Ruby on Rails.
Regardless, the ask was "Perhaps you could clarify what you were trying to say with respect to OOP?", not "Have you used (active record|ActiveRecord)?" Even if you somehow managed to not see the space, and didn't notice the capitalization, the response still doesn't logically follow.
> I said that ActiveRecord was popularized by Ruby on Rails in 2004.
Thanks for the random history lesson and all, but why are you bringing up ActiveRecord in the first place? The topic is OOP, not a library that is bundled with a web framework created many years ago.
Did you not even read your own comment? For a brief moment you seemed to recognize that the subject is about OOP.
Whether it's "active record" or "ActiveRecord", with or without caps, with or without spaces, I'm not persuaded these are different things. If you want me to believe that they are, I invite you to try to persuade me. While I'm inviting you to do that, let me also invite you to accept what people tell you about themselves in lieu of what you infer about themselves. I was talking about OOP. You said that I seemed to be talking about "active record." I assured you that I was not. Setting aside sophistry about caps and spaces, any disinterested third party observer would agree that it's obvious I've addressed what you have inferred. Therefore, I consider the matter settled. I'm talking about OOP and not active record. I will not address this topic further with you.
Why? I enjoy and benefit from the fact that you think a software library and a theoretical concept are the same thing. Never change.
> I'm talking about OOP and not active record.
Yes. We established that in my very first comment. However, I stated that it reads like you were talking about active record, and that is why it was asked if you could clarify how it pertains to OOP, given that we know you are actually talking about OOP.
If you don't know how to clarify your message, why not just say so?
Hmmm. I already don't like it when we're collecting together "procedures and state".
One of the most poisonous things about the "class" whether that's in Java or C++ is that it looks as though this procedure called "chirp" and this state called "loudness" are snuggled up together in my Bird class, after all in my source code they are literally on adjacent lines!
Of course they're not, the actual mechanics are the same as in say Rust, where "chirp" lives in an impl block, while "loudness" is part of the actual data structure, or a language with full blown Uniform Method Call Syntax where the relevance of Bird to a "chirp" procedure is just spelled out wherever "chirp" is defined, not in the data structure of Bird itself.
I think the heart of OOP is the opacity, the fact that we (for some definition of we) aren't allowed to poke around in the state directly, and this article talks about that idea at length, critiquing people who build a whole bunch of getter and setter mechanics for what is, in practice, just Plain Old Data and not really an object at all. So I think I'd start there, not by adding procedures.
So, I think a Doodad which may have internal state but we can't touch it, is an Object, even if there seemingly aren't any procedures for Doodads at all. But a Thingy, which has six named integers and a string inside it, that's not an object in the OOP sense, that's just some data, even if I have a whole tonne of procedures for Thingys.
This also makes sense when I don't have total information. If you give me a Thingy, I can do things with that, regardless of whether you provide procedures, but if you give me a Doodad, I can't do anything with that unless you provide procedures. Maybe you have procedures, but I can't necessarily use them.
> I think the heart of OOP is the opacity, the fact that we (for some definition of we) aren't allowed to poke around in the state directly
At the heart of OOP is being able to throw a message out into the world and maybe find another actor willing to respond to it. It is not so much that you are not allowed to poke around in the state of other actors, but that you fundamentally cannot know what other state exists without breaking the paradigm.
> So I think I'd start there, not by adding procedures.
Agreed. A thin veneer over internal state does not fix a break in the paradigm.
> if you give me a Doodad, I can't do anything with that unless you provide procedures.
You aren't even given Doodad, per se. Under OOP, you just send the message out there. If Doodad chooses to respond, then so be it. If Doohickey responds instead, such is life. Who responds is not your concern.
> If you give me a Thingy, I can do things with that, regardless of whether you provide procedures, but if you give me a Doodad, I can't do anything with that unless you provide procedures.
This is one of the issues I've experienced with overly eager "everything is a class" style of programming. The plain old data gets wrapped up and partially hidden, complected together with procedures.
The other aspect is that plain old functions get wrapped up too, and can only be accessed by instantiating the class, and complected together with state.
This style of code can make the underlying data and algorithms harder to work with, less flexible, too specific to the exact architecture designed by the author - especially as hierarchy of classes, which extend the "complectedness" in more dimensions where they're tied up with each other.
I just want typed and structured "thingies" as plain old data, that lets me reach in, access and modify everything as my own. Then separately, I want stateless plain old functions that accept those and other thingies of the same shape, wherever they come from, however they're created. That way I can use them by themselves, without being tied to any associated state, for my own purposes.
Sometimes I think the problem is too much "architecture", where all the parts are fused and can only be used together; whereas I prefer a "toolset" or "workshop", a coherent collection of parts that are independently useful and usable.
What all these discussions leave out is the importance of distributed object systems (COM, Binder, ...) and related technologies that played a prominent role in GUIs post 1990. Notably COM was designed so you could create "objects" in a non-OO language like C.
I see it as an important watershed because it seems to me the reliability and particularly performance reliability went downhill around the time this technology went mainstream. I remember plain old X Windows was rock solid but once KDE and Gnome came around that were based on this technology the Linux desktop became about as reliable as the Windows desktop.
Could also be because when “KDE and Gnome came around” also was when X Windows started running more than XEyes, XClock and a few terminal windows, and grew extensions left and right to support new use cases.
The C-style of OO, that is a struct of callbacks, takes a very tree-shaped execution graph of a single entry point and grafts on other random trees from who knows where. Extremely helpful when it’s helpful but a nightmare to debug when it’s not.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” ~Dijkstra probably?
For me objects capture some notion of invariants in data that would otherwise just be a bunch of variables. This is usually indicated by functions that act on the data maintaining the invariants. Those functions are the methods.
I get that many people either don't see, or don't place much importance on the invariants of their data and so they are happy writing functions and even get annoyed by people and their over use of objects. Maybe these people are just way smarter than me; I definitely need objects/classes to help me organize my code.
I'm not convinced invariants are crucial. Common, certainly, but not crucial, I think the opacity is more important.
Take Rust's core::net::Ipv4Addr, that's obviously just a 32-bit value inside - it has no invariants to be maintained, but it's opaque, even though I know it's a 32-bit value, I am actually not able to just directly treat it as the value or prod that value, I have to use certain procedures, which include predicates (to ask if this is, for example, the broadcast address, or a loopback address) and some useful bit operations,
I’m not convinced you need objects to enforce invariants on your data. Why wouldn't you just use a good type system and type-checker to enforce those invariants? They could check if you're using data in places where they're meant to be, without having to bundle data with procedures.
At its core, I view OOP as organizing code so the data and the methods that act on that data are linked. Usually there are some compile time restrictions on who can touch the data. You are able to be sure some state is valid because only this class can touch the state. If you think of OOP like that, it seems trivially good. Surely a lot better than a bunch of raw data hanging out that anyone can mutate at any time.
Inside of some class, you can then implement whatever you want inside of that class, ie:struct of arrays, or w/e.
I don't view "inheritance" as a necessity of OOP. Composition fits great. I don't view "array of structs" as a necessity of OOP, nor over usage of heap allocations and pointer chasing. People associate OOP with this, but it's not fundamental, it's a poor, out dated mutation.
It seems like when people say "OOP is bad" they really mean "over abstractions are bad", and yes, they are bad, but "data oriented design" and "procedural code" isn't some silver bullet that's gonna save you from writing trash code.
Ultimately, I consider ideal code to be "verifiable on sight". Ie; I can read it easily and mentally verify that it is correct. Bad code is code that is very hard to verify correctness by reading. There's an art to this and it doesnt always fit into these semantic buckets of "OOP" or "Data Oriented Design".
Programming is mostly about understanding the problem domain. It is interesting that OOP had its heydey when everyone was building native GUI programs. The most likely situation was that programmers were developing abstractions that matched well to GUIs and those abstractions most closely mapped to OOP.
Things like functional programming, OOP, declarative programming, etc, might matter to language designers. They need these concepts to work out if their language is convenient/internally consistent/featureful and maybe these banner concepts help. Once the language has been built, I don't think programmers actually care. The abstraction isn't at the sweet spot where a developer gets the most power. The components of OOP (encapsulation, message passing, interfaces) are important and should be used liberally - but grouping them together under one heading is detrimental, because there will also be opportunities for other techniques from other schools of thought.
And as an aside inheritance seems to have been a mistake. I haven't seen a lot of places where inheritance was the best idea. Interfaces yes, inheritance no.
> I haven't seen a lot of places where inheritance was the best idea. Interfaces yes, inheritance no.
I like to use interfaces to expose the public side of things, but I find inheritance can be really powerful in terms of code-reuse for implementing those interfaces.
Of course if you got a language that makes encapsulation very smooth then inheritance might not be needed, but otherwise I find it can really cut down on code re-use and boilerplate to have a base class for certain interfaces.
Of course, since the interface is the public bit, if the base class is not a good fit for a certain implementation there's no requirement to use the common base class. So you use it when it makes sense.
> The most likely situation was that programmers were developing abstractions that matched well to GUIs and those abstractions most closely mapped to OOP.
Questionable. Qt signal/slot extensions were undeniably created to add OOP concepts to C++ for the sake of GUIs. You might, if you stretch hard enough, be able to make a case that Objective-C emerged for the sake of GUIs. But what else beyond that?
Smalltalk most definitely influenced how we thought about GUIs, but never really solidified itself as the place to develop GUIs. Class-based, non-OOP, languages seemed to be where most GUI development happened. And in large part were suited to the task. There was little need to introduce OOP.
There was COM and the like, which perhaps can reasonably be considered object-oriented, but only at a higher level of abstraction. The programming was not object-oriented. OO, but not OOP.
Agreed. Which is why we are sticking to the definition as has been already defined. Anything else, while perhaps interesting for a completely different discussion, would be clearly off-topic for this one.
> Which is why we are sticking to the definition as has been already defined.
Has already been defined where exactly? Yes, evidently you believe it has been defined in the article, but where exactly in the article did that occur. Please be precise.
First thing you read. That's where definitions go. Obviously you are not going to go on at length about something and then "Oh yeah, and by the way, this is what I meant by X. Gotcha!" Of course it is going to be the first thing you read.
> First thing you read. That's where definitions go.
Says who? You? Did you get a confirmation from the article author that this was their intention? After all, the first thing you read in the article is a quote, but then there's a second quote later from a different person, which doesn't specifically address the first quote. Is that also a definition?
No, in reality, you don't know the author's definition. Neither of us does, which is why we have to make an educated guess (an "inference"). You've guessed evidently that the author's definition is identical to Kay's. Well, let's consider your confidence around that guess. When the author discusses other topics not included in that definition, like inheritance and polymorphism, does that tend to increase or decrease your confidence in your guess?
Finally, just as I'm not obliged to use your definition and you're not obliged to use mine, neither of us is obliged to use the blog article author's definition either. I certainly didn't agree to that, and there's good reason not to, which is that there are other people involved: the OOP critics.
The article author accuses OOP critics of not understanding OOP. Personally, I think that gives us a reason to use THEIR definition of OOP, not the author's. That is, unless the author's argument "they don't understand OOP" is essentially "they're using the wrong definition of OOP." But then, since there is no right or wrong definition of OOP, that could only mean, "they're using a different definition of OOP from the one I'm using", which they're free to do.
To sum up, your argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?
> When the author discusses other topics not included in that definition, like inheritance and polymorphism, does that tend to increase or decrease your confidence in your guess?
Increases. After all, it is ultimately about how people do not understand OOP. The proof is in the pudding, as they say.
> To sum up, your argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?
Says who? You? Did you get a confirmation from the author that this was their intention?
> Increases. After all, the remainder is about how people do not understand OOP.
The author says this about "subtyping" and "inheritance", terms that do not appear in Kay's definition at the top:
Another term that – while not technically necessary – is often associated with OOP is inheritance.
Subtyping is not exclusive to OOP
Evidently, subtyping and inheritance are not mutually exclusive of OOP and in fact often co-occur with OOP. The author certainly doesn't say that they in and of themselves--or "polymorphism" for that matter--causes people to misunderstand OOP (though they might misunderstand the terms themselves, which could cause confusion). You and I don't know for sure what the author's definition of OOP is, and yet you're more confident that it doesn't include subtyping, inheritance, and polymorphism because the author mentioned them? Is that your final answer?
> Says who? You? Did you get a confirmation from the author that this was their intention?
What is it you often say? Oh right: "Did you even read" what was written? In this case I didn't say:
To sum up, the author's argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?
Instead I said
To sum up, your argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?
The careful reader will note that I was asking about YOUR argument, not THE AUTHOR'S ARGUMENT. So no, I didn't get confirmation from the author that this was their intention. I was seeking confirmation from you that this was your intention. Well? Is it?
> You and I don't know for sure what the author's definition of OOP is
And that's fine. We don't need to know the author's definition. That was deferred to Kay, which stands to reason as Kay defined the term. The author is focused on letting it be known that people, which includes the author himself, don't understand OOP.
In fairness, Kay, who appears to be a person, has made it clear that not even he understands OOP. The only thing he knows for sure is that C++ is not it. Inheritance and polymorphism are core concepts in C++, so given that they were brought up, we have proof positive that the article was written from the perspective of not understanding OOP (in case the title wasn't already clear enough; the author could not have been much more explicit).
> Instead I said – To sum up, your argument essentially is, "you critics of OOP are not using the definition that I use." OK. Well, who asked you?
To which I asked: "Says who? You? Did you get a confirmation from the author that this was their intention?"
As I am the author, I already know the answer, but I wanted to hear the other side of the story. Is there some reason for your strange diversion to avoid answering the question? Are you afraid of what we might learn if you were to become earnest with us? Or did you just not bother reading again?
> We don't need to know the author's definition. That was deferred to Kay
We don't know that it was deferred to Kay. You just assumed that it was.
> To which I asked: "Says who? You? Did you get a confirmation from the author that this was their intention?"
I apologize. How foolish of me to assume you would notice that I assiduously avoided doing anything other than to refer to you by "you" and to refer to the blog article's author as "the author." Let me rephrase.
As a critic of OOP, my definition of OOP includes inheritance, polymorphism, and classes. An example of a programming language that fits this definition is Java. While my criticisms don't depend on those properties, nevertheless that is the definition that I personally use. Now, based on your comments, I believe your argument is:
as a critic of OOP you are not using the defintion of OOP that I use
That's what I believe your argument is, but I'm interested in your beliefs about your own argument. What do you believe your argument is?
> How foolish of me to assume you would notice that I assiduously avoided doing anything other than to refer to you by "you" and to refer to the blog article's author as "the author."
I did notice, indeed. But when I called myself "the author", I was referring to myself.
Is it that you want me to call myself "you" instead? I don't think that works. It is not clear what you are trying to convey here.
Obviously I was the author. Were you under the impression someone else authored the work in question? If so, who? If so, how?
> As a critic of OOP
Was "bingo" meant to a criticism? While this is a fun story that you have randomly decided to share, I fail to see the pertinence.
> What do you believe your argument is?
I have no beliefs on the matter. Logically, once a believe is formed, there is no longer value in discussing it. What more can be learned once you are certain of something? Only before beliefs are formed can you gain insights by talking to other people. Beliefs are built on discussion. Discussion always has to come first.
But maybe you have some pet definition for "belief" that contradicts the common usage recorded in the dictionary?
Alan Kay: an object should be just as powerful as the entire computer, ie an object is a recursive structure.
The rest is implementation details. The implementation details chosen over the past many years, particularly those favored by OOP, generally involve making objects way less powerful than the entire computer.
Therefore, before we rush to say that other people don't understand OOP, perhaps we should consider the possibility that WE don't understand OOP if we insist on applying it where it doesn't apply.