5 ms·

No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics. People tie themselves in knots with generics a

• spion 12y ago
  I'd say people tie themselves in inheritance and interface knots more often than generics knots. Especially invariant generics are rather hard to get wrong - they place such constraints on the types that most operations are unavailable.
• mercurial 12y ago
  As somebody using pre-generics Java libraries from time to time, I can say with confidence that generics are not the cause of complexity. Casting from Object is a source of bad type safety and doesn't help with documentation. The complexity you'll find in a mature codebase is a function of the way it is architectured and the complexity inherent to the domain, mostly.
  • NateDad 12y ago
    I wish people wouldn't assume there's only two options - Generics or casting from Object/interface{}/void* It's a straw man argument. No experienced Go programmers are trying to say that's a good way to write code. The idea is to restructure your code so that basic data structures and interfaces pick up the majority of your reuse scenarios.
    • mercurial 12y ago
      I'm no Go programmers, but I relatively often need to take a parametrized basic data structure as storage and write a parametrize class on top of it, while hiding the data structure because it's irrelevant. Well, I guess I'll keep not being a Go programmer :)
• the_af 12y ago
  > People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase. That's not my experience at all. Generics are generally not a source of pain. Do you have any specific examples of your claim?
• tomp 12y ago
  People tie themselves in knots with classes/packages/interfaces/concurrency/computer code all the time. Just look at pretty much any mature codebase at all.