Оригинал: Interview with Donald Knuth, by Donald E. Knuth, Andrew Binstock ( 14.05.2008 )
Эндрю Бинсток (Andrew Binstock) и Дональд Кнут (Donald Knuth) беседуют об успехе open source, о проблеме многоядерной архитектуры, о печальном отсутствии интереса к «грамотному программированию» (literate programming), об опасности повторно используемого кода, а также обсуждают легенду о победе в соревновании программистов за счет единственной компиляции.
Эндрю Бинсток: Вы являетесь одним из отцов революции open-source, хотя об этом не слишком часто говорят. Раньше Вы утверждали, что выпустили TeX как продукт с открытыми кодами из-за имевшейся в то время проблемы с проприетарными реализациями и с целью привлечения других разработчиков к совершенствованию программы. Оба эти фактора лежат в основе сегодняшних проектов категории open-source. Удивляют ли Вас успехи движения open-source, достигнутые с того времени?
Дональд Кнут: Успех программ с открытыми текстами – это, вероятно, единственное явление в компьютерной области, которому я в последние несколько десятилетий не удивляюсь. Но это движение еще не реализовало весь свой потенциал; я полагаю, что программы с открытыми текстами будут становиться полностью доминирующими по мере того, как экономика будет все больше полагаться не на продукты, а на услуги, и будет появляться все больше добровольцев, желающих совершенствовать программы. Например, из программ с открытыми текстами могут производиться тысячи исполняемых файлов, идеально настроенных на конфигурации отдельных пользователей, в то время как коммерческие программы обычно существуют всего в нескольких версиях. Универсальные исполняемые файлы должны включать, например, неэффективные инструкции sync, совершенно неуместные на многих инсталляциях; эти издержки исчезают, если исходный текст является хорошо конфигурируемым. Это должно стать громадным преимуществом open source.
Тем не менее, я думаю, что небольшая часть программ, таких как Adobe Photoshop, будет всегда превосходить конкурентов из категории open source, таких как Gimp, по неизвестной мне причине. Я на самом деле готов платить хорошие деньги за действительно хорошие программы, если я уверен, что их делали самые лучшие программисты.
Однако не забывайте, что я всего лишь преподаватель и ученый, и мои экономические воззрения в высшей степени сомнительны. Я почти ничего не понимаю в рынке.
Эндрю: Предание гласит, что Вы однажды явились на соревнование программистов в Стэнфорде и стали его победителем, представив программу, которая правильно заработала после первой компиляции. Это правдивая история? Ведь сегодняшние разработчики часто производят программы путем добавления небольших кусочков кода, и после каждого изменения компилируют и прогоняют юнит-тесты. Что вы думаете об этом подходе к разработке?
Дональд: Это типичная легенда, основанная всего лишь на зернышке истинных фактов. В действительности, дело было так: Джон Маккарти в 1971-м году решил провести состязания на скорость программирования в честь Дня Памяти (Memorial Day Programming Race). Все участники соревнования, кроме меня, работали в его лаборатории искусственного интеллекта, которая располагалась на холмах выше Стэнфорда, и использовали систему разделения времени WAITS. Я сидел внизу, на основной территории университета, и единственным доступным для меня компьютером был мейнфрейм, для которого я должен был пробивать перфокарты и отдавать их на обработку в пакетном режиме. Я пользовался системой Вирта ALGOL W (предшественником Pascal). Моя программа не заработала с первого раза, но, к счастью, я смог воспользоваться замечательной оффлайновой системой отладки Эдда Саттертвейта (Ed Satterthwaite), так что мне понадобилось всего два захода. Тем временем, ребята, пользовавшиеся WAITS, не смогли получить достаточного машинного времени, поскольку их машина была перегружена. (Я думаю, что программист, занявший второе место, который использовал этот «современный» подход, пришел к финишу почти через час после того, как я представил работающую программу, полученную с применением старомодных методов.) Это соревнование не было справедливым.
Что касается Вашего основного вопроса, то к идее немедленной компиляции и «юнит-тестирования» я прибегаю крайне редко, когда на ощупь пробираюсь сквозь полностью неизвестную мне среду и нуждаюсь в информации о том, что работает, а что – нет. В противном случае тратится куча времени на действия, в которых я просто не нуждаюсь, и о которых даже не думаю. Нет нужды в «импровизации».
Эндрю: Одной из новых проблем для разработчиков, в особенности для разработчиков клиентских частей программных систем, является потребность изменения своего образа мышления для возможности программирования в терминах потоков команд (thread). Для решения этой проблемы, вызываемой появлением недорогих многоядерных ПК, конечно, потребуется переделка многих алгоритмов в многопотоковые или, по крайней мере, в безопасные в многопотоковой среде. Пока большая часть материала, который Вы публикуете в четвертом томе «Искусства программирования» (The Art of Computer Programming, TAOCP), как кажется, не затрагивает этого измерения. Предполагаете ли Вы включить в свои будущие публикации материал, связанный с проблемой параллелизма и параллельного программирования, в особенности, если учесть естественную пригодность параллелизма в области комбинаторики, в которой Вы в настоящее время работаете?
Дональд: Область комбинаторных алгоритмов настолько огромна, что я был бы счастлив, сумев описать ее последовательные аспекты в трех или четырех физических томах, и я не думаю, что последовательные методы когда-нибудь станут несущественными. И наоборот, параллельные методы быстро устаревают, поскольку аппаратные средства быстро меняются, и для каждой новой машины требуется несколько иной подход. Так что я давно решил придерживаться того, что я лучше всего знаю. Другие люди понимают параллельные машины намного лучше меня; по поводу параллелизма нужно слушать их, а не меня.
Эндрю: Поставщики многоядерных процессоров выражают разочарование по поводу трудностей при переходе разработчиков к этой модели. Как почетный профессор, что Вы думаете относительно этого перехода и возможности его осуществления? Состоит ли проблема в отсутствии должных инструментов, таких как лучшие средства поддержки параллелизма в языках, или в инфраструктуре исполнения? Или имеются другие решения?
Дональд: Я не хочу полностью уклоняться от ответа на Ваш вопрос. Я хотел бы немного сказать о своей личной неудовлетворенности имеющейся тенденцией к переходу к многоядерной архитектуре. Мне кажется более или менее правдоподобным, что у разработчиков аппаратуры исчерпались идеи, и они пытаются переложить вину за будущее прекращение действия закона Мура на разработчиков программного обеспечения, предоставляя нам машины, которые работают быстрее только на нескольких ключевых тестах производительности! Я не буду удивлен, если вся идея многопотоковости потерпит провал еще больший, чем провал подхода Itanium, который считался совершенно замечательным, пока не оказалось, что практически невозможно написать требуемые компиляторы.
Я хотел бы также сказать, что за последние 50 лет я написал более тысячи программ, многие из которых были значительного размера. Не думаю, что хотя бы пять программ из числа написанных мной существенно выиграли бы за счет параллелизма или многопотоковости. Например, вне всякого сомнения, дополнительные процессоры бесполезны для TeX.*
Сколько Вы знаете программистов, проявляющих энтузиазм по поводу этих обещанных будущих машин? Я не слышу от программистов почти ничего, кроме слов горечи и печали, хотя специалисты в области аппаратуры с нашего факультета уверяют меня, что я не прав.
Я знаю, что существуют важные приложения параллелизма: рендеринг графики, взлом кодов, сканирование изображений, моделирование физических и биологических процессов и т.д. Но для всех этих приложений требуется специальный код и специализированные методы, требующие существенного изменения каждые несколько лет.
Даже если бы я знал об этих методах достаточно много, чтобы написать о них в TAOCP, мое время было бы в значительной степени потеряно, поскольку вскоре эти части было бы почти бессмысленно читать. (Аналогично, при подготовке третьего издания третьего тома (Volume 3) я планирую исключить из него большую часть материала, посвященного сортировке с использованием магнитных лент. В свое время эта тема была одной из наиболее важных во всей области разработки ПО, но теперь ее сохранение в книге приведет лишь к лишнему расходу бумаги.)
В машине, которой я пользуюсь сегодня, два процессора. Я использую их оба только в тех случаях, когда одновременно запускаю два независимых задания. Это хорошо, но случается всего лишь в течение нескольких минут в неделю. Если бы у меня было четыре, восемь или еще больше процессоров, то при той работе, которую я делаю, мне не стало бы сколько-нибудь лучше – хотя я пользуюсь своим компьютером почти ежедневно в течение большей части дня. Так отчего же мне быть счастливым по поводу будущего, которое обещают поставщики аппаратуры? Они думают, что появится чудодейственное средство, которое позволит многоядерным процессорам ускорить мою работу; я считаю, что это несбыточная мечта (pipe dream). (Нет, эта метафора неверна! Конвейеры (pipeline) действительно на меня работают, а потоки управления – нет. Может быть, более правильной метафорой является «мыльный пузырь» (bubble)).
С другой стороны, я действительно допускаю, что для просмотра WWW многоядерные архитектуры пригодятся. Однако я говорю о своей технической работе, а не о развлечениях. Признаюсь также, что у меня нет каких-либо интересных идей насчет того, что бы я хотел получить от разработчиков аппаратуры вместо многоядерных процессоров сейчас, когда они начинают достигать предела своих возможностей по отношению к последовательным вычислениям. (Но в моей разработке MMIX содержатся несколько идей, которые могли бы существенно повысить производительность программ, интересующих меня больше всего, – за счет отказа от совместимости с унаследованными программами для x86.)
Эндрю: Одним из нескольких Ваших проектов, не принятых широким сообществом, является «грамотное программирование» (literate programming). Как Вы думаете, почему грамотное программирование не прижилось? Если можно было бы вернуться назад, сделали ли Вы что-нибудь в этой области по-другому?
Дональд: Грамотное программирование – это очень личная вещь. Мне оно кажется бесподобным, но это, может быть, потому, что я очень странный человек. У этого подхода имеются десятки тысяч поклонников, но не миллионы.
Мой опыт показывает, что программное обеспечение, созданное на основе грамотного программирования, оказывается существенно лучше, чем разработанное с применением более традиционных методов. Тем не менее, обычное программное обеспечение, как правило, оказывается неплохого качества – я поставил бы ему оценку C (или, может быть, C++), но не F; следовательно, традиционные методы остаются с нами. Поскольку эти методы усвоены огромным сообществом программистов, у большинства людей нет большого стимула к их изменению, равно как у меня нет мотивации для изучения эсперанто, хотя этот язык мог бы быть предпочтительнее английского, немецкого, французского или русского языков (если бы все на него перешли).
Вероятно, правильно сказал Джон Бентли (Jon Bentley), когда его однажды спросили, почему грамотное программирование не овладело стремительно всем миром. Он заметил, что хорошо программировать умеет небольшая часть населения земного шара, а хорошо писать на естественном языке – другая небольшая часть. По-видимому, мне хотелось, чтобы каждый человек входил и в ту, в и другую группу.
Тем не менее, лично для меня грамотное программирование – это наиболее важная вещь, вышедшая из проекта TeX. Этот подход не только позволил мне писать и поддерживать программы быстрее и надежнее, чем когда бы то ни было раньше, и он не только был для меня самым большим источником удовольствия, начиная с 1980-х гг. – он иногда оказывался незаменимым. Некоторые из моих основных программ, такие как метасимулятор MMIX, не могли бы быть написаны с применением любой другой методологии, о которой я когда-либо слышал. Сложность была просто чересчур устрашающей, чтобы с ней можно было справиться на основе моих ограниченных умственных возможностей; без применения грамотного программирования все предприятие потерпело бы полную неудачу.
Если люди действительно обнаружат хорошие способы использования новомодных многоядерных машин, то я думаю, что это сделают те люди, которые повседневно используют грамотное программирование. Литеральное программирование – это то, что требуется для превышения обычного уровня достижений. Но я не считаю разумным навязывание идей кому бы то ни было. Если грамотное программирование – это не ваш стиль, забудьте о нем и делайте то, что вам нравится. Если этот подход не будет нравиться никому, кроме меня, пусть он умрет.
В качестве положительного явления, мне было приятно обнаружить, что соглашения CWEB стандартным образом используются в предустановленном программном обеспечении типового дистрибутива Linux, таком как Makefiles.
Эндрю: В отдельном выпуске тома 1 (Fascicle 1 of Volume 1) Вы заново описали компьютер MMIX, являющийся 64-разрядной модификацией почтенной машины MIX, с которой в течение многих лет знакомятся студенты из области компьютерной науки. Ранее Вы очень подробно описали MMIX в MMIXware. Я читал части обеих книг, но не могу сказать, имеются ли в отдельном выпуске какие-нибудь модификации материала, вошедшего в MMIXware, или же это в чистом виде конспект этого материала. Не могли бы Вы прояснить этот вопрос?
Дональд: Отдельный выпуск тома 1 – это введение для программистов, включающее полезные упражнения и тому подобные вещи. Книга про MMIXware – это подробное справочное руководство, несколько сжатое и сухое, плюс набор грамотных программ–прототипов. В обеих книгах обсуждается один и тот же компьютер (с учетом исправления опечаток, обнаруженных в печатном издании MMIXware, список которых поддерживается на моем Web-сайте). Для большинства читателей TAOCP первый отдельный выпуск содержит всю информацию про MMIX, которая им понадобится, или которую им захочется знать.
Однако мне следует заметить, что MMIX – это не одна машина; это некоторая архитектура с почти неограниченным количеством вариантов реализации, зависящих от конкретного выбора функциональных устройств, конфигурации конвейера, подхода к упреждающему выполнению команд, способа предсказания условных переходов, размера кэша, стратегии замещения кэша, скорости шины и т.д. В «удешевленных» вариантах аппаратуры некоторые команды и/или регистры могут эмулироваться программным образом. И т.д. Это тестовый стенд, все симулируется с применением моего метасимулятора, хотя развитые версии можно будет эффективно построить только лет через пять (и тогда мы можем захотеть дальнейших усовершенствований всего лишь за счет дальнейшего развития спецификаций метасимулятора до следующей отметки).
Предположим, вы хотите знать, позволит ли наличие пяти отдельных устройств умножения и/или возможности одновременной обработки трех команд ускорить выполнение заданной MMIX-программы. Или, может быть, стоило бы увеличить или уменьшить кэш команд и/или данных, или сделать его более ассоциативным. Всего лишь запустите метасимулятор и посмотрите, что произойдет.
Эндрю: Я полагаю, что Вы не используете компонентное тестирование при работе с MMIXAL. Не могли бы Вы объяснить мне, как Вы убеждаетесь в том, что Ваш код работает правильно при наличии различных условий и входных данных? Если у Вас имеется какой-либо установленный порядок верификации, то не могли бы Вы описать его?
Дональд: Большинство примеров кода на машинном языке в TAOCP содержится в томах 1-3; к тому моменту, когда мы подошли к тому 4, такие низкоуровневые детали, в основном, являются излишними, и мы можем безопасно работать на более высоком уровне абстракции. Поэтому при подготовке вступительных частей тома 4 мне нужно написать всего около десятка MMIX-программ, и это почти совсем игрушечные программы – ничего существенного. Для подобных небольших программ я использую всего лишь неформальные методы верификации, основанные на теории, которую я описал в уже доступной в Сети книге вместе с ассемблером MMIXAL и симулятором MMIX (и полностью описал в книге про MMIXware).
Этот симулятор включает средства отладки, подобные тем, которые я нашел настолько полезными в упоминавшейся ранее системе Эдда Саттертвейта для ALGOL W. Я всегда чувствую себя достаточно уверенно после проверки программы с использованием этих инструментальных средств.
Эндрю: Несмотря на то, что система TeX была разработана много лет тому назад, она все еще процветает, прежде всего, как основа LaTeX. Хотя система TeX была по Вашему желанию, по сути, заморожена, имеются ли какие-нибудь характеристики, которые Вам хотелось бы в ней изменить или в нее привнести, если бы у Вас было на это время? Если да, то какие основные элементы Вы бы добавили или изменили?
Дональд: Я полагаю, что изменения в TeX принесли бы намного больше вреда, чем пользы. Другие люди, желающие наличия других возможностей, создают свои собственные системы, и я всегда поощрял дополнительные разработки – за исключением того, чтобы кто-нибудь давал своей программе то же название, которым обладает моя программа. Я хочу нести пожизненную ответственность за TeX и Metafont, а также за все важные детали, влияющие на существующие документы, основанные на моих работах — например, точные размеры символов в шрифтах семейства Computer Modern.
Эндрю: Один из мало обсуждавшихся аспектов разработки программного обеспечения состоит в том, как следует разрабатывать программное обеспечение в совершенно новой прикладной области. Вы столкнулись с этой проблемой, когда взялись за TeX: Вам не был доступен исходный текст каких-либо предыдущих разработок, и Вы не являлись экспертом в этой предметной области. С чего Вы начали разработку, и сколько прошло времени, прежде чем Вам стало удобно приступить к кодированию?
Дональд: Еще один хороший вопрос! Подробный ответ на него содержится в главе 10 моей книги «Грамотное программирование» (Literate Programming), а также в главах 1 и 2 моей книги «Цифровая типография» (Digital Typography). Я думаю, что любой человек, который действительно интересуется этой тематикой, получит удовольствие от чтения этих глав. (См. также главы 24 и 25 «Цифровой типографии», в которых полностью приведены первый и второй варианты моей исходной разработки TeX в 1977 г.)
Эндрю: Книги про TeX и сама программа демонстрируют явную заботу об ограничении использования памяти – важная проблема для систем того времени. Сегодня беспокойство по поводу использования памяти в программах в большей степени связано с размерами кэшей. Поскольку Вы разработали процессор в программном исполнении, мимо Вас не могли пройти проблемы алгоритмов, в которых учитываются конкретные характеристики кэша (cache-aware algorithms), и алгоритмов, в которых такие характеристики считаются неизвестными (cache-oblivious algorithms). Собираетесь ли Вы затронуть в своей будущей работе, хотя бы косвенно, вопрос о влиянии кэшей процессоров на разработку алгоритмов?
Дональд: Ранее я упоминал, что MMIX предоставляет испытательный стенд для многих разновидностей кэша. И это машина, реализованная программным образом, так что мы можем производить эксперименты, которые можно будет воспроизвести даже через сотню лет. Безусловно, в следующих редакциях томов 1-3 будет обсуждаться поведение разнообразных базовых алгоритмов при различных параметрах кэшей.
В томе 4 пока насчитывается около дюжины ссылок на кэш-память и на подходы, в которых учитывается наличие кэша (не считая «мемо-кэша» (memo cache), представляющего другую, но близкую по смыслу идею в области программного обеспечения).
Эндрю: Какой набор инструментальных средств Вы используете сегодня для написания TAOCP? Вы пользуетесь TeX? LaTeX? CWEB? Word? И чем вы пользуетесь для написания программ?
Дональд: Мой обычный стиль работы состоит в том, что сначала я все пишу карандашом на бумаге, сидя неподалеку от большой корзины для мусора. Затем я использую Emacs для ввода в свою машину текста в формате TeX. Для получения и просмотра результатов я применяю tex, dvips и gv, и эти результаты в наши дни появляются на моем экране почти мгновенно. Свою математику я проверяю с помощью системы Mathematica.
Любой обсуждаемый в книге алгоритм я программирую с использованием системы CWEB (чтоб я полностью его понимал), которая отлично работает совместно с отладчиком GDB. Иллюстрации я делаю с использованием MetaPost (или в редких случаях на Mac с применением Adobe Photoshop и Illustrator). У меня имеется несколько самодельных инструментов, таких как мой собственный спел-чекер для TeX и CWEB внутри Emacs. Я разработал собственный растровый шрифт для использования с Emacs, потому что я терпеть не могу то, как символы ASCII «апостроф» и «левая открывающая кавычка» эволюционировали в независимые символы, не соответствующие друг другу визуально. В Emacs у меня имеются специальные режимы, помогающие мне классифицировать все мои десятки тысяч файлов со статьями и заметками, а также специальные «быстрые клавиши», наличие которых превращает писание книги в некоторое подобие игры на органе. Для ввода с терминала я предпочитаю пользоваться rxvt, а не xterm. С прошлого декабря я использую систему резервного копирования файлов backupfs, которая замечательно удовлетворяет мою потребность к архивировании каждодневных изменений каждого файла.
Что касается текущих каталогов в моей машине, в этом году я пока написал 68 разных CWEB-программ. В 2007-м году их было 100, в 2006-м – 90, в 2005-м – 100, в 2004-м – 90 и т.д. Кроме того, в CWEB имеется исключительно удобный механизм «изменения файлов», с помощью которого я быстро создаю несколько версий и вариаций на одну и ту же тему; пока в 2008-м г. я создал 73 вариации этих 68 тем. (Некоторые из вариаций являются совсем короткими, всего несколько байт; другие имеют размер в 5 Кб и больше. Некоторые CWEB-программы имеют значительный размер, как, например, 55-страничный пакет BDD, работу над которым я завершил в январе.) Таким образом, Вы можете видеть, насколько важное место в моей жизни занимает грамотное программирование.
В настоящее время я пользуюсь Ubuntu Linux на автономном лаптопе – у него нет подключения к Internet. Время от времени c помощью «флэшки» я синхронизирую некоторые данные на этой машине и на компьютерах Mac, которые я использую для хождения по Internet и графики, но свои фамильные драгоценности я доверяю только Linux. Кстати, при работе с Linux я гораздо больше предпочитаю использовать фокусировку ввода, обеспечиваемую классическим FVWM, а не средами GNOME и KDE, которые многим людям кажутся удобнее. Каждому свое.
Эндрю: В предисловии к отдельному выпуску 0 тому 4 (Fascicle 0 of Volume 4) TAOCP Вы утверждаете, что том 4 будет непременно состоять из 3-х или большего числа физических томов. Из этого текста отчетливо видно, что Вам действительно нравится писать на эту тему. С учетом этого, на чем основывается Ваша уверенность, выраженная в заметке, которая опубликована на сайте TAOCP, что том 5 увидит свет в 2015-м году?
Дональд: Если Вы посмотрите с помощью Wayback Machine на предыдущие инкарнации этой Web-страницы, то увидите, что число 2015 не является константой.
Конечно, Вы правы в том, что мне нравится писать этот материал, потому что я продолжаю наталкиваться на очаровательные факты, которые просто нельзя не включить в книгу, – хотя больше половины моих заметок не войдут в окончательный вариант текста.
Точно оценить время невозможно, поскольку я не могу сказать, пока глубоко не погружусь в каждый раздел, какая часть материала, имеющегося в моих файлах, является действительно фундаментальной, а что не слишком подходит для моей книги или является чересчур сложным. В массе современных литературных источников демонстрируется академическое желание превзойти других исследователей, не представляющее для меня интереса; сегодняшние авторы часто предлагают заумные методы, которые оказываются лучше известных простых только в тех случаях, когда размер проблемы превосходит число протонов во Вселенной. Такие алгоритмы никогда не могут быть важны при реальном применении компьютеров. Я читал сотни таких статей в поисках самородков, имеющих ценность для программистов, но большинство этих статей не заслуживает внимания.
С точки зрения планирования работы, все, что я сейчас знаю, состоит в том, что когда-нибудь я буду должен систематизировать огромный объем материала, которые я собрал и сохранил за 45 лет. Я выигрываю важное время, работая в пакетном режиме: я не приступаю к глубокому чтению статьи до тех пор, пока у меня не набираются десятки статей на ту же тему. Когда, в конце концов, я оказываюсь готов прочитать все, что накопилось на данную тему, я часто обнаруживаю, что большая часть этого материала мне совершенно не нужна, и мне не требуется его глубокая проработка. С другой стороны, я могу обнаружить, что материал носит фундаментальный характер и заслуживает изучения в течении недель; тогда мне приходится редактировать свой Web-сайт и сдвигать число 2015 в сторону бесконечности.
Эндрю: В конце 2006-го года у Вас был диагностирован рак простаты. В каком состоянии Ваше здоровье сегодня?
Дональд: Естественно, рак — серьезная проблема. У меня отличные врачи. Сейчас я чувствую себя таким же здоровым, как и всегда, с поправкой на то, что мне уже 70 лет. Когда я пишу TAOCP, мои слова текут легко, и я пишу грамотные программы, предшествующие вариантам TAOCP. Я просыпаюсь утром с идеями, которые меня радуют, и некоторые из этих идей нравятся мне и позже, днем, когда я ввожу их в свой компьютер.
С другой стороны, я охотно предаюсь в руки Господа по отношению к тому, сколько я еще смогу сделать, пока меня не атакует рак, сердечное заболевание или старческая немощь. Если мне предстоит неожиданно умереть завтра, у меня нет оснований жаловаться, поскольку моя жизнь была очень счастливой. И наоборот, до тех пор, пока я смогу писать о компьютерной науке, я буду прилагать все силы к классификации и изложению материала десятков тысяч технических статей, которые я собрал и проаннотировал, начиная с 1962 года.
Эндрю: На своем Web-сайте Вы упоминаете, что Peoples Archive недавно произвел серию видеозаписей, на которых Вы размышляете о своем прошлом. На сегменте 93 «Советы молодежи» Вы говорите, что людям не следует что-то делать только потому, что это модно. Все мы слишком хорошо знаем, что разработка программного обеспечения, как и любая другая дисциплина, подвержена влиянию преходящих увлечений. Можете ли Вы привести несколько примеров модных в настоящее время подходов, которые разработчикам не следует применять только по причине их популярности? Не интересно ли Вам указать важные примеры этой внешней стороны разработки программного обеспечения?
Дональд: Этот вопрос является несколько противоречивым, потому что я, главным образом, советую молодежи прислушиваться к себе, а не к другим, а я и есть один из этих других. В биографии любого человека, которому может захотеться подражать, наверняка обнаружится, что она или он совершали много поступков, противоречащих «общепринятой точки зрения» своего времени.
Тем не менее, я не хочу уклоняться от ответа на Ваши вопросы, хотя также не хочу оскорблять лучшие чувства других людей – учитывая, что методология разработки программного обеспечения всегда была сродни религии. С той оговоркой, что нет оснований серьезно учитывать мнение по поводу разработки программного обеспечения, высказываемое специалистом в области компьютерной науки и математиком, позвольте мне сказать, что почти все слышанное мной в связи с термином «экстремальное программирование» (extreme programming) показывает мне ошибочность этого подхода… за одним исключением. Исключением является идея командной работы и чтения кода, написанного другими программистами. Эта идея очень значительна, и ее достоинства могут перевесить все ужасные недостатки экстремального программирования.
Я также должен признаться в своей склонности отрицать моду повторного использования кода. По мне, «повторно редактируемый код» намного лучше неприкосновенного черного ящика, или набора программ. Об этом я мог бы сказать очень много. По-видимому, я не смог бы переманить на свою сторону человека, полностью убежденного в замечательных качествах повторно используемого кода, но и меня никогда не удастся убедить в том, что повторно используемый код обычно не представляет опасности.
Вот еще вопрос, который Вам следовало бы задать: Почему новая книга называется «Том 4, отдельный выпуск 0» (Volume 4 Fascicle 0), а не «Том 4, отдельный выпуск 1»? Ответ состоит в том, что я не был готов начать писать четвертый том TAOCP с его настоящей начальной точки, поскольку, как известно, невозможно написать код инициализации программы, пока сама программа не обретет требуемую форму. Поэтому в 2005-м г. я начал с отдельного выпуска 2 тома 4, за которым последовали отдельные выпуски 3 и 4. (Ведь и «Звездные войны» начались с «Эпизода 4».)
Наконец, я подготовился к написанию начальных частей, но вскоре понял, что во вводные разделы требуется включить намного больше материала, чем вмещается в один отдельный выпуск. Поэтому, вспомнив максиму Дейкстры (Dijkstra) о том, что считать нужно начинать с нуля, я решил начать том 4 с отдельного выпуска 0. Позже в этом году появится отдельный выпуск 1 тома 4.
Эндрю Бинсток является главным аналитиком в Pacific Data Works. Он также исполняет обязанности обозревателя в SD Times и старшего пишущего редактора в журнале InfoWorld. Эндрю ведет собственный блог.
* Мой коллега Кунле Олукотун (Kunle Olukotun) указывает, что если бы использование TeX стало основным узким местом, и владельцы десятка процессоров действительно нуждались бы в очень сильном ускорении подготовки типографского набора, то можно было бы разработать суперпараллельный вариант TeX с использованием «спекуляции» для одновременной обработки нескольких глав. Можно было бы обрабатывать каждую главу в предположении, что в предыдущих главах не делается ничего такого, что могло бы нарушить логику, используемую по умолчанию. Если это предположение не оправдывается, мы можем перейти к обычной последовательной обработке глав. Но в большинстве случаев, когда подготавливается только обычный типографский набор, обработку можно ускорить в 12 раз. Пользователи, которых заботит скорость обработки, могли бы изменить стиль своей работы и использовать TeX дисциплинированным образом.
Еще много полезного и интересного вы сможете найти на наших ресурсах: