Кодеры за работой. Размышления о ремесле программиста - Сейбел Питер

Сейбел: Как правило, публикуя литературную программу, вы публикуете ее финальную версию. Кроме того, вам часто приписывается авторство фразы «Преждевременная оптимизация — корень всех зол». Но на момент создания финальной версии программы уже нельзя говорить о преждевременности — возможно, некоторые части были оптимизированы весьма эффективно. Но не усложняет ли это чтение кода?

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

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

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

Сейбел: То есть это чаще встречается не в коде, а в тексте?

Кнут: Да, речь о текстовой части. Я не показываю код, который исключил из программы. Хотя мог бы.

Сейбел: Есть ли в CWEB возможность включать код, не являющийся частью приложения? Тогда можно не документировать этот момент, а просто делать комментарий: «Это действительно очень простая версия данной функции».

Кнут: У вас просто есть код, который не используется. Он упоминается в документации с пометкой, что этот код нигде не используется.

Сейбел: То есть на этот фрагмент вы просто нигде не ссылаетесь?

Кнут: Да. Кроме того, у меня есть код, который я могу вызвать из отладчика. Я могу сказать: «Нужно вызвать то-то и то-то с такими-то и такими-то параметрами». Подпрограмма никогда не вызывается непосредственно из самой программы, но она всегда есть в документации. Поэтому я могу остановить выполнение программы посередине, вызвать эту подпрограмму — она осмотрится, как идут дела, как все обстоит на более масштабном уровне.

Сейбел: И точно таким же образом вы можете написать: «Раздел первый — это простейшая реализация данного алгоритма; раздел второй — слегка модифицированная версия первого раздела; раздел третий — вот его мы действительно используем, но вы его никогда не поймете, если не прочтете первые два раздела».

Кнут: Именно. У меня есть несколько программ в Интернете, которые решают головоломку «15». И я использую 3 разные версии. Я говорю: «Прочитайте версию номер один, иначе вы никогда не поймете версию номера два. И прочитайте версию номер два, иначе вы никогда не поймете версию номер три».

Мне приходилось писать самые разные программы. Иногда я работаю над программой, для которой производительность — последнее дело; важно лишь получить ответ. В таком случае я применяю метод грубой силы — тогда мне совсем не нужно думать, поскольку не требуется придумывать никаких тонких решений, и я точно не перемудрю. При таких обстоятельствах ни о какой преждевременной оптимизации не может быть и речи.

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

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

Комбинаторные алгоритмы — это потрясающая вещь, поскольку одна хорошая идея может в десятки раз сократить время работы программы. Но я вовсе без всякого высокомерия отношусь к идеям, с помощью которых можно сэкономить и 20%, если программа выполняется триллион раз. Потому что, сэкономив сотню наносекунд в цикле, который исполняется триллион раз, думаю, вы экономите целый день. Если код будет использоваться действительно часто, то будет совсем не лишним придумывать различные тонкие ходы, которые не так-то легко сразу понять.

Около года назад я прочитал обзор в журнале «Computing Reviews» — рецензент писал о книге под названием «Programming Tricks» (Уловки в программировании) или что-то вроде того. Суть рецензии сводилась к следующему: «Если бы я узнал, что кто-то из программистов, работающих на меня, применяет эти штучки, я бы их уволил». Естественно, я начал искать эту книгу, подумав: «Именно такая книга мне и нужна — в ней я могу узнать для себя много нового». К сожалению, уловки не были такими уж хорошими.

Сейбел: Они что, действительно причиняли вред?

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

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

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

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

Люди же, наоборот, все засовывают в упаковку, которую не открыть, и преподносят эту закрытую упаковку программистам, и всем программистам во всем мире не разрешается вскрывать эту упаковку. Они только и могут что соединять одно с другим. И поэтому приходится помнить, что, вызывая вот эту подпрограмму, нужно ввести х0, у0, х1, у1, а при вызове другой подпрограммы нужно ввести х0, х1, у0, у1. Все выполняется строго по инструкции — и это ваша работа.