4 ms·
> No abstract examples/arguments. These cause the discussion to lose focus and make examples harder to follow. The example/argument must be traceable to a real-
by simias 12y ago
> No abstract examples/arguments. These cause the discussion to lose focus and make examples harder to follow. The example/argument must be traceable to a real-world problem - Go is intended to solve real problems not imaginary ones.
I find that's a very good rule in those discussions, it's too easy to get bogged down to some obscure use case and miss the forest for the trees.
I note however that the authors seemed to have forgotten about that rule just after writing it down since the rest of the document is full of vague assertions and unsubstantiated arguments like:
- "I have heard of simple libraries having text segments shrink from megabytes to tens of kilobytes by revising or eliminating the use of templates."
- "Generic algorithms can be harder to follow than their non-generic counterparts."
- "Fancy algorithms are slow when n is small, and n is usually small. - Rob Pike"
- "map/slice suffice for most of the cases encountered in programming. (based on some community opinions https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ)" https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwG.... The linked thread contains a bunch of posts, not sure what I should be looking for (I thought the whole point of this document was to "go over the relevant points without digging through hundreds of forum posts"?)
- "Code won’t look idiomatic." I'm not sure what that even means.
I don't know if generics have a place in Go or not but I'm not sure this document is going to help solve that issue. Making a list of concrete use cases for generics and discussing possible alternatives would probably be more constructive.
- jerf 12y ago"I note however that the authors seemed to have forgotten about that rule just after writing it down..." I feel I need to remind you, and a lot of the other commenters here, that this is a top-level summary of all the various arguments. And that it is possible on the Internet to mention arguments without actually advocating for them at the same time. I doubt you could find any individual on the planet that would "agree" with that entire document from top to bottom.
- simias 12y agoThen it should link to the various places where those arguments have been discussed. As it is it's hard to take that as a neutral reference and looks more like an opinion piece against the implementation of generics in Go trying to pass off as a neutral reference. If that was on wikipedia it would be littered with [citation needed].
- deleted 12y ago[deleted]
- scott_s 12y agoI get that, but I had the same reaction as simias. I, and I assume simias as well, is not concerned with the advocacy, but the lack of examples. I read the introduction and thought "Oh, cool! I'll get to see lots of use-cases showing how things behave in various circumstances." But I mostly saw the same hand-wavy arguments I see elsewhere. I think the better reaction to simias and my point is that this is clearly a work in progress. I assume that in the future, it will actually contain the use-cases I thought it would.