It's worth noting that "slow compilation" often translates directly into "slow programmers".
What's wrong with using both approaches: debug binaries get compiled with boxing generics, while release compiles using macros?
The Generic Dilemma in Go
11–20 of 26 posts
Re: The Generic Dilemma in Go
#12Where does the Haskell type system fit into his description?
There are a whole host of ways that Haskell supports (or has been extended to support) generic programming. There's a big overview here: http://www.haskell.org/haskellwiki/Research_papers/Generics In the simplest case, generic programming in Haskell is done using type classes (similar to OO "interfaces"), often with the GHC extension for derivable type classes. If I understand correctly, this is generally implemented…
No, the simplest case for Haskell would be type variables. For example, the map function doesn't need typeclasses at all:
map :: (a -> b) -> [a] -> [b]
For the record, in Go+generics, this might look something like:
func map(f func (A) B, xs A[]) B[] { ... }
Re: The Generic Dilemma in Go
#13I'd like to hear a compelling justification for generics in a language where you can add methods to any type, and every type implements an interface just by implementing all of the methods. I suspect that all of the reasons have to do with compile-time checks. (But in the domains where I do my work, it's fine to get by with runtime checking, so I admit I don't have complete in-depth knowledge on the subject.)
How about letting the programmer have it both ways? Let the programmer request either macro expansion or implicit boxing. The default would be implicit boxing, which would allow for fast compilation. The programmer could then specify macro expansion for certain specific types. This enables both rapid initial development and optimization and generation of compact runtime representations and fast code.
Re: The Generic Dilemma in Go
#14It's worth noting that "slow compilation" often translates directly into "slow programmers".
What's wrong with using both approaches: debug binaries get compiled with boxing generics, while release compiles using macros?
Or have the former as the default, and allow the programmer to opt for the second, if the optimization is needed?
Re: The Generic Dilemma in Go
#15Where does the Haskell type system fit into his description?
In the most general case it uses boxing strategies, but it's also able to behave like C++ with certain compile-time optimizations turned on (at the cost of slowing down compilation). There's a lot of literature out there about how to take advantage of those optimizations. It's a fairly involved topic.
Re: The Generic Dilemma in Go
#16I'd like to hear a compelling justification for generics in a language where you can add methods to any type, and every type implements an interface just by implementing all of the methods. I suspect that all of the reasons have to do with compile-time checks. (But in the domains where I do my work, it's fine to get by with runtime checking, so I admit I don't have complete in-depth knowledge on the subject.) How abo…
Having a vector or map collection where you can call methods etc. on elements without having to do a typecast, and know that the method call will work (i.e. is statically typed), is useful. It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection.
If you don't understand the benefits of static typing, it's likely that you won't understand why generics can be preferable to polymorphism in containers.
Re: The Generic Dilemma in Go
#17I'd like to hear a compelling justification for generics in a language where you can add methods to any type, and every type implements an interface just by implementing all of the methods. I suspect that all of the reasons have to do with compile-time checks. (But in the domains where I do my work, it's fine to get by with runtime checking, so I admit I don't have complete in-depth knowledge on the subject.) How abo…
Having a vector or map collection where you can call methods etc. on elements without having to do a typecast, and know that the method call will work (i.e. is statically typed), is useful. It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection. If you don't understand the benefits of static typing, it's likely that you won't understand why generics can be p…
[deleted]
Re: The Generic Dilemma in Go
#18I wish we could get back to using "Go" as a reference to the board game.
I agree. I got way too excited seeing multiple articles about Go in HN, but started wondering a moment later why there would be more than one such article about a board game, as wonderful as it is.
Re: The Generic Dilemma in Go
#19I'd like to hear a compelling justification for generics in a language where you can add methods to any type, and every type implements an interface just by implementing all of the methods. I suspect that all of the reasons have to do with compile-time checks. (But in the domains where I do my work, it's fine to get by with runtime checking, so I admit I don't have complete in-depth knowledge on the subject.) How abo…
Here you 'go': http://golang.org/src/pkg/sort/sort.go
http://golang.org/doc/go_spec.html#Type_assertions is possible, but it is costly. Basically, you either have to go through the tedium of writing "convenience" boiler plate (per above sort.go) or bite the runtime hit.
Re: The Generic Dilemma in Go
#20I wish we could get back to using "Go" as a reference to the board game.
Way back when I played go with a few friends in college, we started calling it "baduk" (the Korean term) because the term "go" always took a second to register if you weren't already expecting it based on context. It's a really unfortunate word to try to borrow into English. To name a language "Go" when they knew most of their users would discuss it in English was just stupid.