4 ms·

You’re right, there’s nothing inherently wrong with map, reduce and the rest of the high-order functional suite. What I’m talking about more is when people make

by OskarS 5y ago

You’re right, there’s nothing inherently wrong with map, reduce and the rest of the high-order functional suite. What I’m talking about more is when people make very complicated aggregation functions in order to keep state around. In these cases, simple for loops are usually much easier to read and as a bonus they’re almost always significantly faster. Not every problem benefits from a functional solution.

ratww 5y ago
I mean, sure, but the opposite is also true: Sometimes people make complicated incantations inside for loops (or worse, while loops) that could be replaced by simpler functional constructs. In these cases, map and friends are easier to read. The problem here is not one construct or the other, but the fact some people are making code that is hard to understand. There's no one size fit all solution.
jhgb 5y ago
> What I’m talking about more is when people make very complicated aggregation functions in order to keep state around Are we talking about languages without handy combinators? I can imagine that in these, turning stateless functions into stateful aggregators is going to be more obscure rather than easy. As for speed, that seems like an implementation issue. In principle a functional solution could still preserve more information for efficient code generation than a loop for which such information needs to be extracted from by complicated auto-vectorizers. In practice the environments aren't "quite there" (lack of such features as Common Lisp's compiler macros), and any potential or even realized benefits may be cancelled out by other performance issues of such environments.
- overgard 5y ago
  > As for speed, that seems like an implementation issue. At the end of the day though, it's still your issue, even if you can point at a 3rd party. Personally I'd rather have my fate in my own hands rather than wait on a "sufficiently smart optimizer"
  - jhgb 5y ago
    Hence my mention of compiler macros, which put the fate of the sufficiently smart optimizer into your own hands.

by OskarS 5y ago

ratww 5y ago

I mean, sure, but the opposite is also true: Sometimes people make complicated incantations inside for loops (or worse, while loops) that could be replaced by simpler functional constructs. In these cases, map and friends are easier to read. The problem here is not one construct or the other, but the fact some people are making code that is hard to understand. There's no one size fit all solution.

jhgb 5y ago

> What I’m talking about more is when people make very complicated aggregation functions in order to keep state around Are we talking about languages without handy combinators? I can imagine that in these, turning stateless functions into stateful aggregators is going to be more obscure rather than easy. As for speed, that seems like an implementation issue. In principle a functional solution could still preserve more information for efficient code generation than a loop for which such information needs to be extracted from by complicated auto-vectorizers. In practice the environments aren't "quite there" (lack of such features as Common Lisp's compiler macros), and any potential or even realized benefits may be cancelled out by other performance issues of such environments.

overgard 5y ago
> As for speed, that seems like an implementation issue. At the end of the day though, it's still your issue, even if you can point at a 3rd party. Personally I'd rather have my fate in my own hands rather than wait on a "sufficiently smart optimizer"
- jhgb 5y ago
  Hence my mention of compiler macros, which put the fate of the sufficiently smart optimizer into your own hands.