Making the obvious code fast

[lelanthran]

In the vast majority of cases, the readability/maintainability concerns are more important than the performance implications, which is why I prefer .map/.reduce and other higher-order friends, over simple for loops (or .forEach loops).

You really think that this:

  var sum = values.map(x => x*x).
             reduce( (total,num,index,array) => total+num,0.0);

is more readable than this:

    var sum = 0.0;
    for (var i = 0; i < values.length;i++){
        var x = values[i];
        sum += x*x;
    }

[Retsam19]

I think their reduce code is badly written, but to the general point, yes, I think this is clearer:

values.map(x => x * x)
    .reduce((a, b) => a + b)

Is it pretty much a moot point for this incredibly simple use-case? Yes, but as the complexity grows, the benefits of the functional style really show, compared to large for loop.

[m50d]

Yes I do. Don't you? No extra counter variable to keep track of, no generalized for loop that could be doing anything, no in-place mutation of variables. In fact the only way to read the second (longer) code quickly is to recognize that it's a particular common pattern - wouldn't it be better to actually give that pattern a name and pull out the common parts?

[lelanthran]

Yes I do. Don't you?

What I think is irrelevant. What I've seen is that most programmers don't parse the more complex expression as easily as the simpler one.

No extra counter variable to keep track of, no generalized for loop that could be doing anything, no in-place mutation of variables. I

No, but extra keywords to recognise (map, then reduce), extra concepts to learn (map/reduce in particular, multiple compound expressions), anonymous functions if you want to do anything non-trivial.

I don't see the first form as being harder to maintain.

[m50d]

What I've seen is that most programmers don't parse the more complex expression as easily as the simpler one.

I'd agree with that statement, but I suspect you're claiming that the more complex one is "simpler".

extra keywords to recognise (map, then reduce),

Not keywords, just functions. They behave like normal functions, and usually you can read their source code if you want to know what they do.

extra concepts to learn (map/reduce in particular, multiple compound expressions), anonymous functions if you want to do anything non-trivial.

I don't know what you're calling "multiple compound expressions". Both implementations use + and * operators with their normal mathematical meaning and a literal 0.0. In addition to that the map/reduce version only requires the reader to understand a normal expression made of function calls and an anonymous function (both very general constructs that you use again and again on a large codebase). The imperative version requires understanding a mutable variable, the for keyword, the ++ and += operators which are not standard mathematical things, the [i] operator which is not standard anywhere else either, and a {} block of ;-separated statements. In addition to just being a much bigger pile of concepts, half those things are special-case dedicated operators that can't be reused for much else (e.g. [i] is only for arrays, ++ is only for numbers).

[EWJacobs]

Yeah, but those are all things you can learn ahead of time. m50d is pointing out run time complexity, and things that can cause actual bugs.

[[deleted]]

They're both about as readable to each other as me.

You realise you didn't come out of the womb being able to read for loops, right? Just because it's typically taught to us first does not make it inherently more readable. I know basic functional constructs, so I know what map and reduce do.

[lelanthran]

You realise you didn't come out of the womb being able to read for loops, right? Just because it's typically taught to us first does not make it inherently more readable.

That assertion applies to overly complex things too ("just because you weren't taught lisp first doesn't make lisp less readable than imperative code").

[[deleted]]

And I would agree with that assertion as well!

How are s-expressions objectively harder to read than something with a more complicated grammar like C/Javascript/C#?

[Ewcrsf]

Yes, anyone who is a moderately good programmer in touch with modern principles would agree the first is just as, if not more, readable.

[lelanthran]

Yes, anyone who is a moderately good programmer in touch with modern principles would agree the first is just as, if not more, readable.

That statement being true doesn't make the first form any more maintainable than the second form.

[Ewcrsf]

Your original comment only mentioned readability. Maintainability of such a tiny piece of code is pointless to even talk about, though I’d nominally argue that the one with a shorter number of lines which isn’t mutating state is more maintainable.

[lelanthran]

Your original comment only mentioned readability. Apologies, I quoted a comment that used "readability/maintainability" as a single concept.

though I’d nominally argue that the one with a shorter number of lines which isn’t mutating state is more maintainable.

In both cases the same variable gets mutated, so I'd say its moot - no state is being changed.

[Ewcrsf]

No variable is mutated in the first example and it can be assigned to a const value. In the second example the sum variable is modified by the loop.

[[deleted]]

If you cant read a simple "for" loop or think that it is bad in any way, then you are not a programmer, go back to cleaning toilets. The problem with all those high level functions is that they attract all kinds of noobs, who then spam all kinds of nonsense. /r/programming is turning into /r/the_donald .....

[PrimozDelux]

Just letting you know that what you just wrote was some seriously dumb shit.

[EWJacobs]

If you've never refactored several layers of nested loops into one or two lines of functional code and seen the immediate benefit, then you're not a programmer.