3 ms·

Yes. In Scala people seem to say it's the idiomatic way to sum a list of numbers which never felt right to me. It just seems to much code to look at for that.

yakshaving_jgt 3y ago
It definitely is the idiomatic way. How would you do it otherwise? Recursion?
secdeal 3y ago
in Scala the idiomatic way to sum is the method sum on collections List(1,2,3,4).sum Although this is indeed implemented with reduce. But is it really too much code? List(1,2,3).reduce(_ + _)
BigJono 3y ago
Summing a list of numbers is the exact kind of use case you should use reduce for. If it feels wrong to you it's just because you have more experience with for loops than reducers. In languages like JS that have both styles, the place you probably want to use for loops over reducers is for more complex operations where mutation can simplify the code. For example if you have 10,000 elements in an array that you want to aggregate into 1,000 properties on an object (with a non trivial relationship between array elements and object properties), it's probably going to look nicer in a for loop than it is in a reducer with a bunch of spread and ternary operators. IMO .reduce calls should probably be one line. If not then it's time to either write a for loop or compose more smaller functions. Avoiding them entirely is just FUD though. To compare summing an array in JS: let sum = 0; for (const n of numbers) { sum += n; } const sum = numbers.reduce((acc, n) => acc + n, 0); The latter is much nicer to read if you're used to both styles. What I particularly like about it is it clearly signals that 'sum' is a variable that we will be using further down. The for loop style leaves ambiguity as to whether 'sum' is going to be used later or if it's just some context for something that's happening inside the loop. Actually, to throw a hot take in the mix here, I think people should be more accepting of multiple statements across single lines in C-style languages. let sum = 0; for (const n of numbers) sum += n; That would be a perfectly fine way to signal to the reader that "this is a specific line of code to produce a sum value" (much the same as the reduce example), but people seem to have a dogmatic aversion to leaving braces off if/for statements or putting multiple statements on a single line.
- da39a3ee 3y ago
  I just expect it to be my list.sum() or sum(mylist) and to trust that the implementation under the hood is reasonable.
- ThinkBeat 3y ago
  I disagree. The first version is something most programmers could read and understand right away. I also dont understand why the second version signals use of the variable any better than the classic version, esp if you declare the variable right ahead of it, but that is the classic "C" style. How ever in a real system I would hope people use better names than sum. which would give it some comprehension of what the variable does / exists for. What is the obsession with one liners? Perhaps if paper was quite expensive and it was printed out paper on a regular basis you could save a few sheets, I dont think one long line is easier to read than several short lines. I suppose if everyone involved with the project prefers or is used to the second version it is fine.
  - BigJono 3y ago
    > I also dont understand why the second version signals use of the variable any better than the classic version, esp if you declare the variable right ahead of it, but that is the classic "C" style. Because you have no idea if the variable is used further down in the scope. Compare with something like parsing a csv file with support for quotes: let rows = []; let quoteMode = false; for (char c of csvFile) { ... } rows is the end result, quoteMode is state only relevant to the process happening within the for loop. There's nothing past variable names to distinguish their intended use. Whereas: const rows = parseCsv(csvFile); makes it totally clear. The reason something like reduce can make for nicer code is because it lets you do simple operations (probably not parsing a csv lol) inline in a way that makes the code just as clear as a function call would be, without adding a bunch of extra layers of abstraction (meaning more scrolling and flicking between tabs). Really it's not about the reduce function at all, it's about the "const foo =". Once you see that, you can completely disregard the rest of the line if you've already read it and/or are confident you know what it's doing. It acts as a refresher in a way that a for loop doesn't. After you get past the inital shock of seeing a scary one liner (which get less and less scary as you see them more), it makes the next 20 times you read it much more pleasant.
maharajatever 3y ago
[dead]

yakshaving_jgt 3y ago

It definitely is the idiomatic way. How would you do it otherwise? Recursion?

secdeal 3y ago

in Scala the idiomatic way to sum is the method sum on collections List(1,2,3,4).sum Although this is indeed implemented with reduce. But is it really too much code? List(1,2,3).reduce(_ + _)

BigJono 3y ago

Summing a list of numbers is the exact kind of use case you should use reduce for. If it feels wrong to you it's just because you have more experience with for loops than reducers. In languages like JS that have both styles, the place you probably want to use for loops over reducers is for more complex operations where mutation can simplify the code. For example if you have 10,000 elements in an array that you want to aggregate into 1,000 properties on an object (with a non trivial relationship between array elements and object properties), it's probably going to look nicer in a for loop than it is in a reducer with a bunch of spread and ternary operators. IMO .reduce calls should probably be one line. If not then it's time to either write a for loop or compose more smaller functions. Avoiding them entirely is just FUD though. To compare summing an array in JS: let sum = 0; for (const n of numbers) { sum += n; } const sum = numbers.reduce((acc, n) => acc + n, 0); The latter is much nicer to read if you're used to both styles. What I particularly like about it is it clearly signals that 'sum' is a variable that we will be using further down. The for loop style leaves ambiguity as to whether 'sum' is going to be used later or if it's just some context for something that's happening inside the loop. Actually, to throw a hot take in the mix here, I think people should be more accepting of multiple statements across single lines in C-style languages. let sum = 0; for (const n of numbers) sum += n; That would be a perfectly fine way to signal to the reader that "this is a specific line of code to produce a sum value" (much the same as the reduce example), but people seem to have a dogmatic aversion to leaving braces off if/for statements or putting multiple statements on a single line.

da39a3ee 3y ago
I just expect it to be my list.sum() or sum(mylist) and to trust that the implementation under the hood is reasonable.
ThinkBeat 3y ago
I disagree. The first version is something most programmers could read and understand right away. I also dont understand why the second version signals use of the variable any better than the classic version, esp if you declare the variable right ahead of it, but that is the classic "C" style. How ever in a real system I would hope people use better names than sum. which would give it some comprehension of what the variable does / exists for. What is the obsession with one liners? Perhaps if paper was quite expensive and it was printed out paper on a regular basis you could save a few sheets, I dont think one long line is easier to read than several short lines. I suppose if everyone involved with the project prefers or is used to the second version it is fine.
- BigJono 3y ago
  > I also dont understand why the second version signals use of the variable any better than the classic version, esp if you declare the variable right ahead of it, but that is the classic "C" style. Because you have no idea if the variable is used further down in the scope. Compare with something like parsing a csv file with support for quotes: let rows = []; let quoteMode = false; for (char c of csvFile) { ... } rows is the end result, quoteMode is state only relevant to the process happening within the for loop. There's nothing past variable names to distinguish their intended use. Whereas: const rows = parseCsv(csvFile); makes it totally clear. The reason something like reduce can make for nicer code is because it lets you do simple operations (probably not parsing a csv lol) inline in a way that makes the code just as clear as a function call would be, without adding a bunch of extra layers of abstraction (meaning more scrolling and flicking between tabs). Really it's not about the reduce function at all, it's about the "const foo =". Once you see that, you can completely disregard the rest of the line if you've already read it and/or are confident you know what it's doing. It acts as a refresher in a way that a for loop doesn't. After you get past the inital shock of seeing a scary one liner (which get less and less scary as you see them more), it makes the next 20 times you read it much more pleasant.

maharajatever 3y ago

[dead]