4 ms·

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

by 7bit 7mo ago

pjmlp 7mo ago
It certainly is according to the various CS definitions of type systems. Plenty of OOP architectures can be implemented 1:1 in Rust type system.
- Ygg2 7mo ago
  > Plenty of OOP architectures can be implemented 1:1 Plenty of OOP architecture can be implemented in C. That's an extremely flawed and fuzzy definition. But we've been through this before.
  - pjmlp 7mo ago
    Yet people have to keep be reminded of it.
    - Ygg2 7mo ago
      I think the issue is OOP patterns are one part missing features, one part trying to find common ground for Java, Modula, C++, SmallTalk, that it ends up too broad. A much saner definition is looking at how languages evolved and how term is used. The way it's used is to describe an inheritance based language. Basically C++ and the descendants.
      - 9rx 7mo ago
        > 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?
        Ygg2 7mo ago
        > 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.
        9rx 7mo ago
        > You omitted Smalltalk. 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.
- deleted 7mo ago
  [deleted]
- 9rx 7mo ago
  Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.
  - pjmlp 7mo ago
    I am talking about Rust OOP language features for polymorphism, dynamic and static dispatch, encapsulation, interfaces. Which allowed me to port 1:1 the Raytracing Weekend tutorial from the original OOP design in C++ to Rust. Also the OOP model used by COM and WinRT ABIs, that Microsoft makes heavy use of in their Rust integration across various Windows and Office components.
9rx 7mo ago
Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.
- CyberDildonics 7mo ago
  If you make up your own definitions things can be anything you want and have or not have any label.
  - 9rx 7mo ago
    Absolutely. That's why it is best to stick to the already established definitions. Kay was quite explicit about what "object-oriented" meant when the term was uttered for the first time; including specifically calling out C++ as not being object-oriented. And yes, we all know the rest of the story about how the C++ guys were butthurt by that callout and have been on a mission to make up their own pet definition that allows C++ to become "object-oriented" ever since. I mean, who wouldn't want to latch onto a term that was about the unique features of a failed programming language that never went anywhere?
    - CyberDildonics 7mo ago
      Don't you think it's a bit silly to keep rehashing tribalistic arguments that people moved on from 40 years ago?
      - 9rx 7mo ago
        Once someone offers up the replacement name so that we can continue to talk about what "object-oriented" referred to 40 years ago — and still refers to today, sure. Nobody cares about the exact letters and sounds. But, until then, no. It is still something we regularly talk about. It needs a name. And lucky for us it already has one — and has had one for 40 years.

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

by 7bit 7mo ago

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

pjmlp 7mo ago

It certainly is according to the various CS definitions of type systems. Plenty of OOP architectures can be implemented 1:1 in Rust type system.

Ygg2 7mo ago
> Plenty of OOP architectures can be implemented 1:1 Plenty of OOP architecture can be implemented in C. That's an extremely flawed and fuzzy definition. But we've been through this before.
- pjmlp 7mo ago
  Yet people have to keep be reminded of it.
  - Ygg2 7mo ago
    I think the issue is OOP patterns are one part missing features, one part trying to find common ground for Java, Modula, C++, SmallTalk, that it ends up too broad. A much saner definition is looking at how languages evolved and how term is used. The way it's used is to describe an inheritance based language. Basically C++ and the descendants.
    - 9rx 7mo ago
      > 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?
      - Ygg2 7mo ago
        > 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.
        9rx 7mo ago
        > You omitted Smalltalk. 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.
deleted 7mo ago
[deleted]
9rx 7mo ago
Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.
- pjmlp 7mo ago
  I am talking about Rust OOP language features for polymorphism, dynamic and static dispatch, encapsulation, interfaces. Which allowed me to port 1:1 the Raytracing Weekend tutorial from the original OOP design in C++ to Rust. Also the OOP model used by COM and WinRT ABIs, that Microsoft makes heavy use of in their Rust integration across various Windows and Office components.

9rx 7mo ago

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.

CyberDildonics 7mo ago
If you make up your own definitions things can be anything you want and have or not have any label.
- 9rx 7mo ago
  Absolutely. That's why it is best to stick to the already established definitions. Kay was quite explicit about what "object-oriented" meant when the term was uttered for the first time; including specifically calling out C++ as not being object-oriented. And yes, we all know the rest of the story about how the C++ guys were butthurt by that callout and have been on a mission to make up their own pet definition that allows C++ to become "object-oriented" ever since. I mean, who wouldn't want to latch onto a term that was about the unique features of a failed programming language that never went anywhere?
  - CyberDildonics 7mo ago
    Don't you think it's a bit silly to keep rehashing tribalistic arguments that people moved on from 40 years ago?
    - 9rx 7mo ago
      Once someone offers up the replacement name so that we can continue to talk about what "object-oriented" referred to 40 years ago — and still refers to today, sure. Nobody cares about the exact letters and sounds. But, until then, no. It is still something we regularly talk about. It needs a name. And lucky for us it already has one — and has had one for 40 years.