Дональд Кнут: У создателей компьютеров кончились идеи

Обучение - Современная наука

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

Эндрю Бинсток: Вы являетесь одним из отцов революции 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 в этом году!