6 ms·
What's embarrassing is that people are still evaluating programming languages like they were bags of features. The more features you stuff in the bag, the bett
by colin_mccabe 13y ago
What's embarrassing is that people are still evaluating programming languages like they were bags of features. The more features you stuff in the bag, the better it must be!
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> > > > >"
Of course, it would be nice to have generics, or something like them, for writing typesafe containers. But there are other goals in the language like fast compilation, easy-to-understand error messages, and overall simplicity. I hope they can come up with an implementation of generics that can keep those good properties of the language. But if they can't, it shouldn't be added just to get a feature bullet point. Use the right tool for the job.
- alok-g 13y agoI am not convinced that C++ examples are valid as a generalization of the failures of generics for other languages. C++ libraries are often overly generalized with means to "configure" the generics by passing additional type arguments. I do not think it has to be like that.
- davidcuddeback 13y agoC++ templates are also latently typed. The bad error messages arise from the fact that C++ templates behave more like a duck-typed language than a strongly-typed language. Look at the error messages that arise from C++ template errors and a lot of them are about missing functions, just like you get at runtime when you have a type error is a dynamically-typed language. I think C++ concepts will improve this when they're standardized, because they will allow C++ compilers to type-check template arguments. (See bounded polymorphism.)
- AnthonyMouse 13y agoSome of it is also the fault of the compilers for being too explicit in their default error messages. You get that horrible output because string is really a typedef to "basic_string<char>" and basic_string takes two more template arguments with defaults. But why is the compiler resolving the typedef in the error message by default? At least let it be "std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >" instead of that inscrutable noise. And if you really need to provide the information that "std::string" is "std::basic_string<char, std::char_traits<char>, std::allocator<char> >" then put it on a separate line in the output, once, instead of repeating it internally within every recursive template instantiation.
- nikbackm 13y agoMaybe the typedef:s have been resolved and discarded at the point in compilation where the error is reported? So using it in the error message would require extra work.
- rapala 13y agoSo why do we pass that work from the compiler,the tool, to the programmer? Except that I think I know the reason, as I have looked upon the specification and it was not sane.
- kerkeslager 13y ago> 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 agoYou 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
- stinos 13y agoWhat's embarrassing is that people are still evaluating programming languages like they were bags of features. The more features you stuff in the bag, the better it must be! well in some cases your platform only support one language, or maybe to. So it makes a lot of sense to then evaluate tha language as a whole. Even then, I don't see much wrong with evalulating a language as abag of features as long as you don't simply consider the amount of features but rather it's quality. The reality is that generics aren't free. No, but I noticed that the end, once you know how to use them properly and become used to them, they tend to become invaluable, even to a point that programmers coming from years of C++ background are struggling in other languages when they lack generics. Sure, right tool for the job. But in case of generics I'd say they're much too broad to speak of a single tool and they can be used for multiple jobs. So I'm with the author and feel go lacks on that point. To quote Yossi Krenin aka the guy who doesn't want to write std::map< std::string, std::string > :P
- codygman 13y agoPlease see the simple implementations of generics in ocaml and C# (added later).