4 ms·

All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me. It's true that a lot of the OOP ideas

All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me. It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further. The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal. It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.

deltasevennine 4y ago
Interfaces are not oop. Interfaces are part of type theory. Generics so to say. The unique thing about OOP is objects with mutating state that communicate with one another. This is really the only part of OOP that is uniquely OOP. All other things that are "OOP" like interfaces or object.method() notation are not intrinsic to oop. Rust moves away from this paradigm I describe.
- kaashif 4y ago
  > The unique thing about OOP is objects with mutating state that communicate with one another. In what way does C++ have this but Rust doesn't?
  - deltasevennine 4y ago
    Rust is not geared towards oop. But it can be bent to do that. You should be asking the question in what way does OOP mutate state and what other programming paradigms don't? What described above is unique to the oop style. In general when you write rust. Unless you love oop, in general the syntax isn't set up to promote you creating a graph of objects that mutate one another. Java promotes this style the most. For rust the style the syntax promotes is movement of data through pipelines. The data can get manipulated as it moves through the pipeline. For functional programming it's similar. You have pipelines, but nothing is being manipulated. Each segment of the pipe in this case takes an input and produces a new output without moving or changing anything.
    - scratcheee 4y ago
      any part of OOP that is "unique to the oop style" and not used by other programming paradigms is going to be the worst part of OOP. OOP has been around long enough that all the good ideas have been borrowed/copied/reinterpretted/stolen many times over. Any ideas that managed to remain unique to OOP all this time must have sucked.
      - deltasevennine 4y ago
        Naw. Youre thinking inheritance. That's not what it is. Inheritance can be used in FP. It's not uniquely OOP at all. The only thing uniquely OOP is the concept of setters. It's fundamental and isn't some side concept either. Setters are fundamental to how you program in OOP. OOP is basically a graph of objects mutating one another. Setters are not used in any other programming paradigm. Not in FP, not in C style programming... Any style of programming that strictly is not OOP does not use setters.
- pjmlp 4y ago
  Since when interfaces aren't OOP?!? Better brush up on OOPSLA, ACM and IEEE literature.
  - deltasevennine 4y ago
    That literature is wrong. Interfaces exist outside of of oop. Saying it's oop is like saying addition is oop because you used it in your programs. Interfaces exist in functional languages as well. You need to search for the thing that is uniquely oop. Interfaces is not it. Clearly this is an inconsistency. If IEEE defines interfaces as oop then it is also saying functional programming is oop. This doesn't mesh with our intuition of the meaning of these two terms. There is a differentiator that is uniquely oop and uniquely functional and that is mutation via setters vs. immutability. Functional programs must be immutable, while oop allows for mutation via setters. Some people like to roll with the notion that oop and functional are orthogonal concepts, this is an inconsistent notion. You have to realize that mutation via setters definitively makes the two concepts parallel and opposite. Functional cannot mutate. If the industry ever truly mathematically formalized the term oop rather then relying on crude improvised guidelines via IEEE then mutation via setters is the formal definition of oop. Everyone nowadays gets confused because lack of proper formalism. The think if they used a method like a getter or inheritance or a class, then they did oop. When this is the case, suddenly everything looks like oop. Suddenly oop is prevalent and the dominant paradigm and used everywhere.
    - pjmlp 4y ago
      I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet. Some of the initial implementation of interfaces go back to CLU ADTs, Smalltalk traits, Objective-C Protocols, Java interfaces, C++ pure virtual classes, BETA patterns, Eiffel, CLOS protocols....
      - deltasevennine 4y ago
        > I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet. You don't even know who wrote the IEEE definition and who validated it. Second this isn't academic truth. This is just some arbitrary chosen standard chosen by industry. Not academic at all. In mathematics, the ultimate logical form of academia there is a term for "interfaces". It's called categories, and there's a entire theoretical framework behind it called "Category Theory". This theory of "interfaces" goes beyond just OOP and category theory can be used to foundation-ally describe all of mathematics and function as a sort of replacement of set theory. Don't worship authority for authorities sake. If the IEEE declared 1+1=3 would you believe it? Instead use your own brain. Do my arguments have merit? Does the IEEE definition seem inconsistent? Does my definition make logical sense? If you can think of these things on your own merits instead of blindly following the IEEE then you'll see that the definition of OOP is just something academia hasn't really thought about deeply from a theoretical and mathematical standpoint. OOP is more like a term that comes from applied engineering with very little theoretical foundation. If you want some sort of authority I googled some authoritative talk about category theory explained to programmers: https://www.youtube.com/watch?v=JMP6gI5mLHc https://www.youtube.com/watch?v=JMP6gI5mLHc I'm sure maybe you heard of haskell and category theory? Haskell is a purely functional language and it has huge connections with category theory. Basically Haskell IS the language of interfaces. It's entire type system is centered around categories or AKA "interfaces". It is the defacto language of interfaces much more-so then OOP languages like Java. If you said haskell was OOP, people who love that language would vomit. Haskell is not OOP, but it has interfaces, so the obvious conclusion here is "interfaces" ARE not an OOP exclusive concept. It's therefore bad for a formal definitio of OOP. So now the question is WHAT is it about OOP that makes it uniquely OOP. Or is it just a hodgepodge of random stuff and it will be forever a word that is muddy, inconsistent and poorly defined?

deltasevennine 4y ago

Interfaces are not oop. Interfaces are part of type theory. Generics so to say. The unique thing about OOP is objects with mutating state that communicate with one another. This is really the only part of OOP that is uniquely OOP. All other things that are "OOP" like interfaces or object.method() notation are not intrinsic to oop. Rust moves away from this paradigm I describe.

kaashif 4y ago
> The unique thing about OOP is objects with mutating state that communicate with one another. In what way does C++ have this but Rust doesn't?
- deltasevennine 4y ago
  Rust is not geared towards oop. But it can be bent to do that. You should be asking the question in what way does OOP mutate state and what other programming paradigms don't? What described above is unique to the oop style. In general when you write rust. Unless you love oop, in general the syntax isn't set up to promote you creating a graph of objects that mutate one another. Java promotes this style the most. For rust the style the syntax promotes is movement of data through pipelines. The data can get manipulated as it moves through the pipeline. For functional programming it's similar. You have pipelines, but nothing is being manipulated. Each segment of the pipe in this case takes an input and produces a new output without moving or changing anything.
  - scratcheee 4y ago
    any part of OOP that is "unique to the oop style" and not used by other programming paradigms is going to be the worst part of OOP. OOP has been around long enough that all the good ideas have been borrowed/copied/reinterpretted/stolen many times over. Any ideas that managed to remain unique to OOP all this time must have sucked.
    - deltasevennine 4y ago
      Naw. Youre thinking inheritance. That's not what it is. Inheritance can be used in FP. It's not uniquely OOP at all. The only thing uniquely OOP is the concept of setters. It's fundamental and isn't some side concept either. Setters are fundamental to how you program in OOP. OOP is basically a graph of objects mutating one another. Setters are not used in any other programming paradigm. Not in FP, not in C style programming... Any style of programming that strictly is not OOP does not use setters.
pjmlp 4y ago
Since when interfaces aren't OOP?!? Better brush up on OOPSLA, ACM and IEEE literature.
- deltasevennine 4y ago
  That literature is wrong. Interfaces exist outside of of oop. Saying it's oop is like saying addition is oop because you used it in your programs. Interfaces exist in functional languages as well. You need to search for the thing that is uniquely oop. Interfaces is not it. Clearly this is an inconsistency. If IEEE defines interfaces as oop then it is also saying functional programming is oop. This doesn't mesh with our intuition of the meaning of these two terms. There is a differentiator that is uniquely oop and uniquely functional and that is mutation via setters vs. immutability. Functional programs must be immutable, while oop allows for mutation via setters. Some people like to roll with the notion that oop and functional are orthogonal concepts, this is an inconsistent notion. You have to realize that mutation via setters definitively makes the two concepts parallel and opposite. Functional cannot mutate. If the industry ever truly mathematically formalized the term oop rather then relying on crude improvised guidelines via IEEE then mutation via setters is the formal definition of oop. Everyone nowadays gets confused because lack of proper formalism. The think if they used a method like a getter or inheritance or a class, then they did oop. When this is the case, suddenly everything looks like oop. Suddenly oop is prevalent and the dominant paradigm and used everywhere.
  - pjmlp 4y ago
    I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet. Some of the initial implementation of interfaces go back to CLU ADTs, Smalltalk traits, Objective-C Protocols, Java interfaces, C++ pure virtual classes, BETA patterns, Eiffel, CLOS protocols....
    - deltasevennine 4y ago
      > I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet. You don't even know who wrote the IEEE definition and who validated it. Second this isn't academic truth. This is just some arbitrary chosen standard chosen by industry. Not academic at all. In mathematics, the ultimate logical form of academia there is a term for "interfaces". It's called categories, and there's a entire theoretical framework behind it called "Category Theory". This theory of "interfaces" goes beyond just OOP and category theory can be used to foundation-ally describe all of mathematics and function as a sort of replacement of set theory. Don't worship authority for authorities sake. If the IEEE declared 1+1=3 would you believe it? Instead use your own brain. Do my arguments have merit? Does the IEEE definition seem inconsistent? Does my definition make logical sense? If you can think of these things on your own merits instead of blindly following the IEEE then you'll see that the definition of OOP is just something academia hasn't really thought about deeply from a theoretical and mathematical standpoint. OOP is more like a term that comes from applied engineering with very little theoretical foundation. If you want some sort of authority I googled some authoritative talk about category theory explained to programmers: https://www.youtube.com/watch?v=JMP6gI5mLHc https://www.youtube.com/watch?v=JMP6gI5mLHc I'm sure maybe you heard of haskell and category theory? Haskell is a purely functional language and it has huge connections with category theory. Basically Haskell IS the language of interfaces. It's entire type system is centered around categories or AKA "interfaces". It is the defacto language of interfaces much more-so then OOP languages like Java. If you said haskell was OOP, people who love that language would vomit. Haskell is not OOP, but it has interfaces, so the obvious conclusion here is "interfaces" ARE not an OOP exclusive concept. It's therefore bad for a formal definitio of OOP. So now the question is WHAT is it about OOP that makes it uniquely OOP. Or is it just a hodgepodge of random stuff and it will be forever a word that is muddy, inconsistent and poorly defined?