Conversation

I won’t @ them but limiting expressivity in order to limit cognitive load and keep codebases approachable is a totally legitimate move in language design. I’d even say essential. It’s all about balance, and expressivity _does_ have tradeoffs.
Quote Tweet
Almost all the arguments I see against generics in go are pretty awful. "People might create abstractions I can't understand" is an awful argument. And that's the root of most argument I see. That's so broad that you can apply it to the base language itself. Don't @ me.
Show this thread
9
126
In the case of generics, the cost of leaving out even simple generics has a high cognitive load cost. I have no problem with taking it slow and conservative; that's a reasonable place for them. But the koans and zealous arguments against generics disrupt the design process.
2
9
Too add a sample point to your koans: I can only go with my gut, but my if I were designing my own language, I would not add generics. Not worth the impl burden. Simplicity of implementation for the designer and satisfying the most people are mutually exclusive.
1
And I would have rather have something I could fully understand (or close to it) so I can change it easily rather than something where no single person can understand the whole, but satisfies conflicting use cases so ppl can "get things done". Not understand the layers BOTHERS me
1
It is very possible I'm just not used to it. Graydon has given me very helpful resources in the past and I've slowly been looking into them. But I have to do work for stuff I'm good at/that ppl pay me for (FPGAs) before I can reserve time for things I'm less comfortable with :(.
1
1
Maybe it's more accurate to say: "At present, if I had to implement a high-level lang*, I would skip generics b/c it's still not something I think I'd personally find worth the extra impl details." I totally get why users love them tho.
3
Show replies