6 ms·
See plenty of opinion here too, like generics getting too complicated and error handling needing to be designed in. Vehemently disagree on both
by voxl 5y ago
See plenty of opinion here too, like generics getting too complicated and error handling needing to be designed in.
Vehemently disagree on both
- Animats 5y agogenerics getting too complicated There seems to be some agreement that C++ overdid it. Both Go and Rust have more limited generic systems. error handling needing to be designed in I'm not expressing an opinion on return values vs exceptions. But some kind of standard is needed or library error reporting is terrible.
- formerly_proven 5y agoThe biggest issue with C++ metaprogramming is not necessarily that it is that powerful (though I've concluded for me that C++ allows too much overloading of semantics by library authors and they seem to really like that) but that the metaprogramming "language" if you can call it that is just incredibly weird and like nothing else on Earth. There's this entire jargon that literally only exists for meta C++ and that should be kind of a huge red flag besides the entire thing being an accident. It's truly a "weird machine" in the truest sense of the word that somehow became an industry standard.
- VHRanger 5y agoRight, D has fairly sane metaprogramming (just slap the static keyword on all compile time stuff!) and somehow managed to make it compile fast unlike c++
- duped 5y agoI think it's "weird" because it fills this weird gap between shitty macros and generic programming but does none of the hard parts of either. The syntax itself is not nearly as strange as those semantics. For example, if you look at what type traits are used for, it's essentially making up for the fact that C++ lacked semantics for compile-time checks of generic arguments, forcing anyone that needed to care about that to implement their own (often simple, special case) constraint solvers. Meanwhile, typeclasses in other languages wrote a generic constraint solver (ironic) and support the semantics to express those constraints on generic types, obviating the need for any kind of complex compile-time template logic hackery. Essentially the lack of semantics for a simple concept (yet difficult implementation behind it) forced the implementation of a simple extension to the same syntax that enabled really complex macro programming using the same templating engines. It's no surprise that metaprogramming in C++ is exceptionally weird; it supports neither proper macros or generic programming, yet half-implemented both through templates to solve the lack of either.
- gary_0 5y agoNot to mention C++ templates are hideously slow to compile (if used indiscriminately, as they often are). Although C++ isn't the only language that struggles with build times. At any rate, it does seem possible to do generics without slow compile times (C# seems to do fine, for instance), so C++ might be giving generics a bad name on that count as well. Fast builds would be high on the list of my own "dream language" features. Long developer iteration times are poison.
- kaba0 5y agoI think C++’s slow compile times come more from the stupid C-header conventions. That should have been buried decades ago and replaced by modules.
- chrsig 5y agoI don't think c++ overdid it persay, I just think that they really got some of the ergonomics wrong. SFINAE and the CRTP are examples of idioms that are possible due to the flexibility, but unintelligible to read (I'm sure there's some population that really disagrees with me. I'm not saying they're not useful, just not ergonomic) They're slowly layering in those ergonomics, which will eventually be nice, though there'll always be a big pile of legacy.
- throwDec21 5y ago> like generics getting too complicated I'd love to know if you write lots of code and/or have to maintain other people's hugely templated code. I find if you have to do lots of the second you quickly stop writing it.
- stouset 5y agoSaying that generics get complicated because C++ templates are a nightmare is throwing the baby out with the bathwater. I don’t think anyone same would ever design templates today.
- kaba0 5y agoI would still prefer that over copy pasting that shitty list implementation for the nth type, or whatever “convention” some C devs do to make it “generic”.
- BatteryMountain 5y agoGenerics in C# is crazy good, both in writing and using them, all while the compiler checks the correctness especially if combined with constraints. I've tried "generics" in other languages but they all fall short compared with C#'s way. Between reflection, generics, polymorphism, dependency injection, you have a winning combo of code reuse. Can turn thousands of normal lines of code into a few hundred. I've surprised myself again again on how useful it can be, all without getting lost in the abstractness of it. The people at the dotnet team who carefully thought it through and implemented it deserves a ton of recognition for this.
- ithkuil 5y agoCan you summarize the aspects of C# generics that are different/better than other similar languages?
- torginus 5y agoEh, It can be good or bad. While generics (in C#) can make your code easier to use correctly, by making sure that everything is of the right type, and can give you a nice perf boost when using generic specialization with structs, they also have a tendency of infecting every bit of code they affect with more generics. For example if a function is generic over T, where T is parameter X constrained to be `ISomething`, all the function that it calls with X should use constrained generics as well, this can easily lead to the explosion of generic functions in your codebase. Many times, instead of making a function generic over T it's easier to make parameter X just be interface `ISomething` and be done with it.
- BatteryMountain 5y agoVery good point. I typically use both approaches, sometimes using an interface as a method parameter just "feels" more natural, but other times a generic + type constraint is better. I usually draw the line when the infection you mention becomes too much, aka when 3 or 4 layers are now forced to use a generic cause 1 layer needed it. So yes, very valid point. The key is to find balance so that the code is still maintainable in 6 months from now, still readable + fast, while trying to reduce duplication where it makes sense.