I can understand it after some deciphering, but I think that’s only because I already know quicksort. I’d be interested in seeing if anyone new to sorting algorithms finds it illuminating.
Then again, maybe that’s not important to the author - it is a pretty funny illustration to those in the know.
I'm a programmer (after a fashion) but I don't know how quicksort works.
This is how I understand it after reading these instructiöns, without looking up any further explanation:
1. Choose a random element as the 'center' point of the sort
2. That element defines the maximum 'height' (value)
3. Anything that is larger than that value, is moved to the right side of the 'center'
4. Anything that is smaller than that value, is moved to the left side of the center. After this, the array is partially sorted.
5. The sorting process is repeated on both 'sides' independently, picking a new random center element and so on
What isn't clear, is how often the process needs to be repeated, or when the algorithm 'knows' that the sorting has been finished - surely it can't be just three iterations?
By now I've already looked up how the algorithm actually works, but the above is what I got out of the illustration :)
Also, to save any further puzzling: In practice the very fast sort you use, even if it is labelled "Quicksort" probably doesn't actually do this "all the way down" even though that's the strict algorithm.
They'll have a highly optimised small sort and use that whenever sorting very small things. So e.g. IPN Sort the Rust stdlib unstable sort will do this for 16 items, even though for a big slice it'd quick sort them by default, once it's down to say 10 items they're going to the specialised small sort.
Any serious "fast" sort in 2025 will be a hybrid, using several of these classic sorting algortihms, plus other insights to produce the overall best solution to their problem on modern hardware.
Then again, maybe that’s not important to the author - it is a pretty funny illustration to those in the know.