Вообще, троллинг программистов — это легко и приятно. Вот вчерашний, например, был снова пойман на очередной глупости — сначала начал рассуждать, что goto пользоваться никак нельзя, а потом, после прямо заданного вопроса «а break, continue, try-catch ты используешь?» начал громко орать, что это совсем другое и никак нельзя эти конструкции сравнивать. Самое смешное — вроде бы в подтверждение своих слов он притащил известную статью Дейкстры, про «Go To Statement Considered Harmful«, и на этом стало понятно, что он ее не читал, от слова совсем.
Если совсем коротко ее пересказать — то дело в том, что процесс выполнения «структурной» программы (где используются только условные операторы и циклы) описывается крайне просто — фактически лишь номером строки исходного кода, инвариантами циклов и условиями выхода из тех же циклов. Это очень сильно упрощает формальные методы анализа, за которые топил Дейкстра, и которые при желании можно показать семиклассникам (собственно, «через Дейкстру» они в школьную программу и попали). Применение же goto делает такой простой анализ практически невозможным, описать состояние программы, написанной с использованием goto, получится лишь перебором всех возможных путей выполнения. Если подумать — то всевозможные break, continue, обработка исключений, наконец, точно так же усложняют рассуждения о выполнении программы. Попробуйте написать инвариант несложного цикла, в котором может быть выкинуто исключение! А если это исключение еще и обрабатывается «на уровень выше»?
Но люди думать не хотят, люди хотят пользоваться своими заблуждениями, при необходимости подкрепляя их ссылками на «научную» литературу, которой даже толком не читали. Примерно о том же — и книга Leprechauns of Software Engineering, посвященная разбору популярных — настолько популярных, что их массово тиражируют даже в учебных курсах — утверждений о процессе разработки ПО, которые по факту оказываются либо слабо обоснованными, либо вообще «о противоположном». Сколько раз вы слышали, скажем, о «методологии водопада»? А ведь это такое удобное чучелко для битья, когда рассказывают про всякий Agile! Но если полезть копаться в литературе — то окажется, что «водопад» — в том виде, в каком он был описан впервые, в статье 1970 года — это совсем не то, что вы себе представляете.
Автор докапывается до происхождения мифов о «10x-программисте», о «конусе неопределенности», о «стоимости изменений» на этапах разработки и тестирования — и всякий раз оказывается, что фундамент у этих известных вещей крайне шаткий, местами в первоисточниках написано вообще что-то в духе «а эту картинку мы нарисовали, потому что нам так кажется». Дальше красивая, но не обязательно верная, концепция обрастает несколькими цитированиями — и вперед, она уже тиражируется на правах общеизвестной истины.
В общем, крайне полезное чтение, чтобы курощать программистов и их погонщиков, рекомендую.