'sorted()' doesn't really act like that, does it - taking in a comparator function? It's much better to have comparator functions for the most common types baked in, and use projection to select a list of fields to use to compare with. Comparator functions are very easy to get wrong. The example given here - ".sorted((a, b) -> a.getValue() - b.getValue())" - won't work properly when the calculation wraps around.
> It's much better to have comparator functions for the most common types baked in, and use projection to select a list of fields to use to compare with. Except that requires a sorting key for the result. Trivial for dynamically typed languages, but how do you handle the type of that key in a statically typed language? Mandate that the key be a string? Build a limited set of overloads against a dedicated type? And ev…
And I'll stand by comparators being easy to get wrong, particularly when values may be null, polymorphic, etc.