Not a problem!
On Thursday, September 20, 2018 at 11:55:04 AM UTC-4, Michael Jones wrote: > > [Apologies to Dave Cheney, timely pushback for David Collier-Brown] > > David, I disagree and suggest your remark is not well considered. Three > replies, one per sentence. > Not a problem! Indeed, thanks for the response. > > *"Right now, this looks like the third draft of an academic project."* > Not to me. This reads like years of thought and discussion among qualified > researchers and skilled implementers. Not to boast unduly, but if you look > at the history of Ian, Robert, and Russ, you'll see intimate responsibility > not only in Go but in Gnu C/C++, Modula, and more. What I see in the > proposal is informed wisdom. This is engineering so there is always a > better way, but this may be the best that can be seen before implementation > and experience. > > I've indeed worked with generics in other languages, and always considered that Go, which says it doesn't have generics, has the best set. Mind you, the notation is opaque. It says "create me a bunch of X", for a couple of heavily-used meanings of "bunch". You have to read an article on how it does it to understand the what. My usage of generics over the years has tended to collapse from many types originally to just sequences and hash tables. I literally don't remember the last time I did anything more complex in C++ or Java. Maybe a table of sequences, for a library for Steam games. I don't mean it as an insult to the skills of the community, but I don't see it as an advance, but rather as another experiment *in search of *an advance. To restate your "there is always a better way, but this may be the best that can be seen before implementation and experience", I think it could be the best way before implementation and experience, but I really wish to see more implementations, inclusive of this one, as conscious experiments. And I should say that the title doesn't characterize my thoughts (;-)). I am in favor of generics, but I'm cautious in my enthisiasm. > *"It suffers badly by comparison to make(), the existing mechanism."* > Yes, inherently so. The existing mechanism uses magic in parsing and > implementation—details known in the compiler but not exposed in the Go > language generally, to make things as easy as possible. It is nice. But > from before the launch of Go users asked "how can I do such things > generally, in my code, and not by extending the language or the compiler." > The answer was "use interfaces now and we'll think about generics later." > Later is now and indeed exposing aspects of behind the scenes compiler > magic is more complicated, that's inherent. The decision to be made is how > powerful vs how complicated. > I find the idea of make to be a simple API, just like a library. You ask it for a map of structs indexed by an int, and it gives you one. The overloading of m = make(map[string]int) versus a = make([]int, 5) makes me wonder what's happening. That, IMHO, is something that needs a better notation, where different parameter lists have differentiable names. Using an old *butt-ugly* notation, I would like distinguishable forms like a:= []int.New(5) and m := [int]string.New() At that point, the opacity is the same as with an API: it says to create a slice of int of size 5, implemented on an array, or a map of strings indexed by int, implemented as a thing in itself. If I need more context, I read the code and/or the blogs. > "Can we see some more alternatives, please?" > They are legion. Existing generics approaches in various languages are > more than ideas, they are living examples of design, ecosystem, and > behavior. Several proposals have been offered by the Go team and > collaborators here. The Go 2 design site lists many specific comments and > alternatives. Extensive thoughts have been shared, with *responsa sunt, > novi in via*. > Yes, I agree. Perhaps "ex Africa semper aliquid novi*" *will be our saving grace, or as the cavalry says, "keep on hacking, Algy" (;-)) Limited objectives, tight control is never fun, but we have something surprisingly good with the magic make() incantation. I'd love to see something that's a single step more general and a bit less like formal magic. --dave > > Not a personal attack. Trying to inform these statements and encourage > review and consideration. > > Michael > > On Thu, Sep 20, 2018 at 5:04 AM David Collier-Brown <dav...@spamcop.net > <javascript:>> wrote: > >> Right now, this looks like the third draft of an academic project. It >> suffers badly by comparison to make(), the existing mechanism. >> >> Can we see some more alternatives, please? >> >> --dave >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > > *Michael T. jonesmichae...@gmail.com <javascript:>* > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
