Сейбел: Вы упомянули 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. Но тогда она стала моим “боевым крещением” в Лиспе.
Сейбел: Вот интересно - я знаю, что часто авторами самых сложных, запутанных программ становятся люди, способные держать в голове миллионы подробностей. Вы, без сомнения, это можете, но все же стараетесь сделать свой код как можно более простым и ясным.
Козелл: Признаюсь, у меня бывало по-разному. В целом, я стараюсь делать программы простыми. Но это не значит, что отдельные специфические аспекты их функционирования не могут быть сложными. Стремясь к цели, я могу написать очень сложный код, настолько запутанный, что другим его даже трогать не захочется. Но он всегда будет инкапсулирован.
Большая часть плохих программ, из которых я выкидывал неудачные места, переписывая их заново, не были такими. В них не было маленького островка сложности, который можно попытаться понять и исправить, - они были запутанными в целом.
Я выработал пару правил, которые всегда стремлюсь привить людям, особенно недавним выпускникам колледжей, думающим, что они знают о программировании все. Первое заключается в том, что есть совсем немного непреодолимо сложных программ. Если вы смотрите на участок кода и он кажется вам сложным - настолько, что вам даже не понять, для чего он предназначен, - то почти всегда это значит, что вы просто мало над ним думали. И не стоит, засучив рукава, пытаться прямо сейчас его исправить - лучше вернуться на шаг назад и попробовать понять еще раз. Когда вам это удастся, вы увидите, что на самом деле все гораздо проще.
Мы часто применяли это правило на практике. Как-то раз мы работали над одним большим проектом, и чем дальше, тем более запутанным он становился. Тогда мы начали разбираться вместе. Я сказал: “Это кажется слишком сложным”. И тут вдруг выяснилось, что у нас есть блок-схема, изображающая, как все в итоге должно работать. Посмотрев на нее, все были потрясены: мы сразу поняли, как каждый блок должен выполнять свою задачу. Мы не стали утруждаться и расписывать это все на бумаге, и так было понятно, как скоординировать свои усилия и добиться успеха. Я достаточно давно в этой профессии, чтобы понимать: в ней есть сложности. Но их очень немного. И чем напряженнее человек размышляет над проблемой, тем проще она становится, и в конце концов понимаешь, как на самом деле просто запрограммировать ее правильно.
Второе правило состоит в том, что программы должны быть читабельными. Хотя я, каюсь, в молодости писал страницы макросов ТЕСО, но довольно скоро - наверное, когда работал над системой разделения времени для PDP-1, и ее первоначальная сложность начала понемногу сходить на нет, - пришел к убеждению: исходный код программы предназначен для человека, а не для машины. Компьютеру все равно. Мне кажется, очень правильно, что в Perl есть и “если” (if), и “если не” (unless). Потому что если что-то должно быть сделано при невыполнении какого-то условия, по-английски правильнее сказать “unless”, а не “if not”.
Компьютеру нужен двоичный код, а текстовый файл нужен мне. Я брал в свои проекты умных людей, действительно хороших программистов, недавних выпускников, лучших на своем курсе. И давал им, этим молодым специалистам, фронт работ. После этого на планерках они спорили со мной: “Почему вы жалуетесь, что я прописал глобальные переменные здесь, что я делаю то-то и то-то, что вам не нравится моя структура подпрограмм? Программа же работает?”
Их удивлению не было предела, когда я отвечал: “Конечно, программа работает. Вас взяли сюда именно потому, что вы умеете писать работающие программы. Написание программ - чисто ремесленный навык, и у вас он есть. А теперь вам нужно научиться программировать”. Некоторые из этих ребят, будучи очень хорошими программистами, в жизни не прочли ни строки чужого кода. Фактически некоторые даже свой код не читали и поэтому не понимали, как сильно он потом менялся за какие-то полгода.
Некоторые начинали бунтовать. Они были абсолютно уверены в своих силах, а я для них был просто замшелый старик. Я и сам когда-то удивлялся: если моя программа работает, какие к ней могут быть претензии? Теперь же я сам объяснял другим: “Работающая программа - не оправдание. Это необходимый минимум. Пора переходить на следующий уровень”, - а они только охали в ответ. А потом, поговорив с коллегами, понимали, что в BBN это, по сути, стандарт. Ты не можешь создать что-то новое, не усвоив перед этим основы ремесла.
У меня есть свои предпочтения относительно того, как должны быть организованы мои глобальные переменные и подпрограммы. Как-то раз я ввязался в многодневный спор с одним парнем, который говорил: “Ну посмотрите, все же нормально работает”. Он был действительно хорошим программистом, настолько, что мне не хотелось пользоваться служебным положением. Я хотел, чтобы он сам понял, что я не стараюсь таким образом самоутвердиться, и увидел причину, по которой я хотел, чтобы он программировал так, а не иначе. Он просто не понимал, как трудна для понимания программа, в которой только подпрограмма на Си занимает 42 страницы кода.
Сейбел: Ого!
Козелл: Я спорил с ним, потому что сам решительно предпочитаю простые, вызываемые один раз подпрограммы. Единственная цель такой подпрограммы - абстрагировать одну небольшую часть родительской подпрограммы. По-моему, если родительская подпрограмма шокирует своим объемом и сложностью, это верный признак того, что все нужно переделывать. Допустим, у меня есть маленькая подпрограммка, в которой говорится: “Отсортируй таблицу и найди лучший путь”, и она вызывается всего один раз. Кто-нибудь оптимизирующий код может сказать: “Это не должно быть подпрограммой. Просто добавь ее в код”. Но эту маленькую подпрограммку я могу рассматривать изолированно. Сразу ясно, какие у нее входные данные. Ты видишь алгоритм и можешь быть спокоен, потому, что все понимаешь. Тот парень ненавидел, когда я говорил ему: “Твои подпрограммы слишком сложны. Они занимают много места”. Он в таких случаях отвечал: “Все в порядке, потому что я могу сделать это все в одной подпрограмме”.
Он сопротивлялся, но в конце концов поступал по-моему. Как-то раз ему нужно было взять большой кусок кода, написанный его предшественником, доработать и встроить в новую версию системы. Он
