Что такое «правильная программа»?

Статья в целом неплохая.

Однако существует ряд всяких «но»Например в разделе 1 написано
о простоте алгоритмов: простые алгоритмы не всегда эффективны. Например самый простой вид сортировки это пузырьковая, но более сложные алгоритмы Шелла и Квика или Блочной сортировки работают гораздо быстрее. Тому кто только начал заниматься программированием понять эти алгоритмы будет достаточно сложно. К тому же чем более универсальная программа тем она будет более сложной для понимания.

Что касается пункта 3, то на него следует наложить определенные рамки
по сложности программы. Например исходники «винды» без комментариев будут нечитабельны. То есть в сложных программах нужна очень большая модульность что бы информацию можно было воспринимать
доступными порциями, но дело в том что такая модульность тоже ведет к усложнению программы.

Aleksey,
Вопрос в п.1 - не в эффективности как таковой. Там не рассматривается эффективность ни по скорости, ни по памяти. Там вопрос в том, насколько устойчиво будет работать та программа.

Когда я говорил об уменьшении количества входных и выходных данных, я имел в виду не то, что что нужно жертвовать эффективностью во имя простоты, а то, что часто встречаешь программы, в которых несколько независимых между собой задач решаются одной общей функцией и в результате эта функция принимает на вход данные по каждой из задач и возвращает результат по всем задачам. В этой функции сначала решается кусочек первой задачи, потом кусочек второй, потом кусочек третьей, потом снова кусочек первой, а потом снова кусочек третьей. Это вместо того, чтобы сделать три функции, которые решают каждая свою задачу. Когда видишь вот такой алгоритм, состоящий фактически из переплетения нескольких алгоритмов - начинаешь думать одновременно о всех (в данном примере) трёх задачах, которые он решает.

Нужно, правда, учитывать, что для начинающих программистов не очевидно, решает ли их алгоритм одну общую задачу или несколько независимых задач. Они наваяли код и думают, что это - самый простой способ. Чтобы понять, что задач решается несколько, нужно иметь опыт. Здесь вопрос в алгоритмизации; в том, чтобы программист понимал, какие задачи и как он решает. Программисты, которые ваяли приведённый в предыдущем абзаце пример, убеждены, что они решали цельную, не делимую на части задачу.

Вопрос в п.1 - не о начинающих программистах, которым «понять будет достаточно сложно» чужой алгоритм сортировки. А о тех программистах, которые способны придумать десять собственных способов и выбрать среди них лучший.

Дополнительно, по поводу простоты, замечу, что очень многие программисты стремятся повысить эффективность (часто даже не задумываясь над тем, по каким именно критериям) за счёт чаще всего - усложнения кода. При этом единицы удосужатся провести экспериментальные исследования. В большинстве же случаев реально получается так, что придуманные этими программистами фишки для повышения эффективности - только снижают эту самую эффективность.

К п.1 могу добавить, что иногда имеет смыл упростить саму задачу. Возможно даже, упростить за счёт эффективности. Ломается обычно лифт, а не лестница. Хотя, конечно, никто же не спорит, что лифт удобнее лестницы. Вот только как Вы будете выбираться из здания, если лестницы не предусмотрены, а свет выключился из-за пожара?

В Вашем примере с быстрой сортировкой, сортировка пузырьком - лучше, потому что она понятнее. Этот самый начинающий программист получит более правильную программу, если будет использовать более понятный ему алгоритм. А если он будет использовать метод быстрой сортировки, до конца в него не вникнув, то ошибок не избежать. Но вопрос этот не нужно сводить к личным способностям и наличию/отсутствию лени каждого отдельного программиста.

В действительности в методе пузырька нет ничего хитромудрого, в отличие от тех алгоритмов, которые явно можно упростить и, поэтому, назвать неправильными по критерию чрезмерной сложности.

П.3 - написано же: «эвристика». Когда я придумывал ту эвристику, я думал не о тех редких случаях многомегабайтных исходников, написанных профессионалами, о которых говорили Вы, а о тех чуть ли ни ежедневно встречающихся мне программках в несколько строк, в которых без комментариев даже автор разобраться не может.

Если какая-то часть исходников «винды» - не читабельная из-за отсутствия комментариев, то это совсем не является доказательством того, что другие сложные нечитабельные программы - правильные. Вы привели в качестве примера винду, скорее всего, из-за того, что она не просто большая, она - огромная; чтобы внести туда какие-то изменения и правки, нужно поднять огромное количество людей; необходимость приведения исходников винды в читабельный вид - практически нулевая, потому что она и так работает. У Вас нет автоматических тестов для модулей винды, поэтому, внося изменения в исходники винды Вы не можете быть уверены, что после Ваших изменений она останется работоспособной.

Я же в своём примере говорил о случаях, когда программист задумывается о правильности программы и готов для повышения правильности прилагать усилия. Я убеждён, что любой нечитабельный исходник можно рефракторить и привести к читабельному виду, не вводя туда комментарии.