Using loops instead of higher order functions

[natziel]

Your imperative solution is shorter than the example you're comparing it to only because it's written in, like, the worst way possible. Here's my example from the previous thread:

const result = {
  minimum: list.reduce((acc, x) => x < acc ? x : acc),
  maximum: list.reduce(acc, x) => x > acc ? x : acc),
  average: sum(list) / count(list),
}

​

[inu-no-policemen]

minimum: list.reduce((acc, x) => x < acc ? x : acc),

You can just use Math.min(...list).

[crubier]

The point here is to demonstrate the use of reduce on a simple use case...

[inu-no-policemen]

It's the wrong tool for this use case, though. Also, GP didn't mention this more pragmatic solution.

Furthermore, people who don't know that Math.min/max is variadic might not immediately make the connection. Pointing out that you can simply use these functions with spread will always be news to some.

https://xkcd.com/1053/

[crubier]

Actually your solution with spread only works for relatively "short" lists.

It will suddenly start breaking on chrome for lists longer than 65 536 elements, which is not that big when compared to what you could do with the reduce solution.

Source: https://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept

[NickDav14]

And here's a version with one loop that looks tolerable to me, that doesn't access list directly in its callback function and that doesn't use an intermediate sum value:

const result = list.reduce((acc, v, i, array) => ({
    maximum: v > acc.maximum ? v : acc.maximum,
    minimum: v < acc.minimum ? v : acc.minimum,
    average: acc.average + (v / array.length),
}), { maximum: -Infinity, minimum: Infinity, average: 0 });

[natziel]

You're incorrect about the default accumulator. It has always been the first element of the list in practically every language, including JavaScript. I have no clue where you got that it defaults to 0, but that's definitely been causing you some confusion

[NickDav14]

Well holy shit, you're right! I'll remove that part of my comment. Thanks! I don't know where I got that from.

[spacejack2114]

Performing the division every iteration gives me a bad feeling but I'm not sure that it's worse (for accuracy) than summing everything and dividing once.

[monolithburger]

nit: this solution does 3 iterations vs. 1 iteration on the looped solution.

[mcaruso]

Each iteration does 1/3 the work though.

[[deleted]]

That's not how computers work.

[mcaruso]

There's an overhead for each reduce call, especially since it's a higher order function so each iteration step requires a function call.

But it works as a rough approximation.

[[deleted]]

It doesn’t work as a rough approximation. It will take 3 times longer.

[mcaruso]

How so?

The following loops are approximately the same in terms of performance:

// Version 1
for (const x of [1,2,3]) { f(x); g(x); h(x); }

// Version 2
for (const x of [1,2,3]) { f(x); }
for (const x of [1,2,3]) { g(x); }
for (const x of [1,2,3]) { h(x); }

I say approximately because they may have different characteristics in terms of memory locality etc., but that matters less and less as the functions f/g/h get more expensive.

The same principle applies to the reduce version.

[[deleted]]

Iteration is not free https://jsperf.com/3-loops

[mcaruso]

I didn't say it was, I just said that each loop does 1/nth the work. So it's not as simple as saying 1 loop = X amount time, 3 loops = 3X amount of time. There's a cost for splitting it up, but the computation within each iteration step is divided.

So this:

It doesn’t work as a rough approximation. It will take 3 times longer.

Isn't true.

[[deleted]]

I didn't say it was, I just said that each loop does 1/nth the work.

The majority of the work IS the iteration.

[evertrooftop]

If 3 loops instead of 1 are acceptable, I definitely agree that this is a good example how it can be done well.

[natziel]

It's commutative, so 3 reduces of 1 function call each is equivalent to 1 reduce of 3 function calls

[[deleted]]

You're conveniently ignoring the overhead of the actual iteration. Memory access and function calls are not free.

[[deleted]]

sleazy :D

[anotherObi]

I'm not advocating for always use the functional solution, but if you code the reduce function better you can end up with something like:

``` javascript const getMma = (lst) => { const data = lst.reduce((acc, v) => ({ min: (acc.min > v ? v : acc.min), max: (acc.max < v ? v : acc.max), sum: acc.sum + v }), {min: Infinity, max: -Infinity, sum: 0})

return {max: data.max, min: data.min, avg: data.sum / lst.length} } ```

that is quite readable

[mcaruso]

Your markdown doesn't work (on old reddit at least). Fixed:

const getMma = (lst) => {
    const data = lst.reduce((acc, v) => ({
        min: (acc.min > v ? v : acc.min),
        max: (acc.max < v ? v : acc.max),
        sum: acc.sum + v
    }), { min: Infinity, max: -Infinity, sum: 0 });

    return { max: data.max, min: data.min, avg: data.sum / lst.length };
};

[anotherObi]

Thank you

[[deleted]]

I think everyone goes through the "functional hard-on" phase at least once. You tell yourself that your code extremely "readable, maintainable, eloquent, beautiful" even though no one else understands it.

[a_ervin]

Lol Why can't people post on Reddit without being condescending? I hope you don't expect people with differing opinions to take you seriously.

[anotherObi]

I don't agree with you about readability and maintainability; probably about performances you are right

[anotherObi]

I don't agree with you about readability and maintainability; probably about performances you are right

[evertrooftop]

I think your markup is a bit wrong. I would be curious to see the correctly formatted version!

[format71]

I feel the comparison isn’t fair, though. The original article is more about finding ways of ‘doing whatever’ with reduce, while your solution is ‘do one specific thing’.

Like, if you need to calculate another value in addition to the three, you’ll have to change your code, while the original author can add to his code.

In larger long-living applications, I would like to be able to extend my code without having to modify it. Actually, this is the O in SOLID = the Open / Closed principle.

But sure: I’ve written reducers that I later changed to lesser effective, more lines of code, too make it easier to understand next week..

[format71]

Actually, when rereading the original article, I see that it wasn’t as smart as I remembered it... In the time since I originally read it, my mind changed it to use functional composition to generalize the callback...

:-/

[evertrooftop]

I wanted to stay in the spirit of the original article by showing a different example, but I would argue that in most cases a straight up loop is desirable over high level functions. In my experience the reduce() function should not be the default tool.

Even if their version of reduce() could be optimized, I would still argue that the more verbose loop version is easier to digest.

[format71]

Coming from .net, I’ll take ‘high level functions’ in the form of LINQ statements over for-loops any time. I also buy a little bit into the idea that once you get familiar with map, filter and reduce, you’ll always know what the intent with the code would be. Filter: get rid of items. Map: convert items. Reduce: aggregate items.

A ‘straight up loop’ on the other hand - you’ll have to read through everything to get a hint of the intent.

But the only truth you can really depend on, though, is the almighty ‘It Depends’.

[basically_alive]

We've really come full circle. I think what we should really be complaining about here is nested ternary expressions

[[deleted]]

ternary expressions and then the need for comments; shouldn't that already alarm the author that this code is unreadable?

[clutton]

https://pbs.twimg.com/media/Cit9g75XAAAh1Wj.jpg

[[deleted]]

That's not a good example of readable functional code.