3 ms·

filter/map/reduce are more productive than anything I could write without them.

fwip 6y ago
Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way. Here are three options that were on the first page of google: * https://github.com/kulshekhar/fungen https://github.com/kulshekhar/fungen * https://github.com/awalterschulze/goderive https://github.com/awalterschulze/goderive * https://github.com/cheekybits/genny https://github.com/cheekybits/genny
throwaway894345 6y ago
I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.
- erik_seaberg 6y ago
  filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.
  - throwaway894345 6y ago
    Wall? var out []X for _, x := range elts { if condition(x) { out = append(out, x) } } That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block. I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.
    - eweise 6y ago
      elts.filter(condition(x)) way more readable.
      - theshrike79 6y ago
        Only if you know what a filter is and how the condition is parsed. In more cases than one the condition is a lambda-monstrosity shoved in the filter function, which makes it even harder to parse.
        fomine3 6y ago
        In the situation, even for statement also become monster.
      - marcus_holmes 6y ago
        Not if you're not used to it. Literally had this over the past few months working with a junior programmer who had a really hard time understanding stacked map()s and filter()s but understood them easily when I unrolled them into nested for loops.
        eweise 6y ago
        The junior programmer would have been much better off learning how a filter function works so they could be productive in almost every other language besides Go.
        marcus_holmes 6y ago
        This was Javascript. And yes, I was teaching him how filter functions worked. But the point remains that if you're not used to them, map() and filter(), especially when stacked, are not that readable.
      - throwaway894345 6y ago
        In my opinion the two are very comparable. If filter() is more readable, it’s not by much, and this is all micro optimization bike shedding. I’ve never had a hard time using the idioms in a given language, and things like map/filter vs for loops were never what pushed me away from or pulled me towards a language. The important things are almost always learning curve, tooling, ecosystem, performance, maintainability, etc and Go does very well in many of those respects. The actual in-language features are generally just gravy. Note that the Python people have map/filter/reduce (and have had them for ages) and no one uses them. It’s either for loops or list comprehensions, and people notoriously struggle with the latter.

fwip 6y ago

Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way. Here are three options that were on the first page of google: * https://github.com/kulshekhar/fungen https://github.com/kulshekhar/fungen * https://github.com/awalterschulze/goderive https://github.com/awalterschulze/goderive * https://github.com/cheekybits/genny https://github.com/cheekybits/genny

throwaway894345 6y ago

I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.

erik_seaberg 6y ago
filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.
- throwaway894345 6y ago
  Wall? var out []X for _, x := range elts { if condition(x) { out = append(out, x) } } That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block. I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.
  - eweise 6y ago
    elts.filter(condition(x)) way more readable.
    - theshrike79 6y ago
      Only if you know what a filter is and how the condition is parsed. In more cases than one the condition is a lambda-monstrosity shoved in the filter function, which makes it even harder to parse.
      - fomine3 6y ago
        In the situation, even for statement also become monster.
    - marcus_holmes 6y ago
      Not if you're not used to it. Literally had this over the past few months working with a junior programmer who had a really hard time understanding stacked map()s and filter()s but understood them easily when I unrolled them into nested for loops.
      - eweise 6y ago
        The junior programmer would have been much better off learning how a filter function works so they could be productive in almost every other language besides Go.
        marcus_holmes 6y ago
        This was Javascript. And yes, I was teaching him how filter functions worked. But the point remains that if you're not used to them, map() and filter(), especially when stacked, are not that readable.
    - throwaway894345 6y ago
      In my opinion the two are very comparable. If filter() is more readable, it’s not by much, and this is all micro optimization bike shedding. I’ve never had a hard time using the idioms in a given language, and things like map/filter vs for loops were never what pushed me away from or pulled me towards a language. The important things are almost always learning curve, tooling, ecosystem, performance, maintainability, etc and Go does very well in many of those respects. The actual in-language features are generally just gravy. Note that the Python people have map/filter/reduce (and have had them for ages) and no one uses them. It’s either for loops or list comprehensions, and people notoriously struggle with the latter.