There you have your problem: any programmer can write a bubble sort while half asleep and inebriated at the same time, but for an insertion sort you actually have to think a little. There's much more chance of errors.
edited to add: someonefromca spotted a bug in the insertion sort; where it says
if (tmp > a[j-1]) break;
if (tmp >= a[j-1]) break;
this is some evidence in favor of your point that insertion sort is more error-prone; even if i could have made the same error in the bubble sort, i didn't, and possibly that was because the rest of the algorithm required less mental effort?
Maybe a fair judge of mental difficulty would say "you gotta write at least the loop invariant" (termination being too pedantically obvious) -- though admittedly I leave it out more than I used to.
When I was introduced to sorting as a new programmer, via bubblesort, I thought "why that way?" and came up with selection sort as a method that made more obvious sense. It seems to me like bubblesort's alleged intuitiveness is post hoc from the shortness of the code in terms of all-ascending for-next loops -- the intuitive reason it worked was just that the inner loop did move the next max into place just like selection sort, but with extra swaps along the way.
(FreeBSD got a test suite in 10.1, which came out in 2014, not that long ago in UNIX terms.)
People would be shocked by how little the core tools we use were tested automatically. Some still aren't.
Thankfully the practice of just randomly shelling out to 'random' programs (like the core tools) has been stemmed somewhat, so perhaps we're mostly safe from RCE via that vector. Downloaded files might still be a vector, tho. Maybe I'm an optimist even though I sound very pessimistic.
I dunno what FreeBSD's test infrastructure is, but I'm just saying that "it needs testing" is not a good reason not to change to a better sort algorithm in this case.
if your interests run the other way, that's great, and hopefully you will succeed in improving freebsd's testing infrastructure, but it's hardly a reason for colin not to speed up booting
but i don't think i saw anyone claiming that the change should not be made because it wouldn't be adequately tested?
Quote:
> will be reviewed and tested by 200 people before it reaches production
I was only saying that this is a bad argument for changing to any simple-ish sorting algorithm. (Because: add tests if you need assurance)
Granted, if you're doing super-complicated sorting algos with fallbacks for different sizes, heuristics for detecting semi-sorted input, etc. you might want something more sophisticated than trivial property-based checking.