3 ms·

For me, it's not a question of terseness -- it's more about communicating intent, and not polluting the scope with incidental variables. Everyone knows what map

For me, it's not a question of terseness -- it's more about communicating intent, and not polluting the scope with incidental variables. Everyone knows what map/filter/reduce do. When reading new code, seeing "map" is better than seeing a for loop: you don't have to think about the underlying iteration at all, you can skip directly to the essence of the transformation. As a side effect of this, when you do see a for loop, you can safely assume that something about the iteration is non-trivial: maybe the loop exits early, for example. I wrote a bit more about this here: https://twitter.com/lukechampine/status/1463715093733122054 https://twitter.com/lukechampine/status/1463715093733122054 btw, by "new PL territory" I mean "reifying a small set of container operations, without supporting user-defined generics," which to my knowledge is not a position taken by any mainstream language.

throwaway894345 5y ago
> For me, it's not a question of terseness -- it's more about communicating intent, and not polluting the scope with incidental variables. A mapping for loop doesn't pollute scope with incidental variables: results := make([]Result, len(input)) for i := range input { results[i] = callback(input[i]) } ^ This only adds `results` to scope, which is the same as `results := map(input, callback)`. In the for loop example, the loop variable `i` is scoped to the loop. Moreover, if you don't care about terseness, you can always pull this out into a well-named function or annotate it with a comment. > Everyone knows what map/filter/reduce do In isolation, but for complicated chains of map/filter/reduce (especially with error handling logic in languages which return errors rather than raising them as exceptions) it's much easier for me to read the corresponding for loop equivalent. Even my colleagues at a Python shop had limits on the complexity of list comprehensions beyond which point they were required to rewrite into a for loop because while packing that complexity into a single expression is elegant and clever, it's not particularly readable or easy to understand. I guess my view can be summarized as: for very simple cases, map/filter/reduce are a bit clearer, but for those same simple cases a for loop is still easily understood and a for loop's readability scales better with complexity.
- nemo1618 5y ago
  That's exactly the view I express in the Twitter thread lol

throwaway894345 5y ago

> For me, it's not a question of terseness -- it's more about communicating intent, and not polluting the scope with incidental variables. A mapping for loop doesn't pollute scope with incidental variables: results := make([]Result, len(input)) for i := range input { results[i] = callback(input[i]) } ^ This only adds `results` to scope, which is the same as `results := map(input, callback)`. In the for loop example, the loop variable `i` is scoped to the loop. Moreover, if you don't care about terseness, you can always pull this out into a well-named function or annotate it with a comment. > Everyone knows what map/filter/reduce do In isolation, but for complicated chains of map/filter/reduce (especially with error handling logic in languages which return errors rather than raising them as exceptions) it's much easier for me to read the corresponding for loop equivalent. Even my colleagues at a Python shop had limits on the complexity of list comprehensions beyond which point they were required to rewrite into a for loop because while packing that complexity into a single expression is elegant and clever, it's not particularly readable or easy to understand. I guess my view can be summarized as: for very simple cases, map/filter/reduce are a bit clearer, but for those same simple cases a for loop is still easily understood and a for loop's readability scales better with complexity.

nemo1618 5y ago
That's exactly the view I express in the Twitter thread lol