5 ms·

> 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

by Ygg2 7mo ago

> 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.

igouy 7mo ago
Fruit = { Apple, Cucumber, … } Veg = { Cucumber, … } Fruit As In = Fruit − Veg
- Ygg2 7mo ago
  Culinary they are separate. But fruit can refer to anything that develops from a pollinated flower. Including cucumber and strawberry.
9rx 7mo ago
> Sure but your definition doesn't cover it. How does it not cover 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. Polymorphism? That was never mentioned. Let me reiterate the definitions: - Imperative: Plain functions (C, Fortran, Pascal). - Functional: Functions with encapsulation (C++, Java, Haskell, Erlang). - Object-oriented: Message passing (Smalltalk, Objective-C, Ruby, Erlang). 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.
- Ygg2 7mo ago
  > Polymorphism? That was never mentioned. Let me reiterate the definitions Sigh. Look at what started this whole discussion. > pjmlp: Plenty of OOP architectures can be implemented 1:1 in Rust type system. It's pjmlp's insistence that Rust is object-oriented. I'm fine with object-oriented meaning message passing. I'm fine with object-oriented being used to describe inheritance based langs Java/C#/C++. But where that fails miserably is when you try implementing inheritance based stuff like DOM in Rust. You can't have your cake (all capabilities of OOP) and also eat it too (also most of them missing). Rust was never about inheritance hierarchies or message passing. It's just structs with privacy modifiers. And functions that are applied to them.
  - 9rx 7mo ago
    > Look at what started this whole discussion. 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.

by Ygg2 7mo ago

igouy 7mo ago

Fruit = { Apple, Cucumber, … } Veg = { Cucumber, … } Fruit As In = Fruit − Veg

Ygg2 7mo ago
Culinary they are separate. But fruit can refer to anything that develops from a pollinated flower. Including cucumber and strawberry.

9rx 7mo ago

> Sure but your definition doesn't cover it. How does it not cover 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. Polymorphism? That was never mentioned. Let me reiterate the definitions: - Imperative: Plain functions (C, Fortran, Pascal). - Functional: Functions with encapsulation (C++, Java, Haskell, Erlang). - Object-oriented: Message passing (Smalltalk, Objective-C, Ruby, Erlang). 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.

Ygg2 7mo ago
> Polymorphism? That was never mentioned. Let me reiterate the definitions Sigh. Look at what started this whole discussion. > pjmlp: Plenty of OOP architectures can be implemented 1:1 in Rust type system. It's pjmlp's insistence that Rust is object-oriented. I'm fine with object-oriented meaning message passing. I'm fine with object-oriented being used to describe inheritance based langs Java/C#/C++. But where that fails miserably is when you try implementing inheritance based stuff like DOM in Rust. You can't have your cake (all capabilities of OOP) and also eat it too (also most of them missing). Rust was never about inheritance hierarchies or message passing. It's just structs with privacy modifiers. And functions that are applied to them.
- 9rx 7mo ago
  > Look at what started this whole discussion. 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.