6 ms·
And also: "Minus all the OOP, and then some."
by aldanor 6y ago
And also: "Minus all the OOP, and then some."
- saagarjha 6y agoModern C++ generally doesn’t use OOP all that much anyways. However, <algorithm> and <type_traits> in Rust’s standard library would be quite nice to have.
- pjmlp 6y agoOther than the classes used to implement all those STL concepts.
- johannes1234321 6y agoTypes are being used to create those things. But it's not OOP as many people understand it. (Inheritance, everything via method calls etc.)
- pjmlp 6y agoPeople should spend more time learning what OOP actually is all about, hint it isn't just MFC and Qt.
- gpderetta 6y agoif STL is OO then everything is OO.
- pjmlp 6y agoThen remove the classes, static inheritance via template arguments, method dispatch via type parameters (very CLOS like), class member functions, iostreams, ..... Plenty of SIGPLAN papers to one educate themselves about what OOP is all about. OOP is not MFC alone, apparently those that learn languages on the trenches without referring to them, never get to appreciate the wealth of information we have available. Not surprising, given how many misunderstand "whatever my compiler does" for what ISO actually says.
- gpderetta 6y agoOO is a very nebulously defined term and if you ask two people you'll get three different definitions. But I would say that most people will agree that at the very least late binding is a fundamental component.
- pjmlp 6y agoHence why having a proper CS education is an very important pillar for any good engineering degree. Back to STL, it makes heavy use at compile time method dispatch via template metaprogramming and lambdas (which are implemented as classes actually by the compiler.
- gpderetta 6y agoStepanov has forgotten more about CS than I'll ever learn in an hundreds lifetimes and he is pretty adamant that STL is no OO [1]. I know this is an argumentum ab auctoritate, but you didn't really provide an argument either :) [1] http://www.stlport.org/resources/StepanovUSA.html http://www.stlport.org/resources/StepanovUSA.html
- jcelerier 6y ago> if STL is OO then everything is OO. I mean... in the sense in which most people use "OO language" (which is, "a language with constructs which associates a data specification with procedures"), yes. Only hardcore pure-functional algorithms written in Haskell / ML without typeclasses, or things like Prolog, Esterel (though thinking about it), and similar research languages aren't. Once upon a time programming looked like this. https://github.com/chrislgarry/Apollo-11/blob/master/Luminary099/FRESH_START_AND_RESTART.agc https://github.com/chrislgarry/Apollo-11/blob/master/Luminar...
- tom_mellior 6y agoThis is such a lazy form of "argument". If you have knowledge, share it, or at least share concrete references to concrete resources where one might learn what you think should be learned. If you put it in this nebulous way, people might look up the meaning of OOP in some source you don't approve of, which wouldn't help communicate what you think should be communicated.
- pjmlp 6y agoStart here, "Object-oriented programming: Some history, and challenges for the next fifty years" https://www.sciencedirect.com/science/article/pii/S0890540113000795 https://www.sciencedirect.com/science/article/pii/S089054011... Than read on BETA design for example, https://beta.cs.au.dk/ https://beta.cs.au.dk/ Follow up with "The Art of the Metaobject Protocol", https://mitpress.mit.edu/books/art-metaobject-protocol https://mitpress.mit.edu/books/art-metaobject-protocol and "Xerox LOOPS" http://www.softwarepreservation.org/projects/LISP/interlisp_family/ http://www.softwarepreservation.org/projects/LISP/interlisp_... Then "Component Software: Beyond Object-Oriented Programming" (the 1st edition with Component Pascal) https://www.amazon.com/Component-Software-Beyond-Object-Oriented-Programming-dp-0201178885/dp/0201178885 https://www.amazon.com/Component-Software-Beyond-Object-Orie... "Applying Traits to the Smalltalk Collection Classes" https://rmod.inria.fr/archives/papers/Blac03a-OOSPLA03-TraitsHierarchy.pdf https://rmod.inria.fr/archives/papers/Blac03a-OOSPLA03-Trait... "Self – The Power of Simplicity" http://media.cichon.com/talks/Introduction_Self_Language_OOP-1-23-2003.pdf http://media.cichon.com/talks/Introduction_Self_Language_OOP... https://blog.rfox.eu/en/Programming/Series_about_Self/index.html https://blog.rfox.eu/en/Programming/Series_about_Self/index.... How about this for starters?
- discreteevent 6y agoAlan Kay https://news.ycombinator.com/item?id=11940050 https://news.ycombinator.com/item?id=11940050 On Understanding Data Abstraction Revisited https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf The Power of Interoperability: why objects are inevitable https://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf https://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf A closure is a poor man's object http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- est31 6y agoWhat would be a use case for using type_traits? It feels to me that most cases for it would be frowned upon in Rust, but that's just my gut feeling, not knowing what they are useful for in C++-
- secondcoming 6y agoThey provide the compiler metadata about a type. For example if you have a std::vector<int>, there is a value_type trait for this that deduces to int, i.e. 'this vector holds ints'.
- est31 6y agoHmmm I see. Reading up on it it seems to enable generic code deduce info or assume info about stuff (as in assert). Rust uses proper traits for that instead, basically having lifted traits to a first-class language feature. But there is only a barebones set of traits available in the standard library, mostly the ones needed for language or std features. Any traits only needed for generic libraries are left to crates to implement.
- aldanor 6y agoThe difference here is that, C++ templates are closer to just "string replacement", as they're not validated (basic syntax aside) until you instantiate them. As such, in C++, your generic type T can be whatever the user decides to stick in there (you can't prevent them doing that), and so you typically have a chance of disabling/enabling certain bits of code by checking various type traits and using hacks like sfinae etc (e.g., "if T is an enum - please use this version of this method; otherwise - substitute this version of the same method", this would be quite typical and idiomatic in C++). In Rust, generic code is fully validated as it should be, with all trait bounds being matched where need be. So you would rarely end up with needing to figure (at compile time) whether generic type T is an enum or not - because it wouldn't allow you to do anything extra with it out of the box. In Rust, an idiomatic way of adding different behaviours based on the kind of the generic type would be using traits still - e.g., you can have multiple impl blocks on your generic type, each one having different trait bounds on the generic parameter, like - if T: Copy, then implement these extra methods; standard library has tons of examples like this. The only exception that comes to mind is proc macros - when you deal with Rust code in AST form and generate new code at pre-compile-time phase, but that's a completely different story and not really related.
- pjmlp 6y agoTraits are OOP, check out on Objective-C and CLOS/Flavors protocols, Smalltalk categories, alongside a couple of SIGPLAN papers on component programming.
- vbarrielle 6y agoHaskell typeclasses are quite close to Rust traits, does Haskell count as OOP then?
- pjmlp 6y agoYes, Haskell has all the necessary features to implement some forms of OOP. There are plenty of OOP flavours, just like there are plenty of FP flavours. If one considers 100% Haskell's features as must have for a language to be considered FP, then OCaml and Standard ML are going to have a hard time to be considered FP.
- int_19h 6y agoIIRC, Haskell doesn't have the notion of object identity. It wouldn't make sense in an immutable language, anyway, because identity only matters if object state can change - otherwise any two objects with identical state are substitutable. But anyway, I would argue that this is the crucial difference that sets apart "objects" and "values with syntactic sugar for function calls".
- ncmncm 6y agoAldanor has an important point here, in the "and the some". Rust is deliberately a weaker language for expressing library semantics. You can write libraries in C++ that cannot be written in Rust, that encapsulate semantics that cannot be captured in Rust. C++ library writers do, routinely. The C++ Standard Library has many components that could not be coded in Rust, that make the language more powerful for all users. This makes Rust easier to learn, but it limits the libraries you can use, having learned it, and limits the libraries you can write. This is a difficult tradeoff for any language design. Haskell is more powerful, too, and also harder to learn and to use well. (At the same time, its lack of destructors also limits it in ways that Rust and C++ do not suffer.) The OOP -- inheritance, and virtual functions -- is a niche feature that is sometimes useful, but can often be emulated well enough with function pointers.
- Ar-Curunir 6y agoWhat libraries do you have in mind?
- ncmncm 6y agohttp://cppreference.com/w/cpp http://cppreference.com/w/cpp
- int_19h 6y agoRust has virtual method dispatch. What else do you need to call it OO? If it's implementation inheritance, then that was never a requirement for OO, seeing how prototype-based OO has been around for a very long time.