On Monday, 5 June 2017 16:26:25 UTC+3, utyug...@mail.com wrote: > > I gave you a simple problem, don't over think it. A Set data structure > with a simple api that can work out-of-the-box - just as slices and maps > with the builtins. I kept the requirements minimal. I'd like to see your > solution. >
As I've already mentioned, my current problem-free approach is not out-of-the-box solution. Maybe, you misunderstood what I meant by problem-free. I mean that this is something I don't care about when writing code and the workaround is trivial-low-effort work... I didn't know what the set was intended for; so I wasn't able to add Universe -- or don't have a good idea how you would construct one in Go for infinite constrained type. Not sure what you meant by superset/subset; -- if that one set contains another set, then there would be more code similar to Add/Sub. If you meant a superset that returns all possible supersets, then it would need Universe. By no means I would consider it a good set implementation / API, but since that wasn't one of the criteria. <https://lh3.googleusercontent.com/-TnGw_r6sy5I/WTVi7v_BpsI/AAAAAAAAD4c/9ETmQWhe4uw9RDXbV8hb8xe7wwWu2yYxQCLcB/s1600/SetImplementation.gif> I ran into 3/4 bugs while renaming types: 1. I forgot to save the file. 2. I forgot to remove the original set entry type. 3. I forgot what the original set api was 4. Confused a,b,c and x,y in the demo. At the moment I had to specially write generic code for Set, because it seems in ~5 years I've never found it worthwhile to write one. I had a delta-encoded intset, sparse-set, different bitset implementations, but nothing else. I know the video is not 3minutes long, the rest of 3-minutes I would have used for searching the general purpose set, if I had one. *Depending on the situation the actual approach may vary..* + Egon On Monday, June 5, 2017 at 12:52:47 AM UTC-4, Egon wrote: >> >> >> >> On Monday, 5 June 2017 06:59:46 UTC+3, utyug...@mail.com wrote: >>> >>> >>> >>> On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, 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) >>>> >>> >>> create a custom container type that I can use with any type >>> out-of-the-box. >>> >>> for example: iset := make(Set[int],9); sset := make(Set[string],9); pset >>> := make(Set[Person]); >>> >>> right now, my solution is to rewrite the source with go generate calling >>> a tool i wrote which grew out from a great talk from robert griesemer. The >>> video: https://www.youtube.com/watch?v=vLxX3yZmw5Q >>> >>> This solution has nearly twice the performance increase over maps with >>> almost every type used so far. Now I could have just written the 500 lines >>> of code over and over again for every type needed until the end of time(or >>> copy and paste and edit until the end of time), or I could use empty >>> interfaces which throws type safety out the window, but I chose to write a >>> tool, and when go generate came to be I chose to use that tool like a >>> simple script executed within a '//go:generate go run..' tag. >>> >>> >>> Over time golang(I do this now to annoy the zealots) provided the >>> tools(reflection, /go packages, go generate) that made creating custom >>> generic type safe containers easier. These things weren't always this easy, >>> and these things could be easier. >>> >>> And I am serious about create a custom container type that I can use >>> with any type out-of-the-box. Please indulge me, how would you solve this >>> problem. Provide a solution for a simple type-safe container type Set that >>> takes any type, with a simple api of >>> insert,remove,contain,union,difference,intersection, >>> complement,superset,subset. >>> >> >> I would use copy-paste. That action to specialize and clean-up API is >> pretty trivial, it might take me 3min (probably less), but it isn't a >> problem. I often spend more time on tweaking CSS or figuring out what the >> customer needs. Copy-pasteing code is annoying, but it's trivial low-effort >> work... so it's not a problem. *There of course are probably domains >> where this 3min might be a problem*. Then you might use a >> reflect/interface based solution and create a type-safe wrapper. Or use >> code-generation. >> >> 3min writing code, isn't a problem for me. >> >> There's also a subtle problem here, I consider >> "insert,remove,contain,union,difference,intersection,complement,superset,subset" >> >> API somewhat unclear... it loses domain knowledge and may provide more >> functions than strictyl necessary... this of course it depends on the >> context. >> >> Also, where will this set be used? Set data-structures have a ton of >> different trade-offs. I really don't know how to write a really good >> general purpose Set. (see >> https://github.com/golang/go/wiki/HowToAsk#the-story-of-a-bad-question) >> >> I've seen you provide solutions in the past, so I would like to see your >>> solution to this not-much-of-a-problem. >>> >> >>> >>>> >>>> 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. >>>> >>>> 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 >>>> >>>> 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.
