4 ms·

Well, to me Rust code looks fundamentally like any other OO language e.g. let mut window: PistonWindow = WindowSettings::new( "piston: hello_wo

by copx 9y ago

Well, to me Rust code looks fundamentally like any other OO language e.g. let mut window: PistonWindow = WindowSettings::new( "piston: hello_world", [200, 200] ) .exit_on_esc(true) .opengl(OpenGL::V2_1) .build() .unwrap(); If you wrote that in C++ or Java or Python or.. it would /could look fundamentally the same. You create a window object and then call a bunch of its methods (mutating its state). That's OOP. I think the Rust people just desperately try to disassociate themselves from the OOP label because OOP is not hip anymore. "So 90s" and all that. I think that's childish. If you use a broad definition of OOP according to which C++, Smalltalk, Java, and Python are all OOP languages said definition certainly covers Rust too. To be fair, even the C++ crowd doesn't like to use the term OOP anymore and instead say things like "generic programming".. but at the end of the day they too are instantiating classes.

dbaupp 9y ago
> I think the Rust people just desperately try to disassociate themselves from the OOP label because OOP is not hip anymore. No, it's mostly driven by the differing semantics despite happening to have similar syntax. Syntax is a surface polish that people focus on a lot, but doesn't drive the core language behaviour.
steveklabnik 9y ago
> it would /could look fundamentally the same. Yeah, the usage does, but the definition does not, the implementation does not, and the features are very different. For example, "new" is just a convention here, not an actual constructor, as Rust does not have constructors. > You create a window object and then call a bunch of its methods (mutating its state). That's OOP. It depends on what you mean by "object". If structs are objects, then OOP boils down to only "you can use x.y() instead of y(x)", which I don't think is a good way to think about programming languages or their features. YMMV, of course. > I think the Rust people just desperately I can assure you, that's not the case for me at least; I love OOP languages enough to have both Ruby and Perl logos tattoo'd onto my body. I don't like saying Rust is OOP because of said definitions elsewhere in the thread, as well as people struggling to map their OOP patterns over. If they hear "Rust is OOP", they expect to be able to do OOP-like things, and when they can't, that's a big frustration. Enough so that we had to add that book chapter.
kibwen 9y ago
"OOP" has suffered since the 90s of being a somewhat vague term in practice (much to the chagrin of Smalltalkers), but making it even more overbroad just to make it apply to Rust will only drive the term further into uselessness. It's not about being "hip", it's about using terminology that's usefully precise. (For the record, I also think "functional programming" is a uselessly broad category these days, having become a victim of its own success.) It's uncontroversial to state that Rust has methods, which are usually associated with OOP. It's also uncontroversial to state that Rust is utterly incapable of defining inheritance hierarchies, which are also usually associated with OOP. If we're going to argue about it, we might as well try to agree on terms that will let us say things that are meaningful.
- copx 9y ago
  It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases. Declaring class inheritance to be the defining feature of OOP just because it was fundamental to 1990s Java courses makes about as much sense as to say extreme late-binding is a fundamental aspect of OOP, like Alan Kay does, and thus neither Java nor C++ are OOP languages. Yippee! Suddenly they are no longer boring, old OOP anymore either! Thanks Alan! You mention FP being a broad category. Indeed it is. Haskell is all about expressive static types, meanwhile Erlang couldn't care less about types. Yet I dare to argue that this broad definition is not "useless" because both Erlang and Haskell default to immutable data and pure functions, and that defines FP more than anything. Practically meaning that Erlang and Haskell tend to be massively closer to each other than they are to imperative languages. The same is the case here. Rust is massively closer to C++ than to Haskell. Mutable ADTs+methods+interfaces, as opposed to free functions and (immutable) "raw" data defines the code style way more than questions like subtype vs. parametic polymorphism If you think that the fact that your dog does not "inherit" from mammal but instead has the mammal "trait", means you are doing a fundamentally different kind of programming, you are wrong. Such differences are of lesser importance in practice.
  - kibwen 9y ago
    > It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases. No argument there. :) > Yet I dare to argue that this broad definition is not "useless" because both Erlang and Haskell default to immutable data and pure functions, and that defines FP more than anything. I think this illustrates what I'm trying to get at: if one's task is to further the tenets of functional programming, then going around espousing "functional programming" as a general concept is less direct than just cutting to the chase and evangelizing for immutability and/or purity directly, especially when one considers that e.g. Common Lisp is neither immutable nor pure, but will be what plenty of people's minds jump to when they think of FP.
sidlls 9y ago
Generic programming and Object Oriented programming may overlap in the margins but are different concepts. Personally I like Rust's better. It feels more like a "better C with generics" than C++ is.

by copx 9y ago

dbaupp 9y ago

> I think the Rust people just desperately try to disassociate themselves from the OOP label because OOP is not hip anymore. No, it's mostly driven by the differing semantics despite happening to have similar syntax. Syntax is a surface polish that people focus on a lot, but doesn't drive the core language behaviour.

steveklabnik 9y ago

> it would /could look fundamentally the same. Yeah, the usage does, but the definition does not, the implementation does not, and the features are very different. For example, "new" is just a convention here, not an actual constructor, as Rust does not have constructors. > You create a window object and then call a bunch of its methods (mutating its state). That's OOP. It depends on what you mean by "object". If structs are objects, then OOP boils down to only "you can use x.y() instead of y(x)", which I don't think is a good way to think about programming languages or their features. YMMV, of course. > I think the Rust people just desperately I can assure you, that's not the case for me at least; I love OOP languages enough to have both Ruby and Perl logos tattoo'd onto my body. I don't like saying Rust is OOP because of said definitions elsewhere in the thread, as well as people struggling to map their OOP patterns over. If they hear "Rust is OOP", they expect to be able to do OOP-like things, and when they can't, that's a big frustration. Enough so that we had to add that book chapter.

kibwen 9y ago

"OOP" has suffered since the 90s of being a somewhat vague term in practice (much to the chagrin of Smalltalkers), but making it even more overbroad just to make it apply to Rust will only drive the term further into uselessness. It's not about being "hip", it's about using terminology that's usefully precise. (For the record, I also think "functional programming" is a uselessly broad category these days, having become a victim of its own success.) It's uncontroversial to state that Rust has methods, which are usually associated with OOP. It's also uncontroversial to state that Rust is utterly incapable of defining inheritance hierarchies, which are also usually associated with OOP. If we're going to argue about it, we might as well try to agree on terms that will let us say things that are meaningful.

copx 9y ago
It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases. Declaring class inheritance to be the defining feature of OOP just because it was fundamental to 1990s Java courses makes about as much sense as to say extreme late-binding is a fundamental aspect of OOP, like Alan Kay does, and thus neither Java nor C++ are OOP languages. Yippee! Suddenly they are no longer boring, old OOP anymore either! Thanks Alan! You mention FP being a broad category. Indeed it is. Haskell is all about expressive static types, meanwhile Erlang couldn't care less about types. Yet I dare to argue that this broad definition is not "useless" because both Erlang and Haskell default to immutable data and pure functions, and that defines FP more than anything. Practically meaning that Erlang and Haskell tend to be massively closer to each other than they are to imperative languages. The same is the case here. Rust is massively closer to C++ than to Haskell. Mutable ADTs+methods+interfaces, as opposed to free functions and (immutable) "raw" data defines the code style way more than questions like subtype vs. parametic polymorphism If you think that the fact that your dog does not "inherit" from mammal but instead has the mammal "trait", means you are doing a fundamentally different kind of programming, you are wrong. Such differences are of lesser importance in practice.
- kibwen 9y ago
  > It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases. No argument there. :) > Yet I dare to argue that this broad definition is not "useless" because both Erlang and Haskell default to immutable data and pure functions, and that defines FP more than anything. I think this illustrates what I'm trying to get at: if one's task is to further the tenets of functional programming, then going around espousing "functional programming" as a general concept is less direct than just cutting to the chase and evangelizing for immutability and/or purity directly, especially when one considers that e.g. Common Lisp is neither immutable nor pure, but will be what plenty of people's minds jump to when they think of FP.

sidlls 9y ago

Generic programming and Object Oriented programming may overlap in the margins but are different concepts. Personally I like Rust's better. It feels more like a "better C with generics" than C++ is.