4 ms·

Your example is very simple though. What's the go equivalent to x.map(fn).filter(predicate) ie returning a new collection of transformed items which is fil

Your example is very simple though. What's the go equivalent to x.map(fn).filter(predicate) ie returning a new collection of transformed items which is filtered by some predicate? Now we are talking more like 5-6 lines of Go.

kiitos 3y ago
> What's the go equivalent to x.map(fn).filter(predicate) Probably something like var output []T for _, val := range input { if newval := transform(val); allow(newval) { output = append(output, newval) } } No problem?
- xmcqdpt2 3y ago
  It's definitely less clear though, in that it involves an if statement with an assignment, three temporary variable declarations, etc. Also, type inference won't detect the type of the output automatically from the transform function type, and this of course assumes you wanted to collect into a slice, but it could be a set, or a list. For some operations, the Go style of explicit, mostly in-place mutations produces more complicated code. Whether that's balanced out by the code being "simpler" is not clear to me, but I haven't worked with Go.
  - kiitos 3y ago
    I see it as unambiguously more clear, because it makes explicit what the machine will be doing when executing the code. Whether map/filter copy values, or mutate in-place, or etc. etc. is non-obvious. I mean I'm not saying my way is the only way and I appreciate that other people have different perspectives but I just want to make it clear that "clear" in code isn't an objective measure, that's all.
    - xmcqdpt2 3y ago
      I agree that there are no objective measure. I guess it's just different expectations. I would not say it's obvious what the machine is doing in the Go example though. For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. I had to look it up from a blog post, because the source for append() is gnarly https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/internal/gc/ssa.go#L2841 https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/i...
      - kiitos 3y ago
        > For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. Well I guess you do have to grok the language spec and semantics in order to understand how builtins like append behave, I'm not sure that's avoidable.
- pharmakom 3y ago
  That is significantly worse than the FP version and I think it proves the point.
  - kiitos 3y ago
    It's fine that you judge it that way, but it's not like that judgment is any kind of objective truth. I find it superior to the FP version because it is less ambiguous.

kiitos 3y ago

> What's the go equivalent to x.map(fn).filter(predicate) Probably something like var output []T for _, val := range input { if newval := transform(val); allow(newval) { output = append(output, newval) } } No problem?

xmcqdpt2 3y ago
It's definitely less clear though, in that it involves an if statement with an assignment, three temporary variable declarations, etc. Also, type inference won't detect the type of the output automatically from the transform function type, and this of course assumes you wanted to collect into a slice, but it could be a set, or a list. For some operations, the Go style of explicit, mostly in-place mutations produces more complicated code. Whether that's balanced out by the code being "simpler" is not clear to me, but I haven't worked with Go.
- kiitos 3y ago
  I see it as unambiguously more clear, because it makes explicit what the machine will be doing when executing the code. Whether map/filter copy values, or mutate in-place, or etc. etc. is non-obvious. I mean I'm not saying my way is the only way and I appreciate that other people have different perspectives but I just want to make it clear that "clear" in code isn't an objective measure, that's all.
  - xmcqdpt2 3y ago
    I agree that there are no objective measure. I guess it's just different expectations. I would not say it's obvious what the machine is doing in the Go example though. For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. I had to look it up from a blog post, because the source for append() is gnarly https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/internal/gc/ssa.go#L2841 https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/i...
    - kiitos 3y ago
      > For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. Well I guess you do have to grok the language spec and semantics in order to understand how builtins like append behave, I'm not sure that's avoidable.
pharmakom 3y ago
That is significantly worse than the FP version and I think it proves the point.
- kiitos 3y ago
  It's fine that you judge it that way, but it's not like that judgment is any kind of objective truth. I find it superior to the FP version because it is less ambiguous.