> one part trying to find common ground for Java, Modula, C++
The primary common ground is that their functions have encapsulation, which is what separates it from functions without encapsulation (i.e. imperative programming). This already has a name: Functional programming.
The issue is that functional, immutable programming language proponents don't like to admit that immutability is not on the same plane as imperative/functional/object-oriented programming. Of course, imperative, functional, and object-oriented language can all be either mutable or immutable, but that seems to evade some.
> SmallTalk
Smalltalk is different. It doesn't use function calling. It uses message passing. This is what object-oriented was originally intended to reference — it not being functional or imperative. In other words, "object-oriented" was coined for Smalltalk, and Smalltalk alone, because of its unique approach — something that really only Objective-C and Ruby have since adopted in a similar way. If you go back and read the original "object-oriented" definition, you'll soon notice it is basically just a Smalltalk laundry list.
> how term is used.
Language evolves, certainly. It is fine for "object-oriented" to mean something else today. The only trouble is that it's not clear to many what to call what was originally known as "object-oriented", etc. That's how we end up in this "no its this", "no its that" nonsense. So, the only question is: What can we agree to call these things that seemly have no name?
> The primary common ground is that their functions have encapsulation
You omitted Smalltalk. Most people would agree that SmallTalk is object-oriented.
But that kinda ruins the common ground thesis.
> Language evolves, certainly. It is fine for "object-oriented" to mean something else today.
pjmlp definition is very fuzzy. It judges object-orientedness based on a few criteria, like inheritance, encapsulation, polymorphism, etc. More checks, stronger OOP.
By that, even Haskell is somewhat OOP, and so is C, assembly, Rust, and any language.
---
What I prefer is looking at it as it's used. And how it's used for appears to be akin to using it as an everyday term fish or fruit.
No one would agree that a cucumber is a fruit. Or that humans are fish. Even though botanically and genetically they are.
Exactly. It isn't functional. It doesn't use functions. It uses message passing instead. That is exactly why the term "object-oriented" was originally coined for Smalltalk. It didn't fit within the use of "imperative" and "functional" that preceded it.
> But that kinda ruins the common ground thesis.
That is the thesis: That Smalltalk is neither imperative nor functional. That is why it was given its own category. Maybe you've already forgotten, but I will remind that it was Smalltalk's creator that invented the term "object-oriented" for Smalltalk. Smalltalk being considered something different is the only reason for why "object-oriented" exists in the lexicon.
Erlang is the language that challenges the common ground thesis: It has both functions with encapsulation and message passing with encapsulation. However, I think that is easily resolved by accepting that it is both functional and object-oriented. That is what Joe Armstrong himself settled on and I think we can too.
> What I prefer is looking at it as it's used.
And when you look you'll soon find out that there is no commonality here. Everyone has their own vastly different definition. Just look at how many different definitions we got in this thread alone.
> No one would agree that a cucumber is a fruit.
Actually, absent of context defining whether you are referring to culinary or botanical, many actually do think of a cucumber as a fruit. The whole "did you know a tomato is actually a fruit?" is something that made the big leagues in the popular culture. However, your general point is sound: The definitions used are consistent across most people. That is not the case for object-oriented, though. Again, everyone, their brother, and pjmlp have their own thoughts and ideas about what it means. Looking at use isn't going to settle on a useful definition.
Realistically, if you want to effectively use "object-oriented" in your communication, you are going to have to explicitly define it each time.
> That is exactly why the term "object-oriented" was originally coined for Smalltalk.
Sure but your definition doesn't cover it. If language for which the term was coined, it's a bit meaningless, ain't it.
Problem with making encapsulation and polymorphism essential to OOP definition, is that it then starts garbling up functional languages like Haskell and imperative like C.
I can see them being necessary but not enough to classify something as OOP.
> And when you look you'll soon find out that there is no commonality here.
Perhaps, but broadly speaking people agree that C++ and Java are OOP, but for example C isn't.
Same way when people say and give me a fruit (as in fruits and vegetables), you'd be looked oddly if you gave a cucumber, rather than an apple.
Same way can be thought of OOP. The common definition is basically covers Message-passing-languages, and inheritance/prototype based languages.
> Problem with making encapsulation and polymorphism essential to OOP definition, is that it then starts garbling up functional languages like Haskell and imperative like C.
Polymorphism? That was never mentioned. Let me reiterate the definitions:
Let me also reiterate that there are other axis of concerns. Imperative, functional, and object-oriented are not trying to categorize every last feature a programming language might have. Mutable/immutable, or polymorphic/monomorphic, etc. are others concern and can be independently labeled as such.
> Perhaps, but broadly speaking people agree that C++ and Java are OOP
Many do, but just as many hold on to the original definition. Try as you might, you're not going to find a common definition here, I'm afraid. If you want to use the term effectively, you're going to have to explicitly define it each time.
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.
The primary common ground is that their functions have encapsulation, which is what separates it from functions without encapsulation (i.e. imperative programming). This already has a name: Functional programming.
The issue is that functional, immutable programming language proponents don't like to admit that immutability is not on the same plane as imperative/functional/object-oriented programming. Of course, imperative, functional, and object-oriented language can all be either mutable or immutable, but that seems to evade some.
> SmallTalk
Smalltalk is different. It doesn't use function calling. It uses message passing. This is what object-oriented was originally intended to reference — it not being functional or imperative. In other words, "object-oriented" was coined for Smalltalk, and Smalltalk alone, because of its unique approach — something that really only Objective-C and Ruby have since adopted in a similar way. If you go back and read the original "object-oriented" definition, you'll soon notice it is basically just a Smalltalk laundry list.
> how term is used.
Language evolves, certainly. It is fine for "object-oriented" to mean something else today. The only trouble is that it's not clear to many what to call what was originally known as "object-oriented", etc. That's how we end up in this "no its this", "no its that" nonsense. So, the only question is: What can we agree to call these things that seemly have no name?