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

Сейбел: Как часто проводились подобные ревизии? Один раз в самом начале проекта или периодически на протяжении всего срока работы над ним?

Козелл: Многократных ревизий не было. Обычно она проводилась один раз сразу после того, как ты разработал проект.

Сейбел: Получается, нужно было знать, как будет выглядеть результат, еще до того, как начнешь программировать?

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

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

Сейбел: Вы упомянули DOCTOR. Что это за программа?

Козелл: Когда я работал над системой разделения времени для PDP-1, Дэн Мерфи с друзьями тоже работали с PDP-1, заканчивая систему на Лиспе. И я надумал выучить Лисп. Той весной Джо Вейзенбаум написал для журнала “Communications of the ACM” статью о своей программе ELIZA (Элиза). Я подумал, что это круто. И еще я был уверен — и пребываю в этой уверенности до сих пор, - что могу сделать на компьютере все, что сумею понять. Он описал, как работает ELIZA, и я сказал себе: “Спорим, я могу написать такую же”. И начал писать программу на PDP-1, на системе Дэна Мерфи в BBN. Телетайп модели 33 в моем компьютерном зале с PDP-1 был подключен к PDP-1 Дэна Мерфи, так что я мог использовать его компьютер из моего компьютерного зала, будто это была моя система. Я писал эту программу, улучшал ее и одновременно работал. Постепенно втянулась практически вся BBN. Ребята оставляли мне комментарии: “Лучше сделай так-то и так-то” или “Я попробовал это, и оно не работает”. Это помогло развить идею Вейзенбаума так, как он и не помышлял. Первоначально программа была написана на Лиспе для PDP-1. Но ребята уже программировали на Лиспе для PDP-6 или, может, даже PDP-10. Лисп получил широкое распространение через ARPANET. И, видимо, DOCTOR вместе с ним.

Я впервые был согрет лучиком славы, когда Дэнни Боброу написал мне: “A Turing Test Passed” (Тест Тьюринга пройден). Это было чуть ли не впервые, когда меня заметили из-за моих дурацких программ: мне пришлось прекратить работу над DOCTOR. Один из директоров BBN зашел в комнату с PDP-1, подумал, что Дэнни на связи, и начал переписываться с ним. Мы, кто был знаком с программами вроде Элизы, легко распознавали их ответы, не замечая, насколько они похожи на человеческие. Но тем, кто не имел дела с такими программами, их ответы казались вполне разумными. К сожалению, он и в самом деле подумал, что это был Дэнни. “Расскажите мне еще о...” - “Помнится, вы сказали, что хотите пройти в комнату для клиентов”. Подобные фразы казались осмысленными в общем контексте, пока в какой-то момент босс не забыл нажать кнопку и отправить очередное сообщение, так что программа не смогла ответить. И он подумал, что Дэнни отсоединился. И позвонил ему домой, наорав на него. А Дэнни даже не понял, что происходит. Но он знал о моем терминале. Так что Дэнни пришел на работу и вынул распечатку из телетайпа, чтобы сохранить ее.

То была очень продвинутая версия программы Вейзенбаума. Мы немного улучшили скрипты. Многие поколения хакеров работали над этим. Как я уже говорил, программа кочевала по Сети. Думаю, сейчас уже есть ее версия, написанная в макросах Emacs. Но тогда она стала моим “боевым крещением” в Лиспе.

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

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

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

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

Мы часто применяли это правило на практике. Как-то раз мы работали над одним большим проектом, и чем дальше, тем более запутанным он становился. Тогда мы начали разбираться вместе. Я сказал: “Это кажется слишком сложным”. И тут вдруг выяснилось, что у нас есть блок-схема, изображающая, как все в итоге должно работать. Посмотрев на нее, все были потрясены: мы сразу поняли, как каждый блок должен выполнять свою задачу. Мы не стали утруждаться и расписывать это все на бумаге, и так было понятно, как скоординировать свои усилия и добиться успеха. Я достаточно давно в этой профессии, чтобы понимать: в ней есть сложности. Но их очень немного. И чем напряженнее человек размышляет над проблемой, тем проще она становится, и в конце концов понимаешь, как на самом деле просто запрограммировать ее правильно.