3 ms·

Well I have over 20 years experience so maybe you need 5 more years or so

piva00 3y ago
Reaching 20 years mark here, and I kinda agree and disagree with your initial take. Hear me out, I don't think classes should be used to mutate state, or perform actions on their own. But they are a nice way to namespace and think about components properly. It can be achieved with just structs and functions (strongly typed, for the love of all deities) but giving a container like a class has its advantages to namespace some categories of functions belonging to their own structs. I agree that many other uses of classes (and fucking design patterns piled on top) were, and still are, a major source of pain in software development, I'm very glad to see that a lot of folks around the 15-25 years of experience realised the footguns are not worth it and adapted to write more readable "dumb" code.
- sgarland 3y ago
  > namespace Precisely. I’m a DBRE, not SWE, but I use Python a lot, and have written some internal tooling. Classes as namespacing is wonderful.
  - monero-xmr 3y ago
    Just namespace with folder and file structure. Done
- eyelidlessness 3y ago
  I share your take, and I’ll even say that classes are an underused tool when applying functional principles in mixed paradigm languages. If you use a class as a struct (with value semantics), you get: - A type - A name for it - A canonical way to build a value of that type - A consistent way to reference its semantic meaning at runtime and in any static/build time/documentation format - A singular, easily discoverable place to change it
  - tensor 3y ago
    Most "non-oop" languages like Go and Rust have all of this. They also generally have interfaces. What they don't have is inheritance, which I think is what really differentiates OOP from structs with interfaces.
    - eyelidlessness 3y ago
      Even inheritance of classes-as-structs is probably under-appreciated. It’s not quite as flexible as more general composition. But it’s not nearly as problematic as OOP inheritance, because it’s ultimately only a hierarchical composition of taxonomy and value construction semantics. It can become problematic if you apply the wrong taxonomy, but that would be true without inheritance as well.

Reaching 20 years mark here, and I kinda agree and disagree with your initial take. Hear me out, I don't think classes should be used to mutate state, or perform actions on their own. But they are a nice way to namespace and think about components properly. It can be achieved with just structs and functions (strongly typed, for the love of all deities) but giving a container like a class has its advantages to namespace some categories of functions belonging to their own structs. I agree that many other uses of classes (and fucking design patterns piled on top) were, and still are, a major source of pain in software development, I'm very glad to see that a lot of folks around the 15-25 years of experience realised the footguns are not worth it and adapted to write more readable "dumb" code.

sgarland 3y ago
> namespace Precisely. I’m a DBRE, not SWE, but I use Python a lot, and have written some internal tooling. Classes as namespacing is wonderful.
- monero-xmr 3y ago
  Just namespace with folder and file structure. Done
eyelidlessness 3y ago
I share your take, and I’ll even say that classes are an underused tool when applying functional principles in mixed paradigm languages. If you use a class as a struct (with value semantics), you get: - A type - A name for it - A canonical way to build a value of that type - A consistent way to reference its semantic meaning at runtime and in any static/build time/documentation format - A singular, easily discoverable place to change it
- tensor 3y ago
  Most "non-oop" languages like Go and Rust have all of this. They also generally have interfaces. What they don't have is inheritance, which I think is what really differentiates OOP from structs with interfaces.
  - eyelidlessness 3y ago
    Even inheritance of classes-as-structs is probably under-appreciated. It’s not quite as flexible as more general composition. But it’s not nearly as problematic as OOP inheritance, because it’s ultimately only a hierarchical composition of taxonomy and value construction semantics. It can become problematic if you apply the wrong taxonomy, but that would be true without inheritance as well.