If you are pointing out that there is no consistent definition for OOP, I agree. I've said so multiple times. Yes, the proof is in the pudding, as they say.
It is not clear where you think that might otherwise fit into our discussion? I, to the best of my ability, spelled out the historical definitions that we are talking about so that we had a shared understanding. What someone else may have defined the same words as is irrelevant.
I think we can agree that these dividing lines aren't even useful, but the history behind them is understandable. In the beginning there was imperative programming, named to differentiate from unstructured programming. Then came encapsulation, which didn't fit under imperative, so they named it functional to separate it from imperative. But then came Smalltalk, and it recognized that it doesn't fit under imperative or functional, so it gave itself the name "object-oriented".
If we could go back in time we'd realize that none of these names bring any significance [hence why there is no consistent definition] and throw them away. But we cannot go back in time. We could recognize today that they are just a historical curiosity and throw them away now, but it seems there is too much emotional attachment to them at this point.
So, if you want to use them to satisfy your emotional desires, you can! But you need to also explicitly define them each time so that the reader/listener understands what you mean by it. Failure to do so means they will pick their own pet definition, and then you will talk past each other. There is no commonality found around these terms because, again, any definition you choose (pjmlp's, mine, yours, anyone's) none of them convey any truly useful information, so any definition offered is never retained by anyone else.
> It's pjmlp's insistence that Rust is object-oriented.
It is, for some definition of object-oriented. But this perfectly highlights how there isn't useful information to be found in the use of the term. Even if we all agreed on what object-oriented means, what would you learn from it? Nothing, is what. It was a pointless statement and we can accept it as such.
Sure, for some definition of red, green is red. E.g., colorblind people. I'm interested in more broadly accepted jargon.
The problem is, Rust isn't really object-oriented either. I'm interested in a mostly consistent and hopefully majority definition.
It's not message-passing sense (can't do cool fancy things* a la Ruby or Smalltalk); nor is it inheritance-based (can't do inheritance-based nor prototype-based OOP patterns).
There is one more mathematical definition of whether two features are equal, but it involves languages, local macros, and Turing machines. See https://www.youtube.com/watch?v=43XaZEn2aLc
* There was some kind of message recorder and playback in Ruby/Smalltalk, that I can't find. Basically send methods to objects and record them, then playback them at later date. Will update if I find it.
> The problem is, Rust isn't really object-oriented either. I'm interested in a mostly consistent and hopefully majority definition.
May I suggest "programming language"? I think you will find that most everyone agrees that Rust is a programming language.
In context, it's functional, but I think you rejecting that historical definition means that you agree with me that the attempt at categorization here doesn't provide any useful information. So, the question here is: What specific information is it that you think is failing to be effectively communicated?
If I take a walk down the street and tell the first guy I meet, "Hey, Rust is a programming language", what information did he miss out on that you find critical?
When we establish that, we might find out there is already a widely recognized term. You won't find it in "object-oriented", however. It has never been used in a context where the information was useful. Even the original message passing definition was never useful as you always had to explain what message passing is at the same time anyway, negating the value of a single word to use as a shorthand.
Words are not given to us naturally by the universe. They are a human invention. Consistent definitions for words only become accepted consistently when those humans find utility in adopting something consistent. "If you build it, they will come" only works in movies.
> So, the question here is: What specific information is it that you think is failing to be effectively communicated?
Expressivity. As the video I linked before shows, there is a quantifiable and objective difference between a language that has exceptions and one that doesn't. Or lambda's or async.
What terms like "message passing" and "inheritance-based" capture is unique ability of each language to do something novel* other languages can't. Rust as of now lacks such capabilities, although it can probably simulate them to some extent.
*For message passing, it's the method record and replayer.
For inheritance-based it can be something like easy DOM manipulation.
Then you might say that Rust is an expressive programming language. But then I'm going to ask: What does expressivity mean?
Ruby is always hailed for its expressivity. Is it also an expressive programming language despite having very little in common with Rust technically?
It seems to me you're going back down the road Kay did thinking that "object-oriented" could become the way to describe his actor based, message passing model. It never caught on because what that means isn't well understood and had to be explained in more detail, so a single word didn't add any value, and thus nobody ever took note of it.
> there is a quantifiable and objective difference between a language that has exceptions and one that doesn't.
Well, I suggest we have a way to say that: {X} {has|does not have} exceptions. The terminology there already exists and is commonplace, as far as I see. If you need to talk about multiple features, then make it a list: {X} has exceptions, lambdas, and inheritance. Laundry list of features are easy to describe. It is when one wants to speak more conceptually that it is harder to find something of actual value as it is usually the concept that you want to explain.
And maybe that's all you really need to get the information conveyed here? "Rust is a programming language" → "Rust is a programming language that has x, y, and z."
> Then you might say that Rust is an expressive programming language.
That's not what I mean. Expressivity allows you to objectively test if two languages are different. The functional/objective/imperative are trying to capture some expressive features.
Using expressivity, you can finally put a Turing machine to that feeling and test it.
> The terminology there already exists and is commonplace, as far as I see.
Missing the point. Message oriented language captures the expressivity of having
the ability to send and receive arbitrary methods. This is what I mean.
If OOP or MOP is just a marketing term, then it carries no value.
If you are pointing out that there is no consistent definition for OOP, I agree. I've said so multiple times. Yes, the proof is in the pudding, as they say.
It is not clear where you think that might otherwise fit into our discussion? I, to the best of my ability, spelled out the historical definitions that we are talking about so that we had a shared understanding. What someone else may have defined the same words as is irrelevant.
I think we can agree that these dividing lines aren't even useful, but the history behind them is understandable. In the beginning there was imperative programming, named to differentiate from unstructured programming. Then came encapsulation, which didn't fit under imperative, so they named it functional to separate it from imperative. But then came Smalltalk, and it recognized that it doesn't fit under imperative or functional, so it gave itself the name "object-oriented".
If we could go back in time we'd realize that none of these names bring any significance [hence why there is no consistent definition] and throw them away. But we cannot go back in time. We could recognize today that they are just a historical curiosity and throw them away now, but it seems there is too much emotional attachment to them at this point.
So, if you want to use them to satisfy your emotional desires, you can! But you need to also explicitly define them each time so that the reader/listener understands what you mean by it. Failure to do so means they will pick their own pet definition, and then you will talk past each other. There is no commonality found around these terms because, again, any definition you choose (pjmlp's, mine, yours, anyone's) none of them convey any truly useful information, so any definition offered is never retained by anyone else.
> It's pjmlp's insistence that Rust is object-oriented.
It is, for some definition of object-oriented. But this perfectly highlights how there isn't useful information to be found in the use of the term. Even if we all agreed on what object-oriented means, what would you learn from it? Nothing, is what. It was a pointless statement and we can accept it as such.