5 ms·

>While C++ had similar goals, it has the disadvantages of multiple legacy design-choices (e.g., object-oriented) How many people agree with this statement? OO

>While C++ had similar goals, it has the disadvantages of multiple legacy design-choices (e.g., object-oriented) How many people agree with this statement? OO is a legacy design choice or in other words: a bad design choice. I agree with the statement, so do most modern languages like rust and golang but I wonder what do non language designers think? This statement was given as if it was obvious but many programmers who I work with still think OO is the greatest invention ever.

pjmlp 9y ago
Go and Rust are also OO. There isn't such thing as the only true and single way of doing OOP. Also without OOP, good luck doing GUI programming in C++. Even Motif and GTK+ are OOP based, in C, because immediate UIs suck for anything beyond simple game UIs.
- BruceIV 9y ago
  [on the Cforall team] FWIW, the Go docs are somewhat ambivalent on the OO nature of Go[1]. Along similar lines, our main objections to object-orientation are that, in "traditional" implementations like C++ or Java, it tightly couples a number of features that we believe would be better served by a more orthogonal design. More specifically, C++-style OO couples (1) in-memory layout of types, (2) behaviour of objects, (3) encapsulation boundaries, and (4) the hierarchical "is-a" relationship. In Cforall, (1) and (3) are handled by the usual C mechanisms of struct types and translation-unit boundaries [we go to great effort to maintain C-style separate compilation, though we will likely build a better namespace/module system at some point], (2) by traits, and (4) by a yet-to-be-implemented system of RTTI for specific "inherited" types [likely when the undergrad RA who started our exceptions implementation comes back as a Master's student this fall]. As you mention, many use-cases (including widgets in GUIs, but also abstract syntax trees in compilers) require some sort of heterogeneous collection type to work properly, and for this OO is the right model. We just don't want to force the entirety of that model on every use case, so we can just take traits when we want to write a polymorphic function over related types or an ADT like "Set" which requires its keys be sortable, or just take RTTI for exception handling, when the set of exception types we're handling is known statically, but we need to determine if the thrown exception inherits from one of the caught types. [1] https://golang.org/doc/faq#Is_Go_an_object-oriented_language https://golang.org/doc/faq#Is_Go_an_object-oriented_language
- crimsonalucard 9y ago
  Modern GUIs happen mostly in JavaScript with the react + redux ecosystem which is more of a functional model then OO.
  - pjmlp 9y ago
    JavaScript uses the same OOP model as SELF, prototype based. It doesn't matter what libraries one uses, they don't remove the OOP model out of JavaScript. Additionally all those react ideas already existed in Smalltalk as well.
    - crimsonalucard 9y ago
      I'm talking about javascript + react + redux. Generally when you use these 3 technologies you avoid javascript oop features.
      - pjmlp 9y ago
        No you don't, because JavaScript is OOP all the way down.
        crimsonalucard 9y ago
        Yes you do, because immutability is recommended by redux. OOP features can be ignored.
        pjmlp 9y ago
        Unless you manage to write JavaScript code without functions and data types, you are using JS OOP features, implemented via prototype based OOP.
        crimsonalucard 9y ago
        No. I'm talking about programming style. I am not talking about how certain JavaScript properties are implemented.
seabrookmx 9y ago
I think OO bashing is just another trendy comment people make. I find it really hypocritical, because the same people that will bash OO in a thread like this will rave about how nice it is to write Python, or are giddy about the latest ES6+ features. Both Python and ES6 have class-based OO, and it is used to great benefit every day. OO can _definitely_ be misused and I think the disconnect is that the traditional abuses of OO (deep class hierarchies, fragile base classes, etc) are associated to "oldschool" Java and C++ codebases. But if developers followed the "composition over inheritance" mantra back then, maybe this complaint wouldn't be so prevalent. I pretty fluidly move between Typescript/C#/GoLang and after the initial hump in GoLang, I find I don't have much preference. Some code feels more clunky without "traditional" OO and some feels better. I've yet to really dive into traits in Rust but I'm guessing I'll feel the same way when I get around to it.
- crimsonalucard 9y ago
  Mantras decrying a built in feature of OO are just flaws within the paradigm. I don't think it's trendy if newer next generation languages like go rust and nim avoid OO. These experts who design languages know something.
  - seabrookmx 9y ago
    I never said it was trendy for languages to not include class-based OO (see most functional languages), I said it was trendy for people to bash it. Like I said, I regularly write Go and don't have trouble with it's interfaces and duck typing. > These experts who design languages know something What about the experts who bolted classes onto ECMAScript? I don't think it's black and white. It's like the static vs. dynamic debate.. there is pros and cons of each approach.
    - crimsonalucard 9y ago
      They didn't bolt classes onto es6. It's more like syntactical sugar over existing features. I think among many language designers starting a whole new language, the issue is indeed black and white.

pjmlp 9y ago

Go and Rust are also OO. There isn't such thing as the only true and single way of doing OOP. Also without OOP, good luck doing GUI programming in C++. Even Motif and GTK+ are OOP based, in C, because immediate UIs suck for anything beyond simple game UIs.

BruceIV 9y ago
[on the Cforall team] FWIW, the Go docs are somewhat ambivalent on the OO nature of Go[1]. Along similar lines, our main objections to object-orientation are that, in "traditional" implementations like C++ or Java, it tightly couples a number of features that we believe would be better served by a more orthogonal design. More specifically, C++-style OO couples (1) in-memory layout of types, (2) behaviour of objects, (3) encapsulation boundaries, and (4) the hierarchical "is-a" relationship. In Cforall, (1) and (3) are handled by the usual C mechanisms of struct types and translation-unit boundaries [we go to great effort to maintain C-style separate compilation, though we will likely build a better namespace/module system at some point], (2) by traits, and (4) by a yet-to-be-implemented system of RTTI for specific "inherited" types [likely when the undergrad RA who started our exceptions implementation comes back as a Master's student this fall]. As you mention, many use-cases (including widgets in GUIs, but also abstract syntax trees in compilers) require some sort of heterogeneous collection type to work properly, and for this OO is the right model. We just don't want to force the entirety of that model on every use case, so we can just take traits when we want to write a polymorphic function over related types or an ADT like "Set" which requires its keys be sortable, or just take RTTI for exception handling, when the set of exception types we're handling is known statically, but we need to determine if the thrown exception inherits from one of the caught types. [1] https://golang.org/doc/faq#Is_Go_an_object-oriented_language https://golang.org/doc/faq#Is_Go_an_object-oriented_language
crimsonalucard 9y ago
Modern GUIs happen mostly in JavaScript with the react + redux ecosystem which is more of a functional model then OO.
- pjmlp 9y ago
  JavaScript uses the same OOP model as SELF, prototype based. It doesn't matter what libraries one uses, they don't remove the OOP model out of JavaScript. Additionally all those react ideas already existed in Smalltalk as well.
  - crimsonalucard 9y ago
    I'm talking about javascript + react + redux. Generally when you use these 3 technologies you avoid javascript oop features.
    - pjmlp 9y ago
      No you don't, because JavaScript is OOP all the way down.
      - crimsonalucard 9y ago
        Yes you do, because immutability is recommended by redux. OOP features can be ignored.
        pjmlp 9y ago
        Unless you manage to write JavaScript code without functions and data types, you are using JS OOP features, implemented via prototype based OOP.
        crimsonalucard 9y ago
        No. I'm talking about programming style. I am not talking about how certain JavaScript properties are implemented.

seabrookmx 9y ago

I think OO bashing is just another trendy comment people make. I find it really hypocritical, because the same people that will bash OO in a thread like this will rave about how nice it is to write Python, or are giddy about the latest ES6+ features. Both Python and ES6 have class-based OO, and it is used to great benefit every day. OO can _definitely_ be misused and I think the disconnect is that the traditional abuses of OO (deep class hierarchies, fragile base classes, etc) are associated to "oldschool" Java and C++ codebases. But if developers followed the "composition over inheritance" mantra back then, maybe this complaint wouldn't be so prevalent. I pretty fluidly move between Typescript/C#/GoLang and after the initial hump in GoLang, I find I don't have much preference. Some code feels more clunky without "traditional" OO and some feels better. I've yet to really dive into traits in Rust but I'm guessing I'll feel the same way when I get around to it.

crimsonalucard 9y ago
Mantras decrying a built in feature of OO are just flaws within the paradigm. I don't think it's trendy if newer next generation languages like go rust and nim avoid OO. These experts who design languages know something.
- seabrookmx 9y ago
  I never said it was trendy for languages to not include class-based OO (see most functional languages), I said it was trendy for people to bash it. Like I said, I regularly write Go and don't have trouble with it's interfaces and duck typing. > These experts who design languages know something What about the experts who bolted classes onto ECMAScript? I don't think it's black and white. It's like the static vs. dynamic debate.. there is pros and cons of each approach.
  - crimsonalucard 9y ago
    They didn't bolt classes onto es6. It's more like syntactical sugar over existing features. I think among many language designers starting a whole new language, the issue is indeed black and white.