Most of the paper is a good joke, but Slowsort takes it a step further. It is just so inefficient I can’t help but laugh out loud each time I revisit the paper and re-understand the algorithm.
It ticks all the nice boxes, such as being easily proven correct, easy to implement, easy to parallelize, stable, no time wasted on unnecessary steps, can produce output as it sorts the rest.
At the same time, it’s Mergesort with a ridiculous merging step. But that means one can simply add a parameter to tune between Mergesort and Slowsort – if(rand(1,10) > 8) then slow else merge – so the code becomes tunable in terms of speed. Someone needs faster software? OK, I’ve got just the parameter for you :-D
If you haven’t implemented it yourself, give it a shot. It’s a transformative experience to see your computer struggle sorting an already sorted 100-entry array ;-)
Quantum Bogosort guarantees the best performance, since it destroys all universes where the list remains unsorted after the first shuffle.
Hashcash (as found in Bitcoin) is another example, albeit more egregious.
On the other hand, if you subscribe to the "reduced jams" view, then that would arguably have the effect of speeding up typing due to having to deal with jams less frequently.