Серьёзный человек, не стоит обижать господина.

Napilnik это известный на весь ЛОР мракобес - сторонник теорий торсионных полей, эфира и всяких лженаучных проходимцев вроде катющика.

O(n) с промахом в кеше на каждом шаге это ...

O(n*n) ибо вложенный цикл

индустриальные стандарты и реальные перспективы в бизнесе

реальные стандарты и реальные перспективы - для реальных училищ, а автор всего лишь препод в универе, а там на выходе должны получаться или учОные теоретики или практики сами задающие стандарты индустрии.

сами задающие стандарты индустрии.

Ётофоноделы из Сколково...

Не значит. У неё своя сфера применимости. Выбор алгоритма или его реализации это комплексный процесс, зависящий и от предполагаемых типичных входных данных, и от конкретного компьютера и от других факторов. И оценка О-большое это только один из параметров алгоритма.

Мне не попадалась ни одна книга, где существовали бы четкие недвусмысленные правила подсчета шагов в алгоритме и как следствие оценки О большое, может быть Вам попадалась ? А смысл вопроса заключается в том что очень может оценка ЗАВИСИТ от метода подсчета шагов и соответственно от железа на котором все будет выполняться, а соответственно существующие оценки (в учебниках) - это сферические лошади в вакууме

Собственно вопрос имеет смысл в контексте топика, автор много рассуждает про вычисления, но чисто теоретически...

P.S. немного на вентилятор: на стр.161 автор утверждает, что watchdog невозможен - это отрицание очевидного ?

На стр. 161 я утверждаю, что обнаружение зацикливания (в просторечии зависания) процесса есть алгоритмически неразрешимая задача. Это вызывает какие-то сомнения? Если что, к небезызвестной самоприменимости она сводится за два шага.

Watchdog не обнаруживает зацикленные задачи, он для этого слишком туп. И, кстати, watchdog вообще не из этой предметной области. Но в операционках тоже есть что-то подобное: вместо обнаружения зацикливания делается отсечка по времени исполнения. Разницу между отсечкой по времени и обнаружением повторения состояния процесса понимаем?

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

но мне более интересно услышать Ваш ответ первую часть поста!

автор много рассуждает про вычисления,

В обсуждаемом первом томе имеется весьма поверхностный обзор теории вычислимости, которая, заметим, не имеет никакого отношения к тому, о чём вы тут говорите. Все эти оценки сложности и т.п. — это отдельный предмет, который называется «вычислительная сложность алгоритмов». Теория вычислимости этим не занимается, там исходят из предположения о наличии неограниченного количества времени и неограниченной то ли памяти, то ленты, то ли чего-то ещё.

Глава о вычислительной сложности если где-то и появится, то в последнем томе. Чтобы рассуждать о вычислительной сложности алгоритмов, нужно для начала научиться обращаться с самими алгоритмами, в противном случае это будет пустой звук.

Разницу между отсечкой по времени и обнаружением повторения состояния процесса понимаем?

• Алгоритм должен каждый N шаг сообщать, что он работает
• Если алгоритм перестал сообщать он либо завершился, о чём сам сообщил, либо зациклился
• Если wdt видит, что алгоритм не сообщил и не отвечает, то он зациклился, либо делает что-то еще...

Что не так в этой логике? Косвенные улики и исключающие обстоятельства не являются доказательством преступления?

Глава о вычислительной сложности если где-то и появится, то в последнем томе. Чтобы рассуждать о вычислительной сложности алгоритмов, нужно для начала научиться обращаться с самими алгоритмами, в противном случае это будет пустой звук.

А зачем тогда презирать тех, кто путается в STL, там list и тп? Они же ещё не дочитали до 3-его тома. Зачем запрещать это использовать?

я вот из практических соображений не отличаю процесс выбросивший исключение

Я, честно говоря, вообще не понимаю, каковы могут быть ваши «практические соображения». Процессы не выбрасывают исключений, но если предположить, что вы имели в виду аварийно завершившийся процесс, то он вообще-то проблем с системной точки зрения никаких не представляет. Он же завершился. Ресурсов больше не жрёт, памяти не занимает. Всё, его больше нет, был процесс — была проблема, нет процесса — нет проблемы. После аварийного завершения проблемы возникают у того, кто писал программу, но никак не у администратора системы.

в конечном счете и того и другого можно уничтожить

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

STL, там list и тп? Они же ещё не дочитали до 3-его тома. Зачем запрещать это использовать?

Что, совсем читать не умеем? Ну так повторяю в третий или четвёртый раз: если человеку дать в руки STL, не научив его работать со списками и массивами вручную, то он больше НИКОГДА не научится с ними работать и никогда не поймёт, что на самом деле делает, когда пишет магическое слово 'vector' и ещё более магическое слово 'list'.

Это даже если считать, что контейнерные классы чем-то полезны, хотя на самом деле никакой пользы от них нет, только вред.

а вот с этого места поподробнее...

В обсуждаемом первом томе имеется весьма поверхностный обзор теории вычислимости, которая, заметим, не имеет никакого отношения к тому, о чём вы тут говорите. Все эти оценки сложности и т.п. — это отдельный предмет, который называется «вычислительная сложность алгоритмов». Теория вычислимости этим не занимается, там исходят из предположения о наличии неограниченного количества времени и неограниченной то ли памяти, то ленты, то ли чего-то ещё.

А зачем нам теория вычислимости для того чтобы научится программировать ?

А зачем нам комбинаторика, если мы не хотим определить какой алгоритм лучше и почему он лучше?

В свете Вашего ответа вопрос: «Какое отношение первая часть книги имеет к обучению программированию?» - становится неожиданно актуальным

А смысл вопроса заключается в том что очень может оценка ЗАВИСИТ от метода подсчета шагов и соответственно от железа на котором все будет выполняться, а соответственно существующие оценки (в учебниках) - это сферические лошади в вакууме

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

не значит ли это что оценки О большое в части случаев можно смело отправлять на помойку?

Значит, кроме «смело».

Для некоторой пары двух конкретных реализаций алгоритмов на конкретной аппаратно-программной платформе и ничуть не менее конкретном наборе данных может иметь несоответствие полученных в действительности реальных затрат их теоретической оценке по мат-модели «большого О».

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

Поэтому для «прикидки на глазок» мы пользуемся О-оценкой, а там, где действительно важны реальные затраты, - профилированием.

Единственная причина любви к Pascal у российских преподавателей - это то что они уже его освоили

Мне его вообще-то вспоминать пришлось. Мой основной инструмент (в смысле когда я не преподаю, а программи пишу) — не поверите, как раз C++. Так что мимо, мимо.

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

progress bar ! log it! и кстати то что я предложил это из области программирования, а молчащий процесс должен быть уничтожен

кстати когда процесс чего-то ждет, а исключение произошло в его «контрагенте», первый благополучно жрет память дальше

то он больше НИКОГДА не научится с ними работать и никогда не поймёт, что на самом деле делает, когда пишет магическое слово 'vector'

Собственно как я уже говорил, категоричность, это Ваше самая большая проблема, ИМХО. Дело будет по другому, студента попросят написать быстрой алгоритм, он сделает это, но результат не будет устраивать никого. Так как у соседа по парте будет работать в 100 раз быстрее. Вот именно в этот момент наступит Ваше НИКОГДА. Студент задумается с фигали у него вcё так медленно, полезет в разбираться и начнётся просветление.

Но если все его задачи ставятся, как отсортировать 100 uint32 чисел значений на i7, то он будет использовать метод пузырька написанный на ruby и даже не замечать проблемы. Если работает зачем что-то менять?

Не кажется ли Вам, что проблема «тупости» студентов, это просто постановка неправильных задачь?

А зачем нам теория вычислимости для того чтобы научится программировать ?

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

Просто мне не вполне интересны те люди, которым она «низачем». И книжка, в конечном счёте, не для них. Мне больше интересны те, кого интересует не только вопрос «как вот прям щас сделать это и то», а вопрос «почему именно так». Здесь нужен определённый кругозор, и, с моей точки зрения, не знать, например, что такое «тезис Чёрча» просто нельзя.

вот ведь так и думал

Поэтому для «прикидки на глазок» мы пользуемся О-оценкой, а там, где действительно важны реальные затраты, - профилированием.

но ни в одной книге не видел...

никогда не поймёт, что на самом деле делает, когда пишет магическое слово 'vector' и ещё более магическое слово 'list'.

это еще пол-беды, а вот если еще и познакомить «читателя» с STL'ным sort? %)

- Quick sort? Не... не слышал.

Какой ещё нахрен «пузырёк на руби»? Он сделает #include <algorithms> и применит std::sort. И всё будет работать ОЧЕНЬ быстро. При этом он не будет знать, как написать не то что qsort, но и этот ваш пузырёк. Задачу же за него уже кто-то решил, всё.

Вообще мне уже давно надоели люди, которые рассказывают МНЕ, как надо преподавать, при том что сами этого делать не пробовали.

Мне не попадалась ни одна книга, где существовали бы четкие недвусмысленные правила подсчета шагов в алгоритме и как следствие оценки О большое, может быть Вам попадалась ?

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

А смысл вопроса заключается в том что очень может оценка ЗАВИСИТ от метода подсчета шагов и соответственно от железа на котором все будет выполняться, а соответственно существующие оценки (в учебниках) - это сферические лошади в вакууме

Пока мы говорим о традиционных вычислительных машинах, оценка не зависит от метода подсчёта шагов и существующие оценки это не сферические лошади в вакууме, а вполне применимы на практике.

Вот Вы конечно извините, но предисловие Страуструпа к его учебнику С++ больше привлекает (только не надо со мной С++ обсуждать я его просто не знаю, вообще никак, еще не прочитал учебник...)

А тезис Черча не является необходимым ни для кого кроме математиков, занимающихся теорией вычислимости...

И, скорее всего, никогда не увидишь. Книги не хранят _все_ знания.

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

Пока мы говорим о традиционных вычислительных машинах, оценка не зависит от метода подсчёта шагов и существующие оценки это не сферические лошади в вакууме, а вполне применимы на практике.

вот говорят, что sort в python ни разу не оптимален в общем случае, но на практике вполне себе устраивает большинство пользователей

Мне почему-то казалось, что ВМК МГУ — одно из лучших мест, где учат программировать. Очень удивлён, что там настолько слабый набор, что многие, по Вашим словам, даже не умеют к первому курсу писать хеллоуворлды.

Вон Дейкстра активно проталкивал Хаскель для изучения на первом курсе, т.к. с императивным программированием студенты уже знакомы, и неплохая идея познакомить их с другими парадигмами. Во всяком случае, понять новую парадигму, когда умеешь программировать на уровне «умею решать простые олимпиадные задачки на Pascal/Java/C++/Python/whatever», проще, чем когда несколько семестров только их и изучал (а то и профессионально на них писал много лет) и привык считать, что программирование — это когда переменные, циклы и вот это вот всё.

progress bar ! log it! и кстати то что я предложил это из области программирования, а молчащий процесс должен быть уничтожен

Н-да, фейл. Данное дерево обработке не поддаётся.

вот говорят, что sort в python ни разу не оптимален в общем случае, но на практике вполне себе устраивает большинство пользователей

Я не копался в исходниках пайтона, но на 99% уверен, что он вполне оптимален и имеет стандартную асимптотику O(N logN).

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

большинство быдлокодеров считают себя «профессиональными программистати», им не помочь даже если они умеют только Hello World написать, который бы компилировался

Вообще мне уже давно надоели люди, которые рассказывают МНЕ, как надо преподавать, при том что сами этого делать не пробовали.

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

Но эти люди меня научили тому, что нужно всё же прислушиваться ко всем мнениям и менять свои представления, если они ошибочны.

Собственно Вы воспринимаете абстрактные примеры (сказал sort, подберите любой другой алгритм) как что-то конкретное. Из-за чего не даёте ответ на вопрос. Вы же прекрасно понимаете, что я вас спрашивал про постановку задачи а не sort.

Я не копался в исходниках пайтона, но на 99% уверен, что он вполне оптимален и имеет стандартную асимптотику O(N logN).

где-то в интернетах есть объяснение разработчиков почему выбран алгоритм (не помню название) не оптимальный в ряде случаев и оптимальный в большинстве, я думаю спецы по алгоритмам вспомнят название

Н-да, фейл. Данное дерево обработке не поддаётся.

за дерево и ответить можно...

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

чувак, на ВМиК МГУ учат ДУМАТЬ и заставляют мозги шевелиться в правильном направлении, тогда ты все поймешь

Мне почему-то казалось, что ВМК МГУ — одно из лучших мест, где учат программировать.

Мне до сих пор так кажется. Вокруг всё ещё хуже.

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

Мне на ВТОРОМ курсе попадаются такие. Только не спрашивайте, как они ухитряются при этом первый курс проскочить.

Вон Дейкстра активно проталкивал Хаскель для изучения на первом курсе

Неприемлемо вообще, от слова совсем. Безумно высокий порог вхождения, это раз (ещё лисп какой-нибудь можно было бы, ну там Scheme как в SICP'е). Где вы преподавателей найдёте, это два.

т.к. с императивным программированием студенты уже знакомы

Такие есть, но их мало и ориентироваться на них не получается. Да и не нужно. Студентам, которые при поступлении на первый курс уже умеют программировать, преподаватель по программированию не нужен, тут лучше всего не мешать.

И, кстати, их всё меньше и меньше. Когда я поступал в 1992 году, я уже программировал за деньги, и таких в моей группе было ещё четверо. Когда я в «нулевые» начинал преподавать, в каждой группе находилось два-три человека, которые всё это уже давно знают и умеют. Сейчас... ээ... если не ошибаюсь, последний такой студент у меня был четыре года назад.

А альтернативные парадигмы — это хорошо, это просто замечательно. Это я так, на всякий случай. Я вообще-то руковожу спецсеминаром «парадигмы программирования» и читаю одноимённый курс. В магистратуре. Раньше такое вкрячить не получается.

тебя еще и крайне толерантно назвали, хотя аналогия и была с другим деревом, но ты, выидимо, стучался лбом только об один их вид :))

ну давай, объясни мне разницу между хамством и троллингом. как по мне, так те же тестикулы, вид с боку

прежде чем заниматься преподаванием рекомендую уяснить разницу между хамством и троллингом

Манера изъясняться у гражданина Croco прям скажем очень не похожа на манеру общения человека работающего в ВУЗе, скорее напоминает какого-то студента-недоучку, при этом довольно гоповатого и недалёкого.

лень мне сегодня хамить, настроение хорошее...ляпота

Алгоритм должен каждый N шаг сообщать, что он работает

Проблема ровно вот здесь. Алгоритм никому ничего не должен. Больше того, алгоритм не обязан состоять из шагов, это представление устарело лет на восемьдесят.

Если можно каким-то образом гарантировать, что «каждые n шагов» программа кому-то что-то скажет, то с таким же успехом можно было бы гарантировать, что она не зациклится. А этого, как мы знаем, не получается. Это раз. Зациклившаяся программа совершенно запросто может каждые N шагов что-то кому-то говорить, но при этом продолжать «молотить в холостую» (например, вычисляя одну и ту же строчку матрицы в стотриллионный раз). Это два. То есть вообще-то программа сама о себе тоже не может сказать, что она зациклилась — точно так же, как этого о ней не может сказать никто.

Алгоритмическая неразрешимость — штука упрямая, а волшебства в мире не бывает.

Вон Дейкстра активно проталкивал Хаскель для изучения на первом курсе

Неприемлемо вообще, от слова совсем. Безумно высокий порог вхождения, это раз (ещё лисп какой-нибудь можно было бы, ну там Scheme как в SICP'е).

А можно чуть подробнее? Чем именно высок этот порог? В некотором смысле, кажется, наоборот, должно быть проще. Вспоминая хотя бы упомянутый вами «алгоритмический кретинизм».

И да, я не с целью поспорить, мне действительно интересно.

Если можно каким-то образом гарантировать, что «каждые n шагов» программа кому-то что-то скажет, то с таким же успехом можно было бы гарантировать, что она не зациклится.

В этом и проблема, программист гарантирует это, программирует, а программа берёт и зацикливается из-за ошибок в коде. Он говорит что это невозможно, а потом винит себя, что какую-нибудь <= вместо < поставил, и проблема выявляется только 29 февраля. Это ровно тот случай про который я вам говорил. Отлаживать программу и писать тесты надо сразу.

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

Если алгоритм такой, что не может это гарантировать, то да, дело плохо. Из Ваших слов же можно понять, что wdt бесполезен чуть менее чем всегда.

А можно чуть подробнее? Чем именно высок этот порог?

Ну расскажите мне, что такое монада.

Это у нас на семинаре такая традиция есть. Поскольку семинар про парадигмы, студенты-хаскелисты многие к нам стараются попасть, так что недостатка в знающих Хаскель не наблюдается. Вот приходит такой третьекурсник с огнём в глазах и говорит, мол, я хочу доклад сделать. По Хаскелю. Руководители семинара синхронно ухмыляются и говорят — окей! Давайте ещё раз послушаем про монады. В смысле, послушаем ещё одно изложение.

Пока что сколько было докладов, столько было разных точек зрения, примерно как «слон похож на столб» vs. «слон похож на шланг». Само по себе это хорошо, мы такие доклады слушаем с удовольствием. Но у нас, понимаете, тусовочка специфическая, мы всё-таки избрали парадигмы объектом изучения.

А теперь меняем вводную. Аудитория изначально ни в чём не заинтересована (в большинстве своём), плюс к тому даже те, кто хотят стать программистами, через одного уверены, что Хаскель — это такая хрень для упёртых, на которой денег не заработаешь. И вам надо этой аудитории объяснить Хаскель так, чтобы они смогли сдать зачёт.

По-поему, unreal. Им Паскаль-то объяснить не все могут, указатели вон едва ли не треть «ниасиливает» в первом семестра. А тут вы со своим хаскелем и монадами.

Отлаживать программу и писать тесты надо сразу.

Разумеется, надо. Только в мозг обучаемому нельзя запихнуть сразу всё, что ему надо. Особенно то, про что его пока что не убедили, что оно ему надо.

Вокруг всё ещё хуже.

Очень спорно — даже у нас в ИТМО (где, в общем-то, всё довольно плохо) при КРАЙНЕ лояльном к должникам деканате те, кто совсем не может в программирование, не дожили до второго курса. Впрочем, их и было от силы несколько человек на потоке. Чего уж говорить об СПбАУ и прочих универах, где уровень преподавания как минимум не хуже, а деканат строже.

Я тут промывал мозг людям, не знаю читали вы это или нет.

Вот пример в школе: учимся делить и умножать в столбик,

Делим число 741 на 13 получили результат. Как проверить, да разделим 741 на 57, получили 13? Ответ верен.

В вашем случае вы предлагаете 741/13 посчитать вручную, а потом сравнить результат с калькулятором. Я же утверждаю, что проверка результата с помощью тек-же средств программирования принесёт колоссально больше пользы.

Никаких забиваний мозгов тут нет. Просто вместо одной задачи вы решаете сразу две.

Совершенно не обязательно его заставлять изучать какие-то теории, отладчики и тп, просто написать программку для проверки результата и всё.

Аналогично с git, не нужно читать длинные трактаты о том что это такое и зачем нужно. Просто сказать, сохраните результат с помощью git commit -m «сообщение» и всё. Через некоторое время студент сам поймёт зачем это нужно было сделать, а если не поймёт, то просьба «покажи ка мне предыдущий вариант этой работы» поможет ему в этом.

кто совсем не может в программирование, не дожили до второго курса.

А вы каким образом определили, что все остальные «что-то могут в программировании»? Они вам сами сказали?

Нет, они просто сдали n домашек на джаве и плюсах, m экзаменов по ним же, дискретке и алгоритмам со структурами данных, да и вообще производят впечатление более или менее адекватных (касательно computer science) людей. Во всяком случае, уж Hello World на мейнстримном языке написать точно все осилят :)

Совершенно не обязательно его заставлять изучать какие-то теории, отладчики и тп, просто написать программку для проверки результата и всё.

На первых порах такая проверочная программа может быть сложнее, чем оригинал, и превышать возможности обучаемого. Но это даже не главное. Обучаемый должен тестировать программы, точно зная, зачем это надо, а не потому, что от него этого препод потребовал. Пока он пишет такие программы, которые гораздо проще протестировать «в лоб» (то есть запуская и вколачивая входные данные), нежели для этого написать тестирующую программу, отношение к требованию о наличии тест-сьюта будет примерно как ко всяким рефератам, отчётам и домашним работам. Должна для начала возникнуть отчётливая потребность в regress test'ах, а для этого программы сами должны стать достаточно сложными, чтобы там появились регрессы при редактировании.

Вот по моим подсчётам где-то к концу паскалевской части у наиболее разумных из моих читателей такая потребность возникнет. Раньше — точно нет.

Домашние работы вообще ни о чём, как вы понимаете. Экзамены — если письменные, то тоже ни о чём, если устные — то... э... в общем, мне достоверно известно, что МНЕ (хотя я экзаменатор довольно жёсткий) ухитрялись успешно сдать экзамен с микронаушником. Ну то есть на устном есть какой-то шанс выявить действительный уровень знаний, но тоже в общем так себе.

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

Croco, резюмирую свою позицию, настоящий программист должен осознать, что может ошибаться и делает это почти всегда. Сначала он ошибается когда выбирает алгоритм для программирования. Потом он ошибается когда пишет код, компилятор ему об этому говорит. И так-же должен понимать, что ошибся когда пытается выполнить свой код.

Программист ошибается всегда и везде, он должен быть параноиком, вставлять всегда проверки, assert-ы. Всегда подозревать, что где-то опять накосячил.

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

А если относится к этому так «я математически доказал» wdt не нужны, или я всё написал правильно зачем тестировать, или зачем я буду документировать, то и выходит то что есть сейчас. Ровно всё, что вы написали в разделе «Отладка» во вступительной части.