3 ms·

> The reality is that generics aren't free. They result in difficult-to-understand error messages and more cognitive complexity. > To quote Yossi Krenin, "You

> The reality is that generics aren't free. They result in difficult-to-understand error messages and more cognitive complexity. > To quote Yossi Krenin, "You may think it's a StringToStringMap, but only until the tools enlighten you - it's actually more of a... std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >" The Kreinin quote is in relation to C++. For historical reasons (reverse compatibility with C) and interoperability with other parts of the language (manual memory management), C++ types are way more complicated than types in a more recent language such as C#, where a Map<string,string> is really not much more complicated than you would think it would be. One might be able to argue that generics make things more complicated, but they certainly don't have to make them as complicated as C++ does.

colin_mccabe 13y ago
You can't blame C++ generics on compatibility with C, because C doesn't have them. The culprit isn't manual memory management either. The issue is just that the complexity of the type grows exponentially as you compose more generic types together. The string was templated on three things: the character type (usually char), the traits, and the allocator. Fair enough, but now the map is templated on the key type, the value type, the comparator, and the alocator. So that's 4 x 3 x 3 = 36 different parts in the StringToStringMap. Java has similar "russian doll" types where you have many different layers of generics within generics. You need to read all of them to fully understand the behavior. To be honest, overuse of generics is a code smell in both C++ and Java. One of the early warning signs that your code might have this problem is if you feel the urge to template on bool. I do think that generics may come to Go some day, but I think it will require a lot of thought, and it may not come in quite the same form as it did for Java and C++. No doubt there will be many angry posts about how Go "has" to do it the C++/Java way at that point.
- eru 13y ago
  > The issue is just that the complexity of the type grows exponentially as you compose more generic types together. Haskell handles this just fine. So we can blame it on C++. (I don't know whether it has anything to do with memory management, or C compatibility.)
  - colin_mccabe 13y ago
    I don't know Haskell, but I do know OCaml, a strongly, statically-typed language with type inference. OCaml does avoid a lot of the pitfalls of C++, but it shares the problem of difficult to decode error messages. Oh boy, does it ever. Adding explicit type specifications helped a little bit. Adding parentheses around everything helped a little bit more. For some reason, the parentheses trick seems to be little-known online, but it's something I really had to do sometimes in OCaml. I once spent a half hour trying to figure out why a file was getting a parse error at the end. I eventually did a kind of binary search, commenting out half of the file at a time until I could narrow it down. It was a missing brace halfway through. The problem is that without the need to put all functions in the top-level, things just float in a sea of declarations, and if two things are next to one another, it's assumed to be curried... and so your error message about a missing brace shows up on a line number far removed from the actual problem. It's possible that with more development effort put into the language, OCaml and other functional programming languages would have better compiler error messages. It's also possible that there's just a fundamental difficulty trying to teach a profoundly stupid computer to give reasonable error messages about a super-clever system. Hopefully the popularity of functional languages like Scala and OCaml will give us a chance to find out the answer to tihs.
    - nostrademons 13y ago
      Clang has excellent error messages for C++ - it even spellchecks your code and can suggest the function you meant to type when you typo something. So this is almost certainly a case of development effort, and not something intrinsic to the type system.

colin_mccabe 13y ago

You can't blame C++ generics on compatibility with C, because C doesn't have them. The culprit isn't manual memory management either. The issue is just that the complexity of the type grows exponentially as you compose more generic types together. The string was templated on three things: the character type (usually char), the traits, and the allocator. Fair enough, but now the map is templated on the key type, the value type, the comparator, and the alocator. So that's 4 x 3 x 3 = 36 different parts in the StringToStringMap. Java has similar "russian doll" types where you have many different layers of generics within generics. You need to read all of them to fully understand the behavior. To be honest, overuse of generics is a code smell in both C++ and Java. One of the early warning signs that your code might have this problem is if you feel the urge to template on bool. I do think that generics may come to Go some day, but I think it will require a lot of thought, and it may not come in quite the same form as it did for Java and C++. No doubt there will be many angry posts about how Go "has" to do it the C++/Java way at that point.

eru 13y ago
> The issue is just that the complexity of the type grows exponentially as you compose more generic types together. Haskell handles this just fine. So we can blame it on C++. (I don't know whether it has anything to do with memory management, or C compatibility.)
- colin_mccabe 13y ago
  I don't know Haskell, but I do know OCaml, a strongly, statically-typed language with type inference. OCaml does avoid a lot of the pitfalls of C++, but it shares the problem of difficult to decode error messages. Oh boy, does it ever. Adding explicit type specifications helped a little bit. Adding parentheses around everything helped a little bit more. For some reason, the parentheses trick seems to be little-known online, but it's something I really had to do sometimes in OCaml. I once spent a half hour trying to figure out why a file was getting a parse error at the end. I eventually did a kind of binary search, commenting out half of the file at a time until I could narrow it down. It was a missing brace halfway through. The problem is that without the need to put all functions in the top-level, things just float in a sea of declarations, and if two things are next to one another, it's assumed to be curried... and so your error message about a missing brace shows up on a line number far removed from the actual problem. It's possible that with more development effort put into the language, OCaml and other functional programming languages would have better compiler error messages. It's also possible that there's just a fundamental difficulty trying to teach a profoundly stupid computer to give reasonable error messages about a super-clever system. Hopefully the popularity of functional languages like Scala and OCaml will give us a chance to find out the answer to tihs.
  - nostrademons 13y ago
    Clang has excellent error messages for C++ - it even spellchecks your code and can suggest the function you meant to type when you typo something. So this is almost certainly a case of development effort, and not something intrinsic to the type system.