6 ms·

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" borderli

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.
        5y ago
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.

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.
      - 5y ago

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.