13 ms·

I agree with the goal of the package, but I feel it doesn't do a good enough job of picking a lane between the imperative and functional approach. If you're go

• sabellito 5y ago
  I think it's to do with the community and what people who are really into Go are interested in. The first reply to the thread deems "map" and "filter" borderline-useful, but "reduce" not worth it - that type of misunderstading just shows that the author (and the 60+ people who +1'd it) didn't spend enough time understading functional constructs yet.
  • foldr 5y ago
    Reduce is basically "loop over this list while maintaining state". If you have loops and state built in, it doesn't buy you a whole lot. I don't think the aim of the package is to move Go towards a more functional style. Rather, it's to provide a set of utility functions that mesh with the style of existing Go code. For example, it would be useful to have a utility to 'pop' an element from a slice, even though that's not a particularly functional idiom.
    • sabellito 5y ago
      I definitely wasn't arguing about what should or should not be in the package. I just replied to the parent comment with my idea as to why the discussion around this point is happening in the proposal.
  • tsdlts 5y ago
    Or maybe they understand them perfectly and have come across enough obtuse code using reduce to not want it as part of the language.
    • sabellito 5y ago
      Everyone draws the "code that I like looking at"-line at different places. Despite our wishes around that, functional constructs do have a hierarchy of abstraction vs power, and skipping a layer is the type of design that backfires in the end, like with Java doubling down on the collection APIs without introducing monads explicitly for users.
      • creata 5y ago
        > Java doubling down on the collection APIs without introducing monads explicitly for users. I'm not necessarily disagreeing with you, but how has that backfired for Java? It seems as popular as ever, and I don't hear many people lamenting the lack of monads in Java.
        • sabellito 5y ago
          Ah thanks for pointing that out as I didn't make myself clear. I definitely didn't mean Java as a whole, as it is indeed a tremedously successful platform and language. I meant specifically the lack of flexibility in some regards because of the missing of monads and friends. For example, we have a few newer languages, TypeScript and Kotlin come to mind, implementing the "null operator": thing?.fieldA?.fieldB While this is quite handy, and people unfamiliar with the Option monad will think that this new syntax is really cool, it poses two limitations: 1. It doesn't compose with other abstractions 2. I can't use this for my own abstractions If the language designers had chosen to take one step back and implemented it in a more generic way (in some sense, in the same as my other comment in this thread about implementing "map" without "reduce"), the feature could've still been implemented in the language, but without the limitations. I'm not sure what you meant with this point: > people lamenting the lack of monads in Java. Do you mean that, because you don't see people lamenting, it's not a useful feature?
          • creata 5y ago
            > It doesn't compose with other abstractions But monads don't compose with each other, do they? I thought you needed something more (monad transformers, algebraic effects, etc.) to get things to compose. Or maybe you meant something else by composition. > I can't use this for my own abstractions Yep. But Java doesn't even let you overload addition afaik, so being able to overload ? is pretty much a pipe dream. > Do you mean that, because you don't see people lamenting, it's not a useful feature? No, it's just that if something "backfired" for Java, I'd expect to hear people complaining about it.
  • majewsky 5y ago
    This is not about misunderstanding. The author argues that heavy map/filter/reduce does not fit with the general style of Go programs. As a heavy Go user, I absolutely agree. There is nothing preventing people from writing their own reduce() in their own utilities package, and I expect a thriving ecosystem of "even-more-functional-constructs" packages to spring up as soon as generics hit stable. The discussion in this proposal is not about this. It's only and entirely about what the stdlib should provide, and that is much more a question of practical and idiomatic usage than it is about one's understanding of a theoretical CS syllabus.
    • sabellito 5y ago
      If you re-read the comment I was replying to I don't think your comment as a reply to mine makes a lot of sense. I'm not arguing what's good and bad, nor what should or should not be in the Go language.
    • jerf 5y ago
      I need to update this for the latest generics syntax, but I wrote this a while back: http://www.jerf.org/iri/post/2955 http://www.jerf.org/iri/post/2955 "Why Go Getting Generics Will Not Change Idiomatic Go" I do not understand the people who think that functional-esque programming is the only and best way to do things who are apparently just sitting and waiting for Go to be able to do it. Are you forced to use Go or something? This is an honest question, btw, and I am legitimately interested in answers. If the only reason or the biggest reason you're not using Go is that you can't import map-centric programming into it, why not use any of the many languages that support that rather than griping about a language where it's still ultimately going to be bodged on? Again, honest question, because there's no shortage of such languages. My perception is that Go isn't that popular that there's a lot of people forced to use it against their will because it's just The Language. Anyhow, even after generics drop, it still isn't going to be any fun. I expect to use a map here or there often enough that it'll be nice to have it in the standard library but there's no realistic way that it's going to become "the best way to program in Go". If you're waiting to try it out after the generics drop, I would suggest trying something else instead; Elixir, Nim, Crystal, Pony.
  • throwaway894345 5y ago
    > The first reply to the thread deems "map" and "filter" borderline-useful, but "reduce" not worth it - that type of misunderstading just shows that the author (and the 60+ people who +1'd it) didn't spend enough time understading functional constructs yet. It’s not very charitable to assume that people who disagree with you must not understand your position. In particular, one person could like reduce() because it’s very abstract and can be used for lots of problems, but critics could dislike it because very high levels of abstraction impede readability. Both parties may understand each other, but they are optimizing for different things (abstraction for its own sake and readability, respectively).
    • sabellito 5y ago
      I definitely didn't mean it as an insult, as my comment is a reflex of my own journey understanding these concepts. I'm also absolutely not an FP expert. Different people have different levels of understanding about different things, this has nothing to do with intelligence or a general programming skill level. I do think this is about understanding, as it's not about syntax, or what feels nicer. It's about building blocks and what comes before what. Given the nature of the proposed library, to give the users an arbitrarily less abstract construct is a design mistake as I mentioned in another comment in this thread. For example, I remember when I needed to flatten a bidimensional array in JavaScript, perhaps back in 2005, and the internet told me that I needed to flatten the array. So I learned then that array.flatMap() served that purpose: to flatten a bidimensional array. This is of course incorrect, but it took me many years until I found the concept again and understood what were the building blocks around flatMap, and what kinds of other abstractions it allowed.
      • throwaway894345 5y ago
        > I do think this is about understanding, as it's not about syntax, or what feels nicer. It's about building blocks and what comes before what. Given the nature of the proposed library, to give the users an arbitrarily less abstract construct is a design mistake as I mentioned in another comment in this thread. Per my earlier comment, it's only "a design mistake" if you assume that it's always better to trade readability for abstraction. This isn't always the case, and in professional software engineering it's often better to optimize for readability--rarely are high degrees of abstraction beneficial (of course, someone will respond to this with some anecdotes of the instances in which high degrees of abstraction are helpful, which is just an enumeration fallacy).
  • masklinn 5y ago
    Sounds about right. Python 3 demoted reduce from builtin to stdlib because it saw very little use after the introduction of the more common use cases as builtins.
  • kubb 5y ago
    Bingo, Go is geared towards junior programmers. Somebody who exits the university has to be able to feel productive within two weeks of using it. That's literally the cornerstone of the entire design and all things follow from it (C-like syntax, attempt to minimize the number of language constructs, and the heavy focus on imperative programming which is what they teach in college).
    • cy_hauser 5y ago
      Oh the unintended irony. Go's syntax may be simple enough to pick up in a few weeks but writing "good" Go code turns out to be much much harder. Idiomatic Go can take a year or two to internalize and introducing non idiomatic Go code into an established code base can really muck it up. You can see this clearly in job listings looking for Go coders. Almost nobody is looking for junior level Go coders with less than a year of experience. Companies are looking for Go coders with at 2, 3, 5+ years of experience instead. A simple syntax may provide benefits, but it doesn't seem to be the benefits most companies want in practice after all.
      • brandonmenc 5y ago
        > Almost nobody is looking for junior level Go coders with less than a year of experience. I have never seen a job posting asking for less than a year of experience with anything.
        • cy_hauser 5y ago
          True, but what other languages or other anythings are doing is at best irrelevant and at worst the entire point.
• parhamn 5y ago
  > The higher-order function style also tends to be much slower, so when writing a loop there's a decision burden every time between saving a line or two and writing fast code. (TIMTOWTDI is not really the Go ethos.) And programmers usually prefer concision, so the net result is often slow, HOF-heavy code. This is very real. We do it all the time in JavaScript: Object.entries({...spreadMerge, ...secondSpread}).map().filter().find(x) Not once do I think about how many things are initialized, iterated over, etc. Rarely would I do something like this in Go. Whether it matters is a good question, but the point is true: language facilities make you care more or less about performance depending on what it does.
  • jolux 5y ago
    This is a problem of optimization, not language design. There’s no inherent reason a chain of functions like that has to be less performant than a for-loop. You need high-performance iterators in the language, and a good compiler.
    • Cthulhu_ 5y ago
      One of Go's objectives is to have a simple and fast compiler; emphasizing simple and readable code will ensure that. It's one reason why type arguments were put off for as long as they have been.
      • dmitriid 5y ago
        `.map().filter().find(x)` is significantly more simple and readable than for-looping for every small thing in Go.
        • throwaway894345 5y ago
          I disagree. Fewer characters != simpler or even more readable. Map/filter/etc are certainly more clever, and I enjoy writing clever code, but I reserve it for my personal projects bprecisely because it isn’t so clear. Note that Python has these first class functions as well as various kinds of comprehensions and still it’s frowned upon to use anything more complex than the simplest comprehensions.