Ian, Ian,
Well, if a simple comprehensive solution can be found, then I'm sure we'll all be in favor of it. The problem is that many people think the current draft design is too complex and I haven't seen a plausible suggestion from anyone (myself included) which would be appreciably simpler but as comprehensive, or nearly so. This is why I'd concluded that, if a system could be devised which was simple but nonetheless addressed 90% of the use cases for generics, it might be good enough. Even simpler solutions are better than some languages have. Having programmed in C# for many years, I was frustrated that you couldn't write useful generic functions for numerics at all and, even though they've added a lot of stuff lately, you still can't. As Robert has just mentioned, Java generics are far from perfect also. Alan On Friday, September 14, 2018 at 6:16:47 PM UTC+1, Ian Lance Taylor wrote: > > On Fri, Sep 14, 2018 at 3:32 AM, alanfo <alan...@gmail.com <javascript:>> > wrote: > > > > I was then brought back to reality by this post by Robert Engels in the > > 'Generics - Why contracts?' thread: > > > > "As I’ve said elsewhere, a SIMPLE to use and understand solution that > covers > > 90% is better than a complex one to cover 100% IMO, and fits in well > with > > the rest of Go design. Go leaves out a lot - and it's a good choice." > > I've seen several people express this idea in different ways. I want > to challenge it. > > I agree that simple is essential. That is not in dispute. If the > current design draft is too complex, we can not adopt it as is. > > However, it does not follow that a 90% solution, whatever that is > taken to mean, is acceptable. > > A 90% solution is frustrating, in exactly the same way that some > people find the fact that Go currently lacks generics to be > frustrating. That is, for generic programming, Go is already a 90% > solution. Some people find the missing 10% to be annoying, > frustrating, and confusing. This will continue to happen if we add > another 90% solution to the problem. > > A 90% solution is complex, because by definition it means that there > are special cases, complex cases, that do not work as expected. > Everybody who learns Go has to learn not only how to implement the > 90%, they also have to learn where that 90% stops. > > A 90% solution is not orthogonal, by definition. Go is in some ways > not very orthogonal, but it is orthogonal in this way: all concepts in > Go that can be meaningfully used together, work together as one would > expect them to. There are no missing elements. > > When considering changes to the Go language, please do not settle for > a 90% solution. > > Ian > -- 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.
