5 ms·

You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it.

You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it. I highly disagree. It is not "pointless semantics". To think everything in the world is some tool in a toolbox and nothing is truly ever bad and everything has a use is naive. Some things are good some things are bad and some things are OOP while other things are not. Rust is not focusing on the OOP philosophy. Both GO and Rust are moving away from that style of abstraction in terms of philosophical goals. If you want to twist the language into OOP that's still possible and still your prerogative. But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. I'm not saying OOP is bad. I'm saying that this is the current status quo. My opinion on the OOP style was not mentioned at all.

scratcheee 4y ago
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.
kaashif 4y ago
> But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. Apologies for not understanding this - if the delineation between OOP and not OOP is so clear, it should be easy to come up with an objective criterion for being OOP that C++ satisfies and Rust doesn't satisfy. I'm not sure what that would be. Inheritance? If that can't be done, then I'd say it's a matter of opinion.
- deltasevennine 4y ago
  Inheritance is not oop. If you think about it inheritance is syntactic sugar around definitions of objects. Not really a programming style because it doesn't change the structure of your program in terms of state and logic. These are simply definitions, no control flow is defined here. I have object a and I have object b. A is similar to b. How do I define a in terms of b? That is inheritance. Functional languages can support this type of syntactic sugar. It is not exclusive to OOP.
- deltasevennine 4y ago
  It can be done. But you don't compare it to rust. You compare it to programming paradigms. This is because rust can be bent to support oop along with almost every language out there. So what you imagine is this: A venn diagram. The left is all other programming paradigms. The right is oop. Most of the oop stuff is in the intersection of these circles. What's to the right is encapsulated mutation. Getters and setters and variants of these two concepts. Mostly setters though. All of oop is simply instantiated objects manipulating and communicating with each other with getters and setters. This is unique to oop. You can't even imitate this with a functional language. But it shouldn't be functional vs. oop. You can avoid writing any getters and setters in your program and while you wouldn't be doing oop, you wouldn't be doing functional either. mutate_function(a) is isomorphic to a.mutate_method(). The latter is oop the former is not. There is a design tradeoff here that's actually well known and named. I forgot what it was called though. But also note how I used mutate here in the names. It's because this property of mutation is the main differentiator that causes oop to be different. If everything was immutable but you still used methods everywhere it wouldn't be uniquely oop. It would be functional as well. And if you think about it is the very property of mutation that allows objects to communicate and mutate one another which fits with our intuition of what oop is. That's why methods that mutate should formally define oop and what it actually is.

scratcheee 4y ago

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.

kaashif 4y ago

> But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. Apologies for not understanding this - if the delineation between OOP and not OOP is so clear, it should be easy to come up with an objective criterion for being OOP that C++ satisfies and Rust doesn't satisfy. I'm not sure what that would be. Inheritance? If that can't be done, then I'd say it's a matter of opinion.

deltasevennine 4y ago
Inheritance is not oop. If you think about it inheritance is syntactic sugar around definitions of objects. Not really a programming style because it doesn't change the structure of your program in terms of state and logic. These are simply definitions, no control flow is defined here. I have object a and I have object b. A is similar to b. How do I define a in terms of b? That is inheritance. Functional languages can support this type of syntactic sugar. It is not exclusive to OOP.
deltasevennine 4y ago
It can be done. But you don't compare it to rust. You compare it to programming paradigms. This is because rust can be bent to support oop along with almost every language out there. So what you imagine is this: A venn diagram. The left is all other programming paradigms. The right is oop. Most of the oop stuff is in the intersection of these circles. What's to the right is encapsulated mutation. Getters and setters and variants of these two concepts. Mostly setters though. All of oop is simply instantiated objects manipulating and communicating with each other with getters and setters. This is unique to oop. You can't even imitate this with a functional language. But it shouldn't be functional vs. oop. You can avoid writing any getters and setters in your program and while you wouldn't be doing oop, you wouldn't be doing functional either. mutate_function(a) is isomorphic to a.mutate_method(). The latter is oop the former is not. There is a design tradeoff here that's actually well known and named. I forgot what it was called though. But also note how I used mutate here in the names. It's because this property of mutation is the main differentiator that causes oop to be different. If everything was immutable but you still used methods everywhere it wouldn't be uniquely oop. It would be functional as well. And if you think about it is the very property of mutation that allows objects to communicate and mutate one another which fits with our intuition of what oop is. That's why methods that mutate should formally define oop and what it actually is.