12 ms·

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!

masklinn 9y ago
> perhaps they can read the literature of the past 30yrs 40, nearing on 45: > Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)
- endymi0n 9y ago
  Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.
  - masklinn 9y ago
    > Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.
  - pcwalton 9y ago
    The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists—it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (either manually or with go generate), while the boxing approach is done with interface{}. Adding generics to the language just automates one or both of the approaches. The idea that the monomorphization/boxing tradeoff can be dodged by not having generics in the language is a fallacy. In Go, today, you as a programmer already have to decide which side of the tradeoff you want every time you write something that could be generic. It's just that the compiler doesn't help you at all.
    - masklinn 9y ago
      > The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types. Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap).
      - slrz 9y ago
        The FAQ entry does not state that the Go compiler boxes escaping variables (it doesn't, AFAICT). How did you arrive at that conclusion?
    - willtim 9y ago
      In Haskell (and I believe Scala), one can use pragma hints to specify to the compiler when to specialise, if performance becomes a problem. So I don't see this as an argument against parametric polymorphism.
    - vram22 9y ago
      >monomorphization Does that mean writing a separate version of an algorithm for each type or types that you want it to handle? Like a sort for ints, a sort for floats, etc., even if the logic is otherwise the same (or almost)? Not a PL design or theory expert, just interested.
- fmap 9y ago
  Nitpick, but the idea is even older, going back at least to Girard (1971) and Reynolds (1974). :) I don't know exactly what the problem is for Go. There are tradeoffs, e.g., just with the type system: impredicative, stratified or predicative quantification, implicit subtyping or explicit type instantiation, value restrictions, variance handling for mutable inductive types, Hindley-Milner or bidirectional typechecking, etc. There are more tradeoffs with the implementation. Fortunately, these are all well understood by now. However, it is also true that many mainstream languages famously got generics wrong. What's most infurating about this situation is that a lot of research just gets ignored. If the question is really "should Go have generics whose design is based on C++ templates and/or Java generics" then the only sane answer is a resounding no.
pjmlp 9y ago
You forgot CLU in 1975. :)
seanwilson 9y ago
> If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Yeah, I find it strange how languages are trending at a glacially slow pace to having the same features that strongly typed functional programming languages have had for literally decades. It's like we're going to be using actual functional programming languages eventually but the only way it'll happen is to very slowly change what everyone is currently using in small steps. Static types, immutability, type inference and non-null variables are popular design choices right now but they've been in functional programming languages for nearly 50 years. I'm still waiting for inductive types and pattern matching to turn up in a mainstream language and seeing them talked about like they're new concepts.
- JBReefer 9y ago
  C# is adding pattern matching in the upcoming release, and to your point, people are acting like it's the new hotness.
  - masklinn 9y ago
    That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. Source: got to interact with the community between the C# 1.0 and 4.0 releases (2.0 added generics, 3.0 added lambdas, neither feature was considered of any use to a Productive Developer up to the day when Microsoft officially announced them).
    - seanmcdirmid 9y ago
      > That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. That isn't true inside Microsoft. Many of the people who work on C# are the same academic wanks that work on Scala or F#. C# has a different user base from those languages though, so they still have to be careful what they add to the language, and many language features are planned 3 or 4 versions in advance.
anth1988 9y ago
> perhaps they can read the literature of the past 30yrs You realize this post is talking about Go right? /s
lngnmn 9y ago
The classic Wizards lecture on generic '+ is good enough argument. The numeric tower of lisps is the canonical use case of what generic functions are good for. Smalltalk, the second greatest language after Lisp, is also good example.

masklinn 9y ago

> perhaps they can read the literature of the past 30yrs 40, nearing on 45: > Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)

endymi0n 9y ago
Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.
- masklinn 9y ago
  > Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.
- pcwalton 9y ago
  The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists—it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (either manually or with go generate), while the boxing approach is done with interface{}. Adding generics to the language just automates one or both of the approaches. The idea that the monomorphization/boxing tradeoff can be dodged by not having generics in the language is a fallacy. In Go, today, you as a programmer already have to decide which side of the tradeoff you want every time you write something that could be generic. It's just that the compiler doesn't help you at all.
  - masklinn 9y ago
    > The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types. Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap).
    - slrz 9y ago
      The FAQ entry does not state that the Go compiler boxes escaping variables (it doesn't, AFAICT). How did you arrive at that conclusion?
  - willtim 9y ago
    In Haskell (and I believe Scala), one can use pragma hints to specify to the compiler when to specialise, if performance becomes a problem. So I don't see this as an argument against parametric polymorphism.
  - vram22 9y ago
    >monomorphization Does that mean writing a separate version of an algorithm for each type or types that you want it to handle? Like a sort for ints, a sort for floats, etc., even if the logic is otherwise the same (or almost)? Not a PL design or theory expert, just interested.
fmap 9y ago
Nitpick, but the idea is even older, going back at least to Girard (1971) and Reynolds (1974). :) I don't know exactly what the problem is for Go. There are tradeoffs, e.g., just with the type system: impredicative, stratified or predicative quantification, implicit subtyping or explicit type instantiation, value restrictions, variance handling for mutable inductive types, Hindley-Milner or bidirectional typechecking, etc. There are more tradeoffs with the implementation. Fortunately, these are all well understood by now. However, it is also true that many mainstream languages famously got generics wrong. What's most infurating about this situation is that a lot of research just gets ignored. If the question is really "should Go have generics whose design is based on C++ templates and/or Java generics" then the only sane answer is a resounding no.

pjmlp 9y ago

You forgot CLU in 1975. :)

seanwilson 9y ago

> If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Yeah, I find it strange how languages are trending at a glacially slow pace to having the same features that strongly typed functional programming languages have had for literally decades. It's like we're going to be using actual functional programming languages eventually but the only way it'll happen is to very slowly change what everyone is currently using in small steps. Static types, immutability, type inference and non-null variables are popular design choices right now but they've been in functional programming languages for nearly 50 years. I'm still waiting for inductive types and pattern matching to turn up in a mainstream language and seeing them talked about like they're new concepts.

JBReefer 9y ago
C# is adding pattern matching in the upcoming release, and to your point, people are acting like it's the new hotness.
- masklinn 9y ago
  That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. Source: got to interact with the community between the C# 1.0 and 4.0 releases (2.0 added generics, 3.0 added lambdas, neither feature was considered of any use to a Productive Developer up to the day when Microsoft officially announced them).
  - seanmcdirmid 9y ago
    > That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. That isn't true inside Microsoft. Many of the people who work on C# are the same academic wanks that work on Scala or F#. C# has a different user base from those languages though, so they still have to be careful what they add to the language, and many language features are planned 3 or 4 versions in advance.

anth1988 9y ago

> perhaps they can read the literature of the past 30yrs You realize this post is talking about Go right? /s

lngnmn 9y ago

The classic Wizards lecture on generic '+ is good enough argument. The numeric tower of lisps is the canonical use case of what generic functions are good for. Smalltalk, the second greatest language after Lisp, is also good example.