>> И въобще, алгоритмите за сортировка трябва да се познават, и да се избира най-подходящия за случая.

Размерът на масива обаче не е едиствения фактор, който трябва да се отчете при избора на алгоритъм за сортиране. Мисля че важат и следните неща:

1. "Бързите" алгоритми са по-сложни за имплементация - отнемат повече време, а както е всеизвестно не всеки е като "истинския програмист" - правят се грешки (било заради неумение или заради препиване предишната вечер :))).

2. В общия случай "бързите" алгоритми гълтат повече памет (за мехурчето или пряка селекция ти трябват 2 брояча и един буфер за размените, за quick sort трябва стек - дали ще е програмния или твой - все тая). Знам че на състезанията по информатика се отчита скорост, а не консумирана памет, но в реалния свят положението е друго.

3. Един час програмистко време е МНОГО по-скъп от един час машинно време, т.е. понякога (и то доста често) си заслужава да изберем нещо просто и бавно, но бързо за имплементация, отколкото нещо сложно и бързо, но да загубим много време да го пишем и дебъгваме.

4. Трябва да се отчита колко често сортираме. Ако да кажем програмата ти веднъж на всеки 20 секудни трябва да сортира един масив от 500 елемента, то мехурчето си е точно на място (сортирането отнема 20 ms на PIII 733 - 0,1% от общото време и то теста го писах на Java :)).