On Sunday, June 4, 2017 at 6:25:17 PM UTC+2, Egon wrote: > > I think you are missing the point of my comment. > > I'm all for generics, but I also can survive without them without much of > a problem. (I'm even maintaining > https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4 > > to understand the problem better) >
that s actually a good pointer. > > The issue I was trying to highlight was that you are proposing solutions > to a problem, but other people don't know what your exact problem is. Hence > my 3 lines version are equivalent in their result and value, because the > problem is missing. > if i m right you argue the fact i did not come up with a complete formalized approach. I did not intended to, i think i tried to force open door of what is hiding under the noise, to think out loud. In the end i expect to either provide one example where its a definitive no-go and its possible to explain why. or sufficient expected real world use cases to start consider it for later implementation. But in one-way-communication this obviously can not happen. > > Similarly, when we don't have a concrete problem we could over-engineer > the generics or alternatively solve the wrong problems. > > For example, when the solution you propose only solves 5% of the problems > that generics needs to solve... or vice-versa... a generics solution 100x > simpler would solve 99% of the cases... then what is the value of the > proposed solution? > > So, which of the 147 different generics approaches/implementations works > better for Go and why? (I'm also counting the ones that aren't known yet :D) > > When you would use a real-world example and problem, it would be possible > to argue that one approach is better than the other... without one, this > discussion doesn't lead to anywhere. > > + Egon > > Just to clarify, i m not really in favor of generics per se, i have enough to deal with right now to not add more complexity here. In *here* I mean both declarer and consumer sides of an api programming. But still i can t go with the existing, so i did try to solve the problem on my hand, but it happens it simply require a more in depth solution, the current superficial solution i can think about will always be limited by what has been well resumed earlier by utyug "or I could use empty interfaces which throws type safety out the window". > On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote: >> >> given the fact that actually everybody disagrees on that idea, >> or even something similar according to some feedback. >> >> I want to put the question differently. >> >> My mean is to say that golang is a basis to build upon in general that is >> better >> than other existing solutions. >> >> imho, golang is governed by its compatibility requirement, >> and, an extremely vertical approach, >> which blocks every possible update to the dogma: >> is it go 1.0 compatible ? >> >> And because its vertical, is it to my taste ? >> >> The go 1.0 compatibility requirement makes everybody very happy. >> >> Still, I dont believe the language is considered as finalized by a >> majority of users. >> Some will say it misses generics, some other (..) will try different >> approach. >> >> Why should it be that much of frictions ? >> >> Why can t we evaluate a solution where multiple vision co exists ? >> Handle the change. >> >> Aint there existing case of such kind of symbiosis which benefits each >> other on the long term ? >> >> A solution where the go 1.0 requirement is kept valuable, >> and a new language target where this requirement has been removed. >> A transpiler to go 1.0 compatible code ? >> So both can exist ? >> >> my 2 cents, >> that close and negative answer i got, >> is not helpful nor inclusive, >> its like take or leave attitude, >> >> it d just be more inclusive to say that >> it is ok to make a transpiler/or whatever it should be/ implementing your >> idea, >> check that resource for further implementation come back here for >> questions. >> >> Other consideration, >> the idea that golang 1.0 is used to build a different language target >> that compiles back to go1.0, >> looks cool. >> >> On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote: >>> >>> for the fun, with early return, >>> >>> https://play.golang.org/p/I9AORKOYQm >>> >>> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote: >>>> >>>> > Generics enable more than just replacing loops. For example, they can >>>> enable libraries of generic algorithms to be used with any type of array. >>>> Here's an example: >>>> >>>> in my demonstration every type got this kind of method, >>>> the problem become how do you jump from Type A to type B. >>>> in []A to []B or A -> B >>>> >>>> indeed it works on the item level, no more on the collections. >>>> >>>> This question is solved in two ways, >>>> - interface definitions (not interface value) >>>> - static conversion, which always resumes to >>>> func(in-type) out-type >>>> >>>> and some alternatives for convenience (producer/consumer) >>>> func (func(in-type) out-type >>>> func (in-type) func() out-type >>>> func (func(in-type) func() out-type >>>> // this is unfinished explanation it should include error management to >>>> be handled more completely. see please previous conv() fn introduced >>>> earlier to statically re decorate a func signature. >>>> >>>> So far the sum/reduce things operation, >>>> i left them as exercise to the stream declarer >>>> and did not consider them as core. >>>> Take become => filter (func(10 elements)) >>>> Map is map >>>> Sort is All(fn sorter) []out >>>> Reduce is a map operation, preceded by a conv if it reduces to a >>>> different type. >>>> >>>> >>>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, >>>> gary.wi...@victoriaplumb.com wrote: >>>>> >>>>> Generics enable more than just replacing loops. For example, they can >>>>> enable libraries of generic algorithms to be used with any type of array. >>>>> Here's an example: >>>>> >>>>> foo := GetArray() >>>>> result := foo.Take(10).map(...).Sort(...).Reduce(...) >>>>> >>>>> That is simple to understand and in one line of code. Imagine the >>>>> acrobatics (and lines of code) needed to do this using Go's loops! >>>>> >>>>> You can read my full article on why Go needs generics here: >>>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/ >>>>> >>>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote: >>>>>> >>>>>> Since everyone thinks it but nobody bothers to reply to it: this >>>>>> whole thing you propose can be currently done with a for loop, which not >>>>>> only is explicit about what it doing, but it also lets you control if >>>>>> you >>>>>> want to exit early from it and so on. Complicating the whole language >>>>>> because something is cool (yet looks like a really complex thing that >>>>>> you >>>>>> need to think about while reading the code) is in no one's benefit. Stop >>>>>> trying to avoid a couple of extra rows of for {} (where the third row is >>>>>> literally just an "}") and start embracing the fact that you can >>>>>> understand the code by looking at it and not apply any complex mental >>>>>> acrobatics to figure out what those three lines of code are doing. Your >>>>>> future self/person after you will thank you for that. >>>>> >>>>> -- 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.
