4 ms·

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

by spion 12y ago

tomlu 12y ago
They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).
- nf 12y ago
  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 all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
  - 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.
- sriku 12y ago
  That's a weird stance. If there are complexities that programmers face that can be absorbed by a compiler, it must be, because that would pay off for every programmer , in every project, in every bug prevented.
  - latch 12y ago
    In the Go FAQ [1], when they list the purpose of the project, the first answer they give isn't about concurrency (as some might suspect), it's: "It is possible to compile a large Go program in a few seconds on a single computer." They've been consistent about this. It's a major design goal and, for some, compilation speed is worth more than support for Generics. [1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project http://golang.org/doc/faq#What_is_the_purpose_of_the_project
    - gnuvince 12y ago
      And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.
      - enneff 12y ago
        I'll say it again: Go doesn't have generics because of implementation complexity. The tradeoff was against the additional complexity that our users would have to deal with.
        gnuvince 12y ago
        I was only addressing the comment of the parent that suggested adding parametric polymorphism would kill compiler performance.
        mlatu 12y ago
        right, because a big codebase to deal with the lack of generics doesnt add complexity at all. you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.
rdtsc 12y ago
I think trade-offs have been made already. If they bring in "generics" they would have to back-pedal and now many in the community would have to in a way refute their previous excuses of why they didn't need generics. ("But I have been arguing on public forums for the last 2 years that generics are not useful, what do you mean we'll now implement generics....") There is also a chance that it will slow down compilation and or runtime. Java, C++ and other code compiles slower. Is it because those languages are stupid and slow and made by idiots? Not necessarily, it is because they have more features. Many added later (with added complexity of keeping backwards compatibility). The fear I think, is if Go gains those new features, its compilation and/or execution speed or claims of simplicity will not hold any more.
- enneff 12y ago
  You have it all backwards. We didn't build Go in order to have arguments on a mailing list. And I don't think the people saying "I don't need generics," are lying. I think they actually believe what they say, and I'm sure if we did introduce generics today many of them would say "I think this is a mistake." Yes, the tradeoffs have been made. The language has been designed. It is very unlikely that Go 1.x will see generics. Yes, any new language feature may slow down the compilers and/or runtime. Go values compilation and execution speed highly very highly. To include any new language feature we would assess whether it is worth the various costs; that much is obvious. But there are technical reasons why C++ and Java could never compile as fast as Go, and they have nothing to do with generics. Go's dependency model is the main reason it can build fast. And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along.
  - rdtsc 12y ago
    > And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along. Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more. > We didn't build Go in order to have arguments on a mailing list. Not sure many popular languages were built for that. But arguments on mailing lists is what you get. Quite often the smarter people are, the better they are able to veil things like disappointments, personal dislikes, and others in technical arguments. I have seen it in private meetings and public discussion forums. The inertia of defending something vigorously and then having to back-pedals is unpleasant.

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

by spion 12y ago

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

tomlu 12y ago

They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).

nf 12y ago
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 all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
- 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.
sriku 12y ago
That's a weird stance. If there are complexities that programmers face that can be absorbed by a compiler, it must be, because that would pay off for every programmer , in every project, in every bug prevented.
- latch 12y ago
  In the Go FAQ [1], when they list the purpose of the project, the first answer they give isn't about concurrency (as some might suspect), it's: "It is possible to compile a large Go program in a few seconds on a single computer." They've been consistent about this. It's a major design goal and, for some, compilation speed is worth more than support for Generics. [1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project http://golang.org/doc/faq#What_is_the_purpose_of_the_project
  - gnuvince 12y ago
    And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.
    - enneff 12y ago
      I'll say it again: Go doesn't have generics because of implementation complexity. The tradeoff was against the additional complexity that our users would have to deal with.
      - gnuvince 12y ago
        I was only addressing the comment of the parent that suggested adding parametric polymorphism would kill compiler performance.
      - mlatu 12y ago
        right, because a big codebase to deal with the lack of generics doesnt add complexity at all. you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.

rdtsc 12y ago

I think trade-offs have been made already. If they bring in "generics" they would have to back-pedal and now many in the community would have to in a way refute their previous excuses of why they didn't need generics. ("But I have been arguing on public forums for the last 2 years that generics are not useful, what do you mean we'll now implement generics....") There is also a chance that it will slow down compilation and or runtime. Java, C++ and other code compiles slower. Is it because those languages are stupid and slow and made by idiots? Not necessarily, it is because they have more features. Many added later (with added complexity of keeping backwards compatibility). The fear I think, is if Go gains those new features, its compilation and/or execution speed or claims of simplicity will not hold any more.

enneff 12y ago
You have it all backwards. We didn't build Go in order to have arguments on a mailing list. And I don't think the people saying "I don't need generics," are lying. I think they actually believe what they say, and I'm sure if we did introduce generics today many of them would say "I think this is a mistake." Yes, the tradeoffs have been made. The language has been designed. It is very unlikely that Go 1.x will see generics. Yes, any new language feature may slow down the compilers and/or runtime. Go values compilation and execution speed highly very highly. To include any new language feature we would assess whether it is worth the various costs; that much is obvious. But there are technical reasons why C++ and Java could never compile as fast as Go, and they have nothing to do with generics. Go's dependency model is the main reason it can build fast. And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along.
- rdtsc 12y ago
  > And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along. Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more. > We didn't build Go in order to have arguments on a mailing list. Not sure many popular languages were built for that. But arguments on mailing lists is what you get. Quite often the smarter people are, the better they are able to veil things like disappointments, personal dislikes, and others in technical arguments. I have seen it in private meetings and public discussion forums. The inertia of defending something vigorously and then having to back-pedals is unpleasant.