51 ms·

It's not my area at all, but to my non-expert knowledge the differences between generics and class based inheritance can border on the semantics at times. The

by urthor 5y ago

It's not my area at all, but to my non-expert knowledge the differences between generics and class based inheritance can border on the semantics at times. The high-level concept I always use to think about it is "coupling." Highly coupled data structures, people applying the very complicated solutions from Gang of 4 where it isn't needed. That's the core problem, and Go solves for the problem of "programmers misapplying highly-coupled data structures and doing bad things with Gang of 4 patterns" by explicitly removing that language feature.

Cryptonic 5y ago
Yes and I like inheritance being removed in Rust too. I too think thight coupling is a core problem of many programs, not only introduced by inheritance, but also multiple mutual references, for example in global state based C architectures (most I have seen, the Linux Kernel is better in this regard, CIs used very responsible there). Dependency Inversion (by interface reference or generics or any other technique) is the one pattern that is missing in the Gang of 4 Book and should be the most remembered, not Singleton (the tightest coupling one can introduce in his OOP system is by introducing Singletons). With loose coupling you can run the very same application with a few switched out dependencies on your bare metal embedded device with SPI driven display, on PC with minifb, as a websevice and with mocks in unit tests. I think it's preferable to always aim for loose coupling to enable testing, easier developing and later change. In that respective "Agile Software Development, Principles, Patterns, and Practices" is a much better old school programming book than "Design Patterns" imao (given the latter one is a decade older and the Gang could not have known) Languages that make thight coupling harder definitely teach a good lesson to learners, even if they have then go back to their day job in another language. Thanks for pointing that out.
- urthor 5y ago
  It's funny because I am so far from the OOP world right now, I'm barely qualified to even comment on this topic given how little OOP I've done in the last 3 years. I've literally never done this stuff, but the idea of "coupling causes problems" is hugely important in my domain. I simply think it's important to understand the actual root cause of concepts, and put it into words. Clearly defining your ideas in concrete terms like "coupling" and "K.I.S.S." is really critical to the big picture. Having them as "fuzzy ideas" in the back of your head isn't good enough. Plus coupling as an issue is REALLY clear if you have a good mental model of "every single object is actually a line of hexadecimal going into the evaluator," In which case "a huge bunch of pointers between hexadecimal blocks is bad" makes perfect sense. I guess the other high level concepts would be stuff like "naming things is hard," "pointers = bugs," "design by iterating on MVPs," "mock tests are never useless, write them every time because they *force* you into single responsibility functions." But I'm still figuring out my bank of these ideas.

by urthor 5y ago

Cryptonic 5y ago

Yes and I like inheritance being removed in Rust too. I too think thight coupling is a core problem of many programs, not only introduced by inheritance, but also multiple mutual references, for example in global state based C architectures (most I have seen, the Linux Kernel is better in this regard, CIs used very responsible there). Dependency Inversion (by interface reference or generics or any other technique) is the one pattern that is missing in the Gang of 4 Book and should be the most remembered, not Singleton (the tightest coupling one can introduce in his OOP system is by introducing Singletons). With loose coupling you can run the very same application with a few switched out dependencies on your bare metal embedded device with SPI driven display, on PC with minifb, as a websevice and with mocks in unit tests. I think it's preferable to always aim for loose coupling to enable testing, easier developing and later change. In that respective "Agile Software Development, Principles, Patterns, and Practices" is a much better old school programming book than "Design Patterns" imao (given the latter one is a decade older and the Gang could not have known) Languages that make thight coupling harder definitely teach a good lesson to learners, even if they have then go back to their day job in another language. Thanks for pointing that out.

urthor 5y ago
It's funny because I am so far from the OOP world right now, I'm barely qualified to even comment on this topic given how little OOP I've done in the last 3 years. I've literally never done this stuff, but the idea of "coupling causes problems" is hugely important in my domain. I simply think it's important to understand the actual root cause of concepts, and put it into words. Clearly defining your ideas in concrete terms like "coupling" and "K.I.S.S." is really critical to the big picture. Having them as "fuzzy ideas" in the back of your head isn't good enough. Plus coupling as an issue is REALLY clear if you have a good mental model of "every single object is actually a line of hexadecimal going into the evaluator," In which case "a huge bunch of pointers between hexadecimal blocks is bad" makes perfect sense. I guess the other high level concepts would be stuff like "naming things is hard," "pointers = bugs," "design by iterating on MVPs," "mock tests are never useless, write them every time because they *force* you into single responsibility functions." But I'm still figuring out my bank of these ideas.