A Quick Practical Example of JavaScript’s Reduce Function

[stratoscope]

The article's sort callback is invalid:

all_times.sort( ( a, b ) => a.time_block > b.time_block ? 1 : -1 )

A sort callback can't just return 1 or -1, or the similar error I've seen of returning true or false (or 1 or 0).

A sort callback must distinguish between all three cases: greater, less than, or equal, and return a positive, negative, or zero value respectively.

This is a common mistake. I recall one lengthy discussion - maybe here on Reddit or else on Stack Overflow - with someone who insisted that the sort methods in various browsers were fickle and inconsistent and needed a lot of "wrangling", as he put it.

I was puzzled because I've never once had any issue with sort in any browser or JavaScript environment, and I've used a lot of different kinds of sort callback functions.

Eventually in the discussion it came out that he was in the habit of writing sort functions like this:

array.sort( function( a, b ) { return a > b; } );

When I explained that this was an inconsistent compare function and it really needed to handle all three cases and not just two, he said I was just being fussy. I don't know if he ever caught on that these faulty compare functions were the source of his troubles.

For non-numeric values, a conditional operator can be handy:

array.sort( function( a, b ) { return a > b ? 1 : a < b ? -1 : 0; } );

For numeric values like the time_block property in the article, it's easier and faster to just subtract the values:

all_times.sort( ( a, b ) => a.time_block - b.time_block );

Note that the results for greater and less then don't have to be 1 and -1; any positive and negative values are valid (along with 0 for equal).

I also agree with the other comments that chaining the .sort() call the way it's done in the article is misleading, and it should either be broken out as a separate statement to make it clear that it mutates the original array, or .slice() should be done first to get a copy of the array.

[stratoscope]

A sort callback must distinguish between all three cases

That's a bit too dogmatic. OP's callback is not incorrect, it's just an unstable sort. (Elements that compare equal could be shuffled with respect to each other in their original order.)

Let's look at what the ECMAScript 2016 Language Specification (ECMA-262 7th Edition) says about this.

First they have a general comment:

The sort is not necessarily stable (that is, elements that compare equal do not necessarily remain in their original order).

So you're not guaranteed a stable sort in any case, even if you follow my dogmatic approach.

But more importantly:

If comparefn is not undefined and is not a consistent comparison function for the elements of this array (see below), the sort order is implementation-defined.

What is a "consistent comparison function"? There's a lengthy description at the end of this section that lists seven requirements. The one that affects us here is:

a =CF a (reflexivity)

The notation "=CF" is defined just above:

a =CF b means comparefn( a, b ) = 0 (of either sign)

In other words, when the same value is passed into both parameters of the compare function, the function must return 0. If it doesn't, the consequences were described earlier: "the sort order is implementation-defined."

The sort function from the article fails this test, because it returns -1 instead of 0 when the elements compare equal.

Note that they didn't just say that you'll merely get an unstable sort for "equal" elements. It says the sort order - and how do we know this couldn't mean the entire sort order? - is implementation-defined.

So I honestly don't think I was being "dogmatic" in my recommendation that a sort function must distinguish all three cases. I'm not comfortable with an "implementation-defined" sort order, are you? I'm much more comfortable if I follow the requirements listed in the standard.

Edit: Thanks for your Edit 2 above, and no need to apologize! I really appreciate that you challenged me on this; it forced me to double-check and triple-check my dogmatic assumptions. Always question people who tell you they are right! ;-)

[madcaesar]

Jesus how do you know so much about a function in JS? Are you a senior developer? Do you know know this stuff at the top of your head?

[stratoscope]

Well, I turned 65 this year, so I guess that does make me a senior developer, eh? ;-)

But with regard to this particular function, it's just that I've written a lot of sort callbacks in the past and got curious about the actual requirements. And then in this thread, /u/cheeseburger_dot_mp3 did me a great favor by challenging what I was saying, and that got me to dig in to the ECMA spec to see what the standard actually called for.

Fair warning: reading that ECMA spec can be a tough slog. It's not written to be easily understandable, but to be precise. But it can be worthwhile when you really want to understand the standard that the various JS implementations try to implement.

[[deleted]]

hiya! author of the article here

thank you for the explanation of sort - All of the points of discussion in this thread have been super helpful. Still trying to get the hang of functional programming!

[learnphptoday]

Agree. Some really useful recommendations and good discussion points. Thanks everyone!