Poll: should default sort behavior be "fast" or "stable"?

Hello.

Related to https://github.com/crystal-lang/crystal/issues/6057

Today Crystal’s only option for sorting is “unstable” but fast quicksort.

This means that things like ary.sort_by(&.x).sort_by(&.x) don’t actually make sense, the second sort_by scrambles what the first did. Java gets around this by sorting “stably” by default.

There’s also some “other” sort algorithms that take up slightly more space but are “faster” than quicksort.

So the question of the day is…what should the default sort behavior best be? Fast? Stable? Even faster but using more memory? Stable for just sort_by?

Thoughts and opinions welcome here! I just wasn’t sure if crystal focuses more on “ease” to the programmer, or more on “speed” by default, so asking for a poll here to learn more. Thanks!

For me, preferred default would be “easiest for the programmer” (i.e. stable). Make the rest optional, for cases when people have profiled, and found they need speed and understand the consequences… :)
You can even have stable for object sorts, but “unstable” for integer sort (etc.) since re-ordering doesn’t matter… :). Actually my preference for integer sorts would be “as fast as possible by default” since reordering doesn’t matter. Default to the fastest :)

2 Likes

Stable. Crystal should always put sanity of mind first. Performance doesn’t help if the result is incorrect or the correct result is hard to achieve.

Adding optimization for hot paths is always possible, but needs to be opt-in.

8 Likes

I’d prefer stable-sorting by default.

2 Likes