Дональд Кнут доверят только Linux и использует FVWM

"Я использую сейчас Ubuntu Linux на отдельном лаптопе - у него нет подключения к Интернету. Я время от времени перетаскиваю файлы на флешках с этого даптопа на "Маки", которые использую для веб-серфинга и работы с графикой; но мои "фамильные бриллианты" я доверяю только "Линуксу". Кстати, с "Линуксом" я предпочитаю классический оконный менеджер FVWM, а не модные среды GNOME and KDE, которые нравятся другим."

Автор "Искусства программирования", известный математик Дональд Кнут в беседе с аналитиком Эндрю Бинстоком рассказывает о новых томах своей популярной книги, а также о преимуществах "открытого кода", о проблемах разработчиков с многоядерными компьютерами и о разнице между "грамотным" и "экстремальным" программированием.

Эндрю Бинсток: Вы являетесь одним из отцов революции open-source, хотя широкая общественность не знает об этом. Но именно вы в свое время заявили, что выпустили TeX с открытым кодом из-за проблем, которые создают проприетарные приложения, а также для того, чтобы код могли модифицировать другие люди. Оба этих положения сейчас являются ключевыми идеями проектов с открытым кодом. Насколько вас впечатляют нынешние успехи данной идеологии?

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

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

Тем не менее, я думаю, что некоторые программы, такие как Adobe Photoshop, всегда будут побеждать конкурентов типа Gimp - и точной причины этого я даже не знаю! Но я действительно готов платить хорошие деньги за хороший софт, если я уверен, что его сделали лучшие программисты.

Помните, однако, что мое мнение по экономическим вопросам очень сомнительно, потому что я всего лишь ученый и преподаватель. Я почти ничего не понимаю в рынке.

Э.Б.: Говорят, вы однажды участвовали в программерском конкурсе в Стенфорде, и ваша победившая программа работала корректно после одной-единственной компиляции. Это правда? Я к тому, что современные разработчики часто создают программы, дописывая небольшие расширения к коду, затем тут же их компилируют и тестируют "частями" (unit tests). Что вы думаете о подобном подходе к разработке?

Д.К.: История, которую вы упомянули - типичная легенда, и правды в ней мало. Вот что было на самом деле: Джон Маккарти в 1971 году решил провести конкурс Memorial Day Programming Race. Все участники конкурса, кроме меня, работали в AI Lab на холмах близ Стенфорда, используя систему разделения машинного времени WAITS. Я же находился внизу, в главном кампусе, и мне был доступен только один общий компьютер, в который надо было вставлять карточки и ждать своего процессорного времени для их обработки в общем потоке. Я писал на виртовском языке ALGOL W (предшественник "Паскаля"). Моя программа не сработала с первого раза, однако я использовал офлайновый дебаггер Эда Саттерсвейта для этого языка, так что мне понадобилось всего два прогона. В то же время ребята, которые использовали систему WAITS, не смогли получить достаточного машинного времени, потому что их машина была перегружена. Человек, занявший второе место, который использовал этот "современный" подход, пришел с результатом примерно через час после того, как я сдал свою работающую программу, отлаженную "стариковским" методом. Короче, это был нечестный конкурс.

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

Э.Б.: Одна из новых проблем для разработчиков, особеннно разработчиков клиентских приложений - необходимость изменить свое мышление для того, чтобы писать программы в терминах потоков (threads). Эта концепция, появившаяся вместе с недорогими многоядерными компьютерами, очевидно потребует переработки многих алгоритмов под многопоточный режим работы. Между тем, в 4-м томе вашего "Искусства программирования" эта проблема, кажется, не рассматривается всерьез. Собираетесь ли вы в будущем отдельно заняться темой многопоточных и параллельных вычислений в новых книгах - особенно с учетом того, что это хорошо сочеталось бы с комбинаторными темами, над которыми вы в последнее время работаете?

Д.К.: Сфера комбинаторных алгоритмов настолько глубока, что я буду счастлив, если удасться уложить в три-четыре тома хотя бы то, что касается методов последовательных вычислений. И я не думаю, что последовательные алгоритмы когда-либо станут "несущественными".

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

Э.Б.: Между тем, производители многоядерных машин сейчас расстраиваются по поводу того, как трудно привлечь разработчиков к этим машинам. Как бывший университетский профессор, что вы думаете об этом? Может, проблема в инструментах - например, необходима более естественная поддержка одновременных вычислений в языках программирования? Или проблема в самих вычислительных архитекрутах? Или какие-то другие решения возможны?

Д.К.: Мне придется несколько уклониться от прямого ответа, и побурчать о моих личных сомнениях по поводу нынешнего тренда в сторону мультипроцессорных архитектур. Мне кажется, у создателей "железа" кончились идеи, и они пытаются свалить на программистов всю вину за грядущий облом Закона Мура. Они дают нам машины, которые работают быстро - но лишь по немногим ключевым показателям! Я не удивлюсь, если вся идея многопоточных вычислений окажется лажей. И это будет даже более серьезное фиаско, чем хваленый подход Itanium - который обещал работать просто удивительно, но потом оказалось, что для него невозможно написать желаемых компиляторов.

Давайте я так скажу: за прошедние 50 лет я написал более тысячи программ, и большинство из них довольно серьезного размера. Но при этом я не могу назвать даже пять из этих программ, исполнение которых значительно улучшилось благодаря параллелизму или многопоточной обработке. К примеру, многопроцессорность совершенно не улучшает работу редактора TeX.

Много ли вы знаете программистов, которые с энтузиазмом относятся к этим обещанным машинам будущего? Кроме печали, я ничего не слышу на эту тему от специалистов по софту - хотя "железячники" говорят, что я неправ.

Я знаю, что параллельные вычисления важны для рендеринга графики, взлома кодов, сканирования изображений, моделирования физических и биологических процессов, и так делее. Но все эти приложения требуют специально заточенного кода и специфических алгоритмов, которые необходимо менять каждые несколько лет. Если бы я знал достаточно о таких методах, чтобы написать о них в "Искусстве программирования", мое время все равно было бы потрачено напрасно, поскольку вскоре читать эти главы было бы уже бесполезно. Аналогичным образом, когда я готовил третье издание третьего тома, я выбросил большую часть материала о сортировках на магнитных лентах. Эта тема когда-то была одной из самых горячих в программировании, но теперь эта часть книги - бесполезный перевод бумаги.

В компьютере, который я использую сейчас, два процессора. Я использую оба, когда делаю две независимые работы в одно и то же время. Это замечательно, но это занимает всего несколько минут в неделю. Если бы у меня было четыре процессора, или восемь, или больше, я все равно бы не мог работать лучше - с учетом, конечно, специфики моей работы - хотя я почти ежедневно использую компьютер в течение целого дня. Так какая мне радость о того параллельного будущего, которое обещают производители железа? Они думают, какая-то волшебная пуля заставит все эти мультипроцессоры ускорить мою работу; я же думаю, что это вылет в трубу... хотя нет, это плохая метафора! "Трубопроводы" (pipelines) прекрасно работают на меня, а вот "потоки" (threads) не работают. Наверное, лучше сказать "пузырь".

С другой стороны, я признаю, что веб-браузинг может стать лучше с мульти-ядрами. Я, однако, говорю здесь о моей работе, а не о развлечениях. Я также должен признать, что у меня нет особо гениальных идей насчет того, чего бы я хотел от создателей "железа" вместо многопроцессорности - чтобы они бросились долбить стену с уважением к последовательным вычислениям. Хотя в моем дизайне компьютера MMIX имеется ряд идей, способных существенно улучшить исполнение программ, которые меня больше всего интересуют - ценой за это является несовместимость со старыми программами для x86-машин.

Э.Б.: Один из ваших проектов, который пока не привлек широкого внимания - это "грамотное программирование" (literate programming - по смыслу точнее было бы перевести как "литературное программирование", но мы оставим буквальный перевод, который встречается чаще - прим. Вебпланеты). Как вы думаете, почему этот проект "не зажигает"? И если оглянуться назад - может быть, стоило сделать это как-то иначе?

Д.К.: Грамотное программирование - это очень персональная вещь. Я люблю этот проект - но возможно, это потому, что я очень странный человек. У проекта тысячи фанатов, но не миллионы.

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

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

Что до меня самого, грамотное программирование определенно является самой важной вещью, которая вышла из моего проекта TeX. Это не только помогло мне писать программы быстрее и надежнее, но и оказалось одним из главных источников удовольствия с 80-х годов. Некоторые из моих главных программ, такие как мета-симулятор для MMIX, просто не могли быть написаны с какой-либо другой методологией программирования. Сложность программы была слишком высока для того, чтобы с ней справился мой ограниченный мозг; без грамотного программирования вся затея бы рухнула.

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

Но есть и позитивные новости: я был рад обнаружить, что мои правила для системы грамотного программирования CWEB уже стали стандартом в пре-инсталлируемом софте типа Makefiles.

Э.Б.: Несмотря на то, что редактор TeX написан много лет назад, он до сих пор процветает, в основном как платформа для LaTeX. И хотя код TeX'а был "заморожен" по вашей просьбе - какие вещи вы хотели бы поменять в нем, если бы у вас было время и ресурсы?

Д.К.: Я думаю, изменения в TeX вызвали бы больше вреда, чем пользы. Люди, которым нужны другие фичи, создают свои собственные системы, и я всегда поддерживал такое развитие - только пусть не дают своим программам то же название, что у моей. Я хочу сам отвечать за TeX и Metafont, и за все те вещи, которые с этой моей работой связаны - например, точные размеры символов в шрифтах Computer Modern.

Э.Б.: Еще один редко обсуждаемый вопрос в области разработки софта: как заниматься дизайном программы в совершенно новой области? Вы столкнулись с этим, когда взялись за TeX: никакие объекты цифрового искусства не были тогда доступны в виде открытого кода, и это была совершенно новая область, в которой вы не были экспертом. Как вы занимались дизайном, и как много времени прошло, пока вы смогли почувстовать себя комфортно в работе над этой программой?

Д.К.: Хороший вопрос! Я дал детальный ответ в 10-й главе книги "Грамотное программирование" (Literate Programming), а также в 1-й и 2-й части книги "Цифровая типография" (Digital Typography). Я думаю, все, кому интересна эта тема, с удовольствием прочтут эти материалы.

Э.Б.: Книга про TeX и сама программа показывают, что вы очень заботились об ограничениях памяти - это было серьезной проблемой в то время. Сейчас забота о памяти в основном связана с параметрами кэш-памяти. Очевидно, что использование кэш-дружественных алгоритмов не могло пройти мимо вашего "радара". Планируете ли вы осветить в новой книге роль кэша в разработке алгоритмов?

Д.К.: Уже упомянутый компьютер MMIX является тестовой площадкой для различных кэшей. И поскольку эта программно-настраиваемая машина, мы можем выполнять эксперименты, которые можно будет воспроизвести хоть через сто лет. Конечно, в следущем издании 1-3 томов "Искусства программирования" будет обсуждаться работа базовых алгоритмов с учетом разных параметров кэш-памяти. В 4 томе также есть дюжина упоминаний кэш-памяти и кэш-дружественных техник.

Э.Б.: Какие инструменты вы используете сейчас, когда пишете новые главы "Искусства программирования"? Используете TeX, LaTeX, CWEB? Другие редакторы? И что вы используете сейчас для программирования?

Д.К.: Мой основной стиль работы - сначала все записывать карандашом на бумаге, сидя перед большой мусорной корзиной. Затем я использую Emacs для набора текста, применяя инструкции для TeX. Я использую tex, dvips, и gv, чтобы смотреть результаты. Математические формулы проверяю через Mathematica.

Алгоритмы я кодирую в CWEB, который отлично работает с дебаггером GDB. Иллюстрации делаю в MetaPost (или, в редких случаях, на "Маке" с использованием Adobe Photoshop or Illustrator). У меня есть несколько самодельных инструментов, как например своя программа проверки орфографии для TeX и CWEB внутри Emacs. Я создал собственный шрифт для Emacs, потому что мне очень не нравится, как апостроф и левая открывающая кавычка в ASCII-коде превращаются в независимые символы, которые визуально не соответствуют друг другу. У меня есть также специальные режимы для Emacs, которые помогают классифицировать десятки тысяч статей и заметок в моих файлах, и специальные настройки клавишных комбинаций быстрого вызова, что делает написание книг похожим на игру на органе. Для ввода команд с терминала я предпочитаю эмулятор rxvt вместо xterm. С прошлого декабря я использую программу бэкапа под названием backupfs, которая прекрасно удовлетворяет мою потребность архивировать ежедневное состояние каждого файла.

Согласно текущему состоянию папок в моем компьютере, я в этом году написал 68 программ в CWEB. Около 100 было в 2007-м, 90 в 2006-м, 100 в 2005-м, 90 в 2004-м, и так далее. В CWEB очень удобная система изменения файлов, которая позволяет мне быстро создавать множественные версии и вариации на тему; так, в 2008-м я сделал 73 варианта тех самых 68 программ. Можете теперь понять, насколько важно в моей жизни "грамотное программирование".

Я использую сейчас Ubuntu Linux на отдельном лаптопе - у него нет подключения к Интернету. Я время от времени перетаскиваю файлы на флешках с этого даптопа на "Маки", которые использую для веб-серфинга и работы с графикой; но мои "фамильные бриллианты" я доверяю только "Линуксу". Кстати, с "Линуксом" я предпочитаю классический оконный менеджер FVWM, а не модные среды GNOME and KDE, которые нравятся другим.

Э.Б.: В предисловии к нулевой части 4 тома "Искусства программирования" вы пишете, что этот том будет состоять из трех или более книг. Кажется, вам действительно нравится писать такие книги. Насколько верным является обещание на вашем сайте, что 5-й том увидит свет к 2015 году?

Д.К.: Если вы посмотрите через Wayback Machine на прошлые инкарнации этого сайта, то увидите, что дата 2015 не была постоянной. Вы правы, мне нравится работать над этим материалом, потому что я постоянно натыкаюсь на интересные факты, которые просто нельзя игнорировать - хотя более половины моих заметок все равно не достигают финального варианта книги.

Точное время выхода нового тома сказать невозможно, ведь пока я не погрузился в каждую секцию, я даже не знаю, какие из моих материалов будут фундаментальными, а какие окажутся несущественными или наооборот, слишком продвинутыми. Множество современных книг на эти темы являются попыткой заявить свое академическое преимущество, которое мне мало интересно; сейчас авторы частенько описывают всякие "тайные техники", которые могут победить более простые лишь тогда, когда размер проблемы превышает число протонов во Вселенной. Такие алгоритмы никогда не будут нужны в реальных компьютерных приложениях. Я читаю сотни таких работ, чтобы поглядеть, нет ли там каких-нибудь ноу-хау для программистов - но в большинстве случаев приговор ясен сразу.

Э.Б.: В конце 2006 года у вас диагностировали рак простаты. Как ваше здоровье сейчас?

Д.К.: Точно, рак будет серьезной проблемой. Но у меня хорошие доктора. Сейчас я чувствую себя таким же здоровым, как всегда - со скидкой на то, что мне 70 лет. Слова бегут легко, когда я пишу "Искусство программирования" и программы для этого проекта. Я просыпаюсь по утрам с идеями, которые мне нравятся, и некоторые из этих идей нравятся мне даже потом, когда днем я записываю их на компьютере.

С другой стороны, я легко отдаю себя в руки Господа с уважением к тому, как много я еще смогу сделать перед тем, как рак или сердечный приступ или старость меня доканают. И даже если я скоропостижно скончаюсь завтра, у меня нет причин жаловаться, поскольку моя жизнь была невероятно счастливой. Тем не менее, пока я могу писать на темы программирования, я надеюсь сделать все возможное, чтобы организовать и резюмировать десятки тысяч документов и заметок, которые я собирал с 1962 года.

Э.Б.: Peoples Archive недавно сделал ряд видео-интервью, в которых вы рассказывате о своем прошлом. В ролике под названием "Совет молодым людям" вы советуете им не делать что-то только потому, что это популярно. Как мы все хорошо знаем, в разработке программного обеспечения тоже часто случаются "модные увлечения". Могли бы вы привести пример таких сомнительных идей, которые разработчикам не стоит применять только потому, что они популярны, или потому, что так сейчас делают все?

Д.К.: Хмм... Вопрос противоречивый, потому я обычно советую молодым людям слушать себя больше, чем других - а я сам как раз и есть один из "других". Любая биография человека, которого вы захотите использовать в качестве ролевой модели, покажет вам, что он или она делали множество вещей, противоречащих "здравому смыслу" своего времени.

Однако я не буду уколоняться от этого вопроса, хотя и не люблю обижать чужие чувства - ведь надо понимать, что методология программирования сродни религии. Но даже с учетом того, что нет никаких причин слепо верить мнению программиста и математика вроде меня, я все-таки скажу, что все вещи, которые я слышал о так называемом "экстремальном программировании" (extreme programming), кажутся мне совершенно неправильной дорогой... с одним исключением. Исключение касается работы в команде и чтения кодов друг друга. Эта идея верная, и она даже может затмить все другие ужасные аспекты экстремального программирования, которые меня беспокоят.

Я также должен признать, что у меня есть сильное предубеждение против моды на многоразовое использование одних и тех же кодов (reusable code). Для меня, "пере-редактированный" код гораздо лучше, чем нетронутый "черный ящик" или набор инструментов. Я об этом много могу говорить. Если вы убеждены, что повторно исползуемый код прекрасен, я вряд ли смогу вас разубедить. Но вы никогда не разубедите меня, что такой код не опасен.

Еще одна вещь, о которой вы, возможно, хотели спросить: почему новая книга в серии "Искусство программирования" называется Том 4 Часть 0, а не Том 4 Часть 1? Ответ, который поймут все программисты, состоит в том, что я не был готов начать Том 4 с "самого начала" - точно так же, как инициализация программы не может быть написана до того, как сама программа примет определенную форму. Поэтому я начал в 2005 году со второй части 4 тома, затем пошли третья и четвертая часть (вспомните о "Звездных войнах", которые начались с Эпизода 4).

Это позволило мне собраться с духом для написания первой части книги. Но тогда я понял, что вводные главы должны включать гораздо больше материала, чем вместится в одну книжку. Таким образом, вспомнив предложение Дейкстры о том, что счет должен начинаться с нуля, я решил сначала выпустить Том 4 Часть 0. Ждите также Часть 1 в этом году!