В 1969 году, когда первые два узла сети ARPANET — основы будущего Интернета — были введены в строй, каждый пакет данных, передававшийся по арендованным линиям с пропускной способностью 50 Кбит/с, направлялся через два специальных компьютера, носивших название Interface Message Processors (Интерфейсные процессоры сообщений), или IMP. Эти IMP были спроектированы и созданы компанией Bolt Beranek and Newman (BBN), а управлявшие ими программы писали три программиста, одним из которых был Берни Козелл, ушедший с третьего курса Массачусетского технологического института (MIT) ради работы в BBN.

Первоначально нанятый как программист приложений в проекте по созданию одной из первых систем разделения времени, Козелл быстро перешел к программированию самой системы и вскоре стал «царем системы разделения времени PDP-1», ответственным за завершение кода операционной системы и поддержку работы системы.

За свою 26-летнюю карьеру в BBN Козелл занимался практически всем, заслужив в компании репутацию мастера-отладчика и «умельца», который может спасти любой неудачный проект. Он программировал просто для развлечения: чтобы отточить свое мастерство владения Лиспом, он написал DOCTOR — версию знаменитого виртуального собеседника Элиза — по описанию в журнальной статье автора программы Джозефа Вейзенбаума. Написанный на языке BBN-LISP, широко распространившемся по сети ARPANET вместе с операционной системой TENEX, DOCTOR Козелла стал популярнее оригинала Вейзенбаума, вдохновив других программистов на новые версии и похожие программы.

В 1991 году Козелл ушел из BBN и купил овцеводческую ферму в Виргинии, где и проживает сейчас с женой Линн, тремя собаками, бесчисленными котами и большим стадом овец. Он немного программирует для местного интернет-провайдера, занимается собственными проектами и читает несколько курсов по программированию и компьютерной безопасности в высшей школе, не желая больше быть профессиональным программистом. Ирония судьбы в том, что после переезда в сельскую местность Козеллу — одному из отцов современного Интернета — дома сейчас доступно только соединение по телефонной линии.

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

Сейбел: Когда вы начали программировать?

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

Сейбел: В какой школе вы учились?

Козелл: В научной школе Бронкса в Нью-Йорке. Думаю, те, кто учились до нас, работали еще на IBM 650 Колумбийского университета. Но декан математического факультета был чрезвычайно горд, что у них есть собственный компьютер. Он даже написал учебник по программированию, а в то время их было совсем мало. В итоге я отлаживал все примеры его программ. Практически все, что я помню о старших классах, — это то, как я учился программировать.

Сейбел: Как вы тогда программировали? Ассемблер на перфокартах?

Козелл: Да. В основном на перфокартах, но у модели 1620 уже была своя консоль ввода/вывода; ее роль играла электрическая пишущая машинка IBM Selectric. С ее помощью можно было вводить программы. Чтобы вы поняли, что это была за эпоха: в компьютере не было арифметического блока. Для арифметических действий использовалась таблица, хранящаяся в памяти машины. Например, при сложении двух чисел одно из них давало номер ряда, другое — колонки, а результат находился на их пересечении. Частью создания любой программы был ввод в соответствующий раздел памяти таблиц сложения и умножения.

Так что, в принципе, можно было пользоваться пишущей машинкой, но чаще мы набивали перфокарты и загружали их. Для этого был и Фортран, но я его мало использовал и чаще пользовался ассемблером 1620.

Другой полезный навык, который я освоил в старших классах, — подключение оборудования через коммутационную панель. На каком-то этапе у нас появились, кажется, старые печатающие устройства модели 403, и я занимался их подключением. Это было просто, даже тогда, но десять лет спустя, уже во время работы в BBN, этот опыт мне пригодился. Как-то раз нам понадобилось собрать панель и я сказал: «Дайте инструкцию мне». В результате мне удалось подключить по простому протоколу старое печатающее устройство, чтобы оно служило строковым принтером для нашей PDP-1.

Сейбел: Между школой и работой в BBN еще был MIT?

Козелл: В 1963 году я закончил школу и сразу поступил в MIT. Там было сильное математическое направление, включающее довольно бессистемный компьютерный курс. Он все еще был узкой прикладной дисциплиной на факультете электротехники, специализироваться по компьютерам было нельзя. Ребята как раз начали разрабатывать первые системы разделения времени на модели 709 или 7094, или что у них там было в компьютерном центре, а я в то время с головой ушел в математику.

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

По-настоящему я погрузился в это, присоединившись к кружку под названием «Клуб технического моделирования железной дороги». Я решил, что это очень интересно, — релейная логика была моим коньком. У них была модель железной дороги, вся построенная на реле и шаговых переключателях. Через этот клуб я познакомился с людьми из RLE — Исследовательской лаборатории электроники. В те времена мы целыми днями сидели в подвале 26 корпуса и набивали перфокарты, чтобы вечером отдать их «компьютерному шаману», который на следующий день вручал нам стопку распечаток. Потом я вошел в проект MAC. И заметил, что вместо математики все больше времени уделяю компьютерам.

А из RLE открывалась прямая дорога в научно-технологический центр Tech Square. Там я познакомился с такими людьми, как Ричард Гринблатт и Билл Госпер. Тогда я только начинал познавать этот мир и едва ли представлял из себя что-то как программист. Например, в проект MAC я попал, увлекшись компьютерной игрой «Spacewar!». Причем я интересовался ею не как программист: «Дайте взглянуть на исходный код. Как вы это сделали?» На том этапе я был просто геймером. И мне сказали, что ребята из проекта MAC разработали потрясающую версию Spacewar!, что у них крутые консоли и они могут сколько угодно использовать PDP, так что мне немедленно захотелось стать одним из них. Так я познакомился с Питером Сэмсоном в тот момент, когда он пытался (неудачно) решить грандиозную задачу, связанную с метрополитеном Нью-Йорка, — чтобы по одному билету можно было объехать его весь с максимально возможной скоростью.

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

Оглядываясь назад, я могу сказать, что тогда осваивал азы ремесла программиста. Учился добиваться от компьютера нужного мне результата. Но в этом еще не было искры. Я не осознавал, что делаю; фактически я даже не понимал, как это все работает. Что-то вроде волшебства. Вот чем это было для меня в колледже. Настоящим программистом меня сделала работа в BBN.

Один мой университетский знакомый, уже отучившийся и работавший в BBN, сказал мне: «Давай к нам». Помню, я впервые попал туда в полночь, потому что BBN была безумным местом, где работа кипела круглосуточно, семь дней в неделю. Компания была своеобразным продолжением лабораторий MIT. Каждый мог приходить и уходить когда хочет. И мой приятель как раз работал в ночную смену. Вот мы и наведались туда как-то поздно вечером. Все было загадочным и мистическим; я, по-моему, вообще не понимал, что мне показывают. Вскоре мне передали, что меня хотят нанять. Пригласили на интервью и взяли на работу.

Сейбел: Вы тогда были на третьем курсе MIT?

Козелл: Точно. В сентябре меня взяли на полставки. А уже в начале октября я отчислился и устроился в BBN на полный рабочий день. Теперь мне кажется, что я не был так уж хорош. Я видел компьютер PDP-1, но понятия не имел, как на нем программировать. И ничего не знал о том, что такое разделение времени. Впрочем, это неудивительно, потому что об этом тогда знали хорошо если человек пятьдесят во всем мире.

В BBN тогда делали совместный проект с Главным госпиталем Массачусетса по автоматизации работы больниц, и меня взяли в этот проект. Начинал я как программист приложений, поскольку это было все, на что я тогда годился. Проработал в этом качестве недели три. Но вскоре стал системным программистом, писал библиотеки, которые они использовали. И некоторое время спустя два системных гуру, парни, создавшие большую часть системы разделения времени для PDP-1, взяли меня под опеку и подключили к своей работе. Той зимой они оба покинули BBN, чтобы продолжить свое университетское образование. И к январю я был «царем системы разделения времени PDP-1» — отвечал за весь проект целиком.

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

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

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

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

Я решил, что вся система должна быть абсолютно безотказной. Не помню, требовало от меня этого начальство или нет, я сам поставил перед собой такую задачу. Решил, что должен доказать — именно я должен, — что разделение времени может работать. Что это достаточно надежная вещь, чтобы медики могли ей довериться. Я представлял себе ситуацию, когда пациенту срочно нужно лекарство, а система вдруг «упала». Или, что еще хуже, она потеряла рецепт и пациент вообще никогда не получит свое лекарство. А что будет, если все рецепты перепутаются, а ничего не подозревающие врачи поверят электронике? Так что я решил, что система вообще не должна ломаться. Ее нужно было сделать столь же надежной, как UNIX 30 лет спустя.

Но выполнять отладку в реальном времени было невозможно. Когда система «падала», лампочка гасла, и все. Контрольная панель позволяла считывать и записывать содержимое памяти. Но отладить систему можно было, только узнав ответ на вопрос «Что она делала перед отключением?». Нужно было не запускать программу, а просмотреть список выполненных операций. Так что я рылся в памяти машины, просматривая рулоны распечаток. И постепенно учился делать это все лучше и лучше.

Сейчас даже страшно подумать, насколько лучше. В общем, в итоге начальству пришлось выдать мне пейджер. В те времена это был настолько крутой аппарат, что служебные давали только врачам. Громоздкая неудобная штука, которая умела только одно — пищать. Никакого обмена сообщениями. И он работал только в Бостоне и вокруг него, потому что передатчик был установлен на крыше Пруденшл-центр. Но в радиусе 50 миль сигнал был.

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

Сейбел: Наверное, вам приходилось писать значительную часть кода самому.

Козелл: Так и было. Операционная система была еще не готова, когда я принял проект. Когда Стив Вейсс и Боб Морган уволились, чтобы учиться, она была полна багов и просто недописанных кусков. Мне пришлось доделывать работу за них, и одна из главных вещей, которым я научился в BBN, — как заставлять такие программы работать.

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

Так я и заслужил свою репутацию. Я знал, что мой босс и многие коллеги считают меня великим отладчиком. Отчасти это так и было. Но только отчасти.

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

Иногда попадались такие участки кода — обычно как раз те, которые другим ну никак не давались, — на которые я смотрел и говорил: «Тут все слишком запутанно».

Так что я еще раз читал исходную задачу и переписывал код с нуля. Некоторым из моих коллег, потрясающим программистам, например Уиллу Кроутеру, это не нравилось. Они считали, что таким образом можно, исправив в коде 2 ошибки, добавить туда 27 новых. Но у меня все получалось. Я мог полностью переписать программу, иначе организовав ее, чем это сделал автор, потому что имел собственное видение. Обычно так было проще, во всяком случае для меня. И обновленная программа работала.

Вот так я и заработал свою репутацию, исправляя ошибки, которые больше никто не мог исправить. Хорошо, что меня никогда не спрашивали, как я это делал. Потому что честный ответ, как правило, был: «Я недостаточно разобрался в коде, поэтому просто взял и написал новый».

Я много раз делал так с системой разделения времени для PDP-1. Там были фрагменты кода, при взгляде на которые я понимал, что они либо не работают так, как должны, либо вообще написаны «криво». Так что я их переписывал. Если я не вылетел с работы, то только благодаря хорошей репутации. Если ты в таких вещах недостаточно хорош, то результатом твоей работы будет хаос. Но если ты хорош, люди будут думать, что ты умеешь даже больше, чем на самом деле.

Сейбел: Уход из MIT был трудным решением?

Козелл: Нет. Оглядываясь назад, я удивляюсь, насколько просто это вышло. Я ненавидел учебу, она меня бесила. MIT — место, где испытываешь очень сильное давление. BBN после этого была просто землей обетованной. Это было чудесно. Сотрудники играли с компьютерами, обстановка в компании была безмятежной. Это было похоже на проект MAC даже больше, чем сам проект MAC. В те времена человек запросто брал на работу свою собаку. Так что по коридорам все время бегали домашние питомцы. Ну, а их хозяева работали днем и ночью.

Я начал работать на полставки, потому что, когда учился в MIT, у меня практически всегда была работа на полставки. И сразу же почувствовал себя на работе, как дома. Просто сам не мог в это поверить. Наплевав на учебу, я ушел из института и устроился на полную ставку. Поработав в BBN, я успокоился и лучше разобрался в себе. Так что следующей осенью восстановился в институте и вернулся к учебе. Вот как это было.

Сейбел: Как вы думаете, обучение в MIT было хорошим дополнением к вашему практическому опыту?

Козелл: Курсы программирования, которые я посещал, будучи старшекурсником MIT, были полезны для понимания общих принципов, но мало чему научили меня в практическом смысле. Работать я учился под руководством коллег в BBN. Целенаправленно меня учил, пожалуй, только Стив Вейсс. Но я понемногу набирался знаний и умений от всех.

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

Козелл: Мне трудно советовать сегодняшним программистам. На самом деле, я не могу вспомнить ни одного по-настоящему полезного учебника тех времен. Пожалуй, ближе всего было «The Art of Computer Programming» Кнута, которое я когда-то прочитал от корки до корки. Но его едва ли можно рекомендовать как учебный текст.

Сейбел: Вы действительно прочли эту книгу от корки до корки?

Козелл: Это было потрясающе! Я тогда был на первом курсе. Как только выходила очередная часть, мы сразу же прочитывали ее целиком.

Сейбел: Это требует серьезной математической подготовки. Думаете, программистам действительно нужно разбирать Кнута досконально, как вы?

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

Вторая проблема состоит в том, что студент, приобретя такое понимание, становится даже немного слишком умным. Он начинает оптимизировать мелкие детали программ, размышляя примерно так: «Здесь лучше применить несбалансированное двойное реверсивное кубическое преобразование А-В, и я как раз давно хотел это сделать». И так он тратит неделю или две, улучшая те куски, которые в этом не нуждаются, программа становится сложнее, что ей не на пользу. Программисту нужно скорее поверхностное понимание всех этих алгоритмов, принципов их работы и использования. Важнее знать, как выбрать правильный алгоритм и заставить его работать, чем то, что этот — порядка п3 + 3, а тот – 4n2.

Если станет интересно, всегда можно заглянуть в книгу Кнута, но обычно это не требуется. Что действительно нужно изучить студенту, так это структуры данных. Его не должно шокировать, например, создание связных списков в Perl. Если знаешь все основные структуры данных, всегда сможешь выбрать нужную. Не всегда самую быструю. Не всегда самую симпатичную. Но всегда ту, которая лучше всего подходит в данной ситуации, потому что тебе известны все альтернативы. Не говорите Дону, но я продрался через зубодробительные вычисления, которые он использовал, чтобы понизить комбинаторную сложность, и практически не нашел им достойного применения. Зато я всегда отлично ориентировался в структурах — и это приносило результат.

Сейбел: Что посоветуете программистам-самоучкам?

Козелл: Программируйте больше. Когда-то мне это принесло огромную пользу. Вспоминая свою учебу, могу сказать, что ничто так не продвигало меня вперед, как практика. Не программирование от нечего делать, а совсем наоборот. «Я должен разобраться в этом, и если так, то почему бы не написать с помощью этого программу?» — вот как нужно думать и поступать.

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

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

Сейбел: Насколько часто вы сами программировали ради удовольствия, вместо того чтобы целенаправленно осваивать на практике конкретные методы?

Козелл: Я рассматривал программирование в основном как способ делать полезные вещи и старался развивать свои умения именно в этом направлении. Иногда эти вещи были неисправны, и тогда я мог их починить. Как-то я решил, что неплохо бы разобраться в Лиспе, потому что знал настоящих специалистов по этому языку, а для меня он был тогда по большей части загадкой. Так что я написал несколько программ на Лиспе, и это для меня было гораздо естественнее, чем сидеть под крылышком у Дэна Мерфи и ждать, пока он прочтет мне лекции по CONS, CDR и CAR.

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

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

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

Или взять сортировку и поиск. Если в языке программирования нет функции сортировки, они ничего не будут знать о разных методах сортировки, о поиске, о том, когда надо строить индексы, не будут понимать, что значит «наша база данных хранит данные в виде В-дерева». В хорошем курсе обучения, я считаю, нужно не просто объяснить, как, к примеру, создать связный список в Си — это чисто техническая задача, — но и рассказать о принципах работы связных списков вообще.

Сейбел: Среди самых известных проектов, в которых вам приходилось участвовать, был ARPANET. Вы, Уилл Кроутер и Дэйв Уолден писали программное обеспечение к первым компьютерам IMP новой сети. Как вы попали в этот проект?

Козелл: Наш руководитель Фрэнк Харт относился к своему отделу как к своеобразному инкубатору молодых программистов. Он передвигал людей из проекта в проект. Когда один мой проект заканчивался, он решал, куда меня затем направить. Настоящие консультанты начинали свою работу с командировок в Вашингтон и написания техзаданий; я, однако, был далек от этого. Тем не менее Фрэнк решил поставить меня третьим специалистом в проект IMP.

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

Я знал, что к моему приходу они не могли далеко продвинуться, потому что процесс ассемблирования у них не был автоматизирован. Им приходилось нести перфоленту в комнату с Honeywell 516 и прогонять через него всю эту перфоленту, чтобы получить распечатку, набивая для этого целую коробку перфоленты, которую они потом несли к другой машине, потому что к Honeywell не был подключен строковый принтер, чтобы распечатать результат ассемблирования. Программировать так было очень утомительно. Первое, что я сделал в рамках проекта, — написал кросс-ассемблер для нашего PDP-1.

После этого на PDP-1 появилась возможность редактировать файлы, ассемблировать их, распечатывать результат, запускать ТЕСО-макросы и так далее. Единственное, что надо было набивать, — относительно небольшая бинарная исполняемая программа, которая предназначалась для машины Honeywell.

Сейбел: Что было самым трудным в написании программ для IMP — заставить их работать быстрее?

Козелл: Интересный вопрос. Так, давайте посмотрим. Мы не слишком много думали о размере программы — предполагалось, что в системе будет достаточно памяти для буферизации. И что кода будет не так уж много. Если бы он был, скажем, на 10% больше, чем он получился в итоге после максимального сжатия, рабочих буферов памяти стало бы немногим меньше. Поэтому мы не беспокоились о том, сколько инструкций все займет.

Сейбел: То есть какой объем.

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

Второй проблемой было заставить все это работать. В системе было много новых, непроверенных элементов. Мы не знали заранее, будут ли работать протоколы. Уилл предложил несколько новых идей, связанных с алгоритмами маршрутизации, — будут ли они удачными? Таких вопросов было очень много. Например, по поводу отслеживания заторов. Могли ли мы быть уверены, например, в том, что если пользователи всего мира отправят пакеты одному бедолаге, то мы сможем отбрасывать их в правильном порядке, не дав ему утонуть?

Сейбел: С подобными проблемами до вас никто не сталкивался?

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

Третьим большим вызовом была отладка системы, устранение неисправностей. Например, внезапно пропала связь с городом Цинциннати (штат Огайо). Что случилось? Как это исправить? Звонишь в Цинциннати, а тебе отвечает заспанный ночной охранник — там сейчас три часа ночи. Нужно, чтобы он поднялся и посмотрел на ту мигающую коробочку в углу. Что он расскажет? Что с этим делать? Даже если система вновь заработала, как выяснить, что пошло не так? Как избежать этой проблемы в будущем? Не забывайте, что я считался великим-отладчиком-всего-и-вся, мастером-на-все-руки.

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

Была еще одна проблема из разряда неприятных, но не смертельных. Порча памяти из-за неправильного указателя. Сама по себе порча была незначительной, но спустя несколько тысяч машинных циклов программа вылетала, потому что одна из структур данных оказывалась поврежденной. Та поврежденная структура данных использовалась постоянно, поэтому мы не могли просто добавить в код команду «Остановить программу, когда она изменится». Я немного поразмыслил и наконец придумал двух- или трехступенчатую систему заплаток. Как только память портилась, первая заплатка активировала вторую, которая работала с другой частью кода. Это, в свою очередь, активизировало запись третьей заплатки в еще один участок. Наконец, когда эта третья заплатка замечала, что происходит что-то не то, она останавливала систему. Я придумал, как откладывать проверку до нужного момента с помощью такой динамической системы заплаток. К счастью, это сработало, и мы смогли быстро устранить неполадку.

Сейбел: Что наталкивает на подобные удачные идеи?

Козелл: Если я досконально разобрался в системе, будь то ПО для IMP или система разделения времени для PDP-1, несмотря на то, что она мультипрограммная, многослойная и основана на работе с прерываниями, все равно вся ее динамика находится у меня в голове. Я знаю, что и в каком порядке должно происходить и что не должно происходить. Это позволяет всегда представить примерную модель происходящего.

Надо сказать, что многие из возникавших тогда проблем относились к двум разным моделям компьютеров, и их анализ требовал недюжинной фантазии. Например, что-то происходит не так на первой машине, а последствия проявляются на второй. Я не могу остановить работу, первая машина уже обработала на 6000 пакетов больше, чем вторая, и вдруг вторая говорит, что один из пакетов поврежден. Что тогда делать? Всем нам троим приходилось садиться и прослеживать весь процесс в ретроспективе, чтобы найти ошибку и «вылечить» систему.

Сейбел: Был ли в систему встроен отладочный код?

Козелл: Нет.

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

Козелл: Насколько помню, мы не добавляли никакого отладочного кода. Сейчас я не устаю повторять: программу нужно писать так, чтобы она была тестируемой. А для того чтобы она была такой, нужно подумать об этом заранее, еще до того, как напишешь первую строку кода. Когда программа заработала, в нее уже поздно вставлять блокировки, утверждения или тестовые модули.

Но тогда мы даже не думали об этом. Мы просто старались написать эту чрезвычайно сложную систему реального времени так, чтобы она работала быстро. Это само по себе было трудной задачей. Мы не закладывали никаких проверок на непротиворечивость; к чему тратить на это время? Так что все исправления вносились потом бессистемно. Загляни в такой-то раздел памяти, просмотри код, чтобы разобраться с тем, или другим, или третьим, потом вернись и начни сначала.

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

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

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

Сейбел: Это были буквально ряды лампочек?

Козелл: Да, ряды лампочек. Одна лампочка — один бит.

Сейбел: И тумблеры для ввода адресов?

Козелл: Да. Я считаю, это лучше. На PDP-1 были тумблеры. На той машине, о которой мы говорим сейчас, помнится, были кнопки.

Сейбел: Как вам троим работалось вместе?

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

Для меня он был чем-то вроде виртуального противника в компьютерной игре, причем использующего в качестве оружия Фортран. Дело в том, что и алгоритм маршрутизации, и всю динамическую часть сиетемы управления IMP собирал Уилл. Одно из важных условий работы системы реального времени — каждой операции должна быть сопоставлена предельная продолжительность, тайм-аут. Нельзя дожидаться чего-то бесконечно долго, потому что понятия «бесконечно долго» в таких системах просто не существует.

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

И вот я думал: какими базовыми константами пользовался Уилл, собирая все это вместе? Когда два тайм-аута были одинаковыми по длине, было ли это совпадением или то был один и тот же тайм-аут? Кто знает? Сколько нужно внести изменений в код, чтобы изменить одну константу? Если в процессе работы замечаешь, что ждешь чего-то недостаточно долго и операция завершается по тайм-ауту, когда не должна, то понимаешь, что не можешь просто взять и изменить один тайм-аут в программе, потому что там все взаимосвязано.

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

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

Козелл: Не помню, чтобы я там нашел какие-то ошибки. Но, конечно, в нескольких местах временные промежутки пришлось изменить — просто в качестве меры предосторожности, потому что все работало. Это позволило упростить систему. Для меня немыслимо было оставить 200 разбросанных по коду случайных независимых констант, задающих ритм работы сети. Думаю, корректура упростила код, стало проще разобраться в происходящем. Это также позволило нам использовать более осмысленные константы. Диаметр, умноженный на восемь, плюс длительность импульса или что-то такое — гораздо понятнее.

Уилл был чем-то вроде мощного генератора идей. Помнится, я как-то пожаловался Фрэнку Харту, что его все время ставят в новые проекты. Дело было в том, что BBN производила много революционных продуктов, а Уилл как раз был мастером делать то, что еще никто не делал.

Он был не настолько хорош, чтобы выдавать на 100% идеальный готовый код. Но его код был на 75-80% вполне приличным и в большинстве случаев работал. Когда он ушел в другой проект — TIP, если не ошибаюсь, — мы с Дэйвом продолжали работать над системой IMP, и именно тогда я переписал алгоритм маршрутизации, поскольку не понимал, откуда взялись заложенные в нем константы. Это по-прежнему оставался алгоритм Уилла, но переписанный в моем стиле. И теперь я понимал, как и почему он работает, потому что сам заставил его работать.

Одним из наших главных расхождений с Уиллом — я мог часами работать под его скептическим взглядом — была его убежденность в том, что, переписывая программу, порождаешь больше новых ошибок, чем исправляешь старых. Поэтому его блокнот был полон заплаток. Он до последнего готов был исправлять имеющуюся программу, вместо того чтобы ее переписать. В итоге заплаты ставились на заплаты, и вся система настолько усложнялась, что сам Уилл не мог предсказать, как она будет работать. Тяжело было после этого все наладить, хотя, казалось бы, именно для этого и добавлялись заплатки.

Сейбел: Итак, у вас был листинг оригинального исходника, который нужно было скормить ассемблеру...

Козелл: Да. И запущенный двоичный образ. Затем мы с помощью перфоленты — а порой и вручную — вставляли переход на небольшую область, где три исходные строки кода заменялись на эти пять новых, после чего управление передавалось обратно и работа продолжалась как и раньше. То есть при исполнении этого кода машина обращалась к заплатке, выполняла нужные действия, а потом возвращалась обратно.

Сейбел: Значит, перфолента содержала двоичную версию заплатки?

Козелл: Да. Потом уже я написал маленький интерактивный отладчик, выполнявший функции проверки и помещения заплатки в нужное место. Это существенно облегчало работу: можно было нанести на ленту такую программу: «Перейти по адресу 12785, значение, значение, значение, значение. Пустая строка. Перейти по адресу 12832, значение, значение, значение, значение, значение». Если надо было загрузить программу с нуля, то сначала загружалась сама программа, потом — лента с заплатками.

Сейбел: Значит, на том этапе у вас не было никакого исходного кода, который ассемблировался бы в текущее состояние запускаемой двоичной программы?

Козелл: Совершенно верно. Одна из проблем состояла в том, что у нас было несколько вариантов текста программы. В одном из них мог быть помечен участок кода, где две строки нужно вычеркнуть, заменив таким-то кодом. Были ли такие пометки во всех вариантах? Хорошо, что Уилл все записывал в свой чудесный блокнот — именно он и был последней инстанцией. Таков был его подход.

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

То есть мы почти избавились от такой проблемы, как добавление новых ошибок при исправлении старых, разве что заплатка оказывалась неправильной.

Тут мы с Уиллом здорово спорили, потому что он действительно любил ставить заплатки, стремясь держаться подальше от ассемблера, — отчасти потому, что это занимало много времени, а так он мог, поставив заплатку, работать дальше, а отчасти потому, что не доверял циклу, считая редактирование слишком опасным.

Сейбел: Считаете ли вы работу над IMP одним из своих главных профессиональных достижений?

Козелл: Как ни странно, нет. Да, это был интересный, трудный проект. Но кроме него я написал DOCTOR, программировал на Лиспе, стал «царем больничной компьютерной системы». По-настоящему важной для меня работой была работа над той революционной системой разделения времени, в которой я так тщательно разобрался. A IMP был просто одним небольшим коммуникационным процессором. Там не было столько каналов прерываний, как на PDP-1. Не приходилось решать проблемы вроде такой: как быть, если у тебя всего 32 слота для своппинга, а в системе авторизовано 40 человек?

Работа с IMP принесла нам известность, это было весело и интересно. Написать и отладить некоторые места было действительно непросто. Но я бы не назвал это вершиной своей карьеры. Это была просто еще одна программа. К тому же система IMP была весьма ограниченна в применении. Работа же PDP-1 была настоящим вызовом. Это была система разделения времени, которую требовалось постоянно развивать.

Самое примечательное в системе IMP — это скорость, с которой мы ее сделали. Ребята официально начали работать над ней в январе, я присоединился в феврале, а в сентябре она была уже готова. Относительно «готова», потому что мы продолжали вылавливать баги и вносить еще некоторые изменения. Но все же в сентябре программа официально была выпущена. Вскоре Уилл перешел в другой проект, а мы с Дэйвом и еще пара новых ребят продолжили дорабатывать систему.

Должен выразить самую искреннюю благодарность Фрэнку Харту. Не знаю, как ему удавалось руководить нами, при этом всегда позволяя оставаться самими собой. Не припоминаю ни одного собрания программистов. Не припоминаю, чтобы нас хоть раз загрузили бумажной работой, когда наши головы были полностью заняты программой и некогда было отвлекаться на все это. Это был такой уровень доверия и уверенности, когда нам троим просто дали эту работу и оставили в покое. Оглядываясь назад, я понимаю теперь, как это трудно быть менеджером проекта и какую потрясающую работу проделал Фрэнк. Никаких еженедельных собраний сотрудников, никакого рисования PERT-диаграмм на доске. Уилл, конечно, отслеживал текущие задачи, найденные ошибки и прочую проделанную работу, но отсутствие какого-либо систематического надзора над нами поражало. Собрать нас вместе, дать нам поручение и уйти в тень — думаю, для руководителя это был очень смелый поступок.

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

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

Та часть выступления, в которой ты был уверен, не вызывала интереса. Тебе просто говорили: «О!» Но на той части, где ты «плавал», непременно концентрировали внимание. Я знаю тех, кто действительно боялся таких ревизий. Неуверенный в себе программист мог подумать, что его раскритиковали, выставив некомпетентным, и все плохо.

На самом же деле все было не так, и с другой стороны стола это было отлично видно. Ревизия проекта помогала сотруднику двигаться в верном направлении при работе над проектом. Там, где он чувствовал себя уверенно, он мог разобраться и сам. Но зато лучшие умы BBN могли подсказать ему что-то в тех местах, которые он недостаточно продумал. Почему так получилось? О чем он вообще думал? Что пошло не так? За 15 минут можно было получить реальную помощь.

Нужно быть достаточно уверенным в своих навыках профессионалом, чтобы сказать: «Отлично. Вот моя проблема. Я не знаю, что с ней делать, и когда готовил свой отчет, надеялся, что вы, ребята, этого не заметите и одобрите его». Естественным ответом на это будет: «Конечно, мы одобрим его, потому что он выглядит хорошо. Теперь давай разберемся с твоей проблемой — наши лучшие парни собрались здесь как раз для того, чтобы ты не бился над этим сам еще неделю или две».

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

Конечно, для клиента составлялся другой отчет, весь в радужных тонах. Но для сотрудника такие внутренние отчеты были реальной возможностью вырасти профессионально. И меня всегда удивляло, насколько многие люди их боятся. Умный парень может уверять себя и других в том, что его отчет будет порван на клочки. Хотя ясно, что не будет, если в нем есть хоть что-то хорошее, и что тут собрались не его враги. Но убеждать в этом такого парня было совершенно бесполезно. Он все равно пытался пустить всей BBN пыль в глаза, рассказывая о том, как все замечательно.

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

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

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

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

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

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

Сейбел: Вы упомянули 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 страницы кода.

Сейбел: Ого!

Козелл: Я спорил с ним, потому что сам решительно предпочитаю простые, вызываемые один раз подпрограммы. Единственная цель такой подпрограммы — абстрагировать одну небольшую часть родительской подпрограммы. По-моему, если родительская подпрограмма шокирует своим объемом и сложностью, это верный признак того, что все нужно переделывать. Допустим, у меня есть маленькая подпрограммка, в которой говорится: «Отсортируй таблицу и найди лучший путь», и она вызывается всего один раз. Кто-нибудь оптимизирующий код может сказать: «Это не должно быть подпрограммой. Просто добавь ее в код». Но эту маленькую подпрограммку я могу рассматривать изолированно. Сразу ясно, какие у нее входные данные. Ты видишь алгоритм и можешь быть спокоен, потому, что все понимаешь. Тот парень ненавидел, когда я говорил ему: «Твои подпрограммы слишком сложны. Они занимают много места». Он в таких случаях отвечал: «Все в порядке, потому что я могу сделать это все в одной подпрограмме».

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

Сейбел: Не понимая, что ранее написанные им программы также не удовлетворяли этим стандартам?

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

Сейбел: Вы придерживаетесь каких-либо правил относительно количества комментариев?

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

Я добавляю комментарий в код, только если инстинкт говорит мне: «Этот конкретный участок кода, хотя и работает, не совсем ясно показывает, что я хочу сделать». Тогда я пишу: «Этот код сортирует таблицу», если по каким-то важным для меня причинам он не очень похож на стандартный предназначенный для этого код.

Я никогда не был фанатом структурированных программ, где каждая подпрограмма сопровождается 18-строчным комментарием и все аргументы идут в строгом порядке. Я не структурирую свои программы настолько тщательно. Какие-то из моих подпрограмм могут быть длинными, другие — короткими. Меня беспокоит общая структура программы, так сказать, расположение фигурных скобок.

Одна из причин состоит в том, что я смотрю на работу кода в целом, а не его отдельных частей. Так, встретив инстукцию if, я вижу условие. Я мысленно отвечаю на это условие «да» или «нет», и если хочу пропустить тело инстукции if, то код должен позволить мне перейти к тому, что идет после этой инстукции, не особо вникая в синтаксис. То есть я из тех старомодных парней, которые любят, чтобы открывающая и закрывающая скобки стояли одна под другой.

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

Я всегда стараюсь задвинуть бардак подальше, поместить его в такое место программы, где он не мешал бы понимать структуру и работу кода. Мне тяжело воспринимать некоторые стили программирования, не предусматривающие ясную структуру. Интересно, что у автора языка Python мозги, похоже, устроены в точности как у меня. Он разом избавился от проблем с синтаксисом кода, потому что у него не требуется открывать и закрывать скобки. Если ты видишь инстукцию if, то открывающая фигурная скобка неявно будет рядом, как и закрывающая. И если хочешь пойти по коду дальше, то он будет выровнен по этому if. Я работаю с Си и Perl, предполагая, что в Python то же самое: можно нажать кнопку, и вся программа сворачивается так, что видишь только ее общую структуру.

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

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

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

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

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

Как уже сказано, я зачастую не имел ни малейшего понятия где именно находится баг. В какой-то момент я говорил себе: «Этот участок кода должен делать то-то и то-то, но не похоже, что он действительно это делает. Зачем вообще было писать такой сложный код для такой простой операции?» Так что я просто выкидывал этот кусок и заменял его подпрограммой, которая делала то, что он должен был делать. И программа сразу, как по волшебству, начинала работать. Если разобраться, то дело, как правило, было в том, что программа развивалась и ее части должны были развиваться вместе с ней. А автор предпочитал исправить старую подпрограмму, вместо того чтобы заменить ее новой, и где-то ошибался.

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

Сейбел: Значит, у вас должны быть какие-то стратегии чтения кода. Допустим, исправлять ничего не надо, просто перед вами большой кусок кода, который нужно разобрать. Как вы с этим справлялись?

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

Читая программу, я одновременно думаю, как бы я решил связанную с ней задачу. То есть ищу те места, в которых смогу сказать: «О, вот тут программа делает то-то». Нередко после этого я со свойственной мне самоуверенностью могу сказать, что автор написал эту часть неправильно. Или, по крайней мере, понимаю, что было сделано не так, как сделал бы я.

Итак, я двигаюсь от общего к частному. Но я знал и тех, кто поступал наоборот, добиваясь отличных результатов. Они начинали читать мелкие подпрограммы и наконец находили среди них нужную. Но я, повторюсь, делал иначе. А именно, смотрел на программу и стремился понять, что ее авторы хотели сделать. Зачастую это позволяло исправлять ошибки, даже не понимая, какие именно ошибки я исправляю. Я доходил до определенного места и говорил себе: «Этот участок кода — как я сейчас понимаю — должен делать то-то»; и после этого выяснялось, что либо он этого не делает, либо слишком запутан и дополнительно нагружен другими задачами.

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

Работая над своей первой большой программой, системой разделения времени для PDP-1, я был рядовым программистом, решающим проблемы на уровне выпускника колледжа. После этого, в больничном проекте, я быстро прошел все стадии от написания приложений до уровня системного программирования. Имея полугодичный стаж работы, я уже мог уверенно сказать: «Вот этот кусочек своппинга удаленного процесса выглядит неправильно, и я должен его переписать».

Сейбел: Кроме опасности добавления новых ошибок есть еще одна — можно неправильно понять, что программа должна делать.

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

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

Другой мой принцип состоял в том, что код всегда должен быть ясным и понятным. Я хотел, чтобы все было на своем месте. Исправляя баг в программе, я никогда не исправлял только ту ее часть, где он находился. Правило такое: «Если бы ты знал раньше то, что знаешь сейчас об этом участке кода — а именно то, что тут ошибка, — как бы ты тогда написал его?» Почему ты тогда допустил ошибку? Исправь код так, чтобы это больше не повторилось. Когда ты закончишь, каждый переписанный тобой участок должен выглядеть как новый, только что написанный. Я не хочу видеть признаки исправлений или следы ошибок, или загадочные участки кода, говорящие: «Эта подпрограмма каждый раз выдавала неверные значения, и поэтому я должен был ее исправить». Я не хочу видеть ничего из этого, а хочу видеть код, написанный так, будто озарение снизошло на тебя с самого начала.

Плюс к этому у меня есть еще один трюк. Я научился ему, когда работал над проектами министерства обороны. Они никогда не финансируют новые проекты. И правительство, и BBN уже вложили слишком много в текущий проект, хотя, возможно, он ужасен и его надо исправлять. Назначение программы, требования к ней или что-то еще стало другим — и вот то, что ты на первых этапах сделал совершенно правильно, теперь, в новых условиях, лучше будет переделать. Ты к этому готов, но начальство спрашивает: а зачем нужны исправления? Там какая-то ошибка? Никакой ошибки, отвечаешь ты, просто это сделает программу лучше. Будь уверен, что разрешения ты не получишь.

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

Так что на вопрос «Сколько времени потребуется, чтобы внести изменения?» есть три ответа. Первый — это кратчайший путь, когда заменяешь одну строку кода. Второй путь основан на моем простом правиле: перепиши кусок так, как будто ты с самого начала не собирался ошибаться. Третий же и самый длинный путь — это переписать кусок так, будто пишешь его для уже усовершенствованной программы. Ищешь разумную середину между вторым и третьим вариантами и в результате получаешь дополнительное время для совершенствования программы. Думаю, это очень важно. Так программа может развиваться постепенно. Здорово, конечно, иметь дело с программой, которая всегда остается в одной и той же самой первой версии, но это как жить в каменном веке. Зато в моем варианте мы в итоге получаем новенькую с иголочки программу, причем без разрешения менеджера проекта на эти работы.

Сейбел: Вы когда-нибудь слышали о рефакторинге?

Козелл: Нет, а что это?

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

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

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

Сейбел: Как вы нанимаете программистов? Как определяете, есть ли у них талант?

Козелл: Никогда не понимал стандартного подхода к собеседованиям. Говорят, им дают маленькие задания — кажется, этим особенно прославилась Microsoft. Мой подход можно назвать более интуитивным. Первым делом я просматриваю резюме, стараясь понять, мой ли это тип человека. Часто в резюме вообще нет никакого смысла, так как на работу приходит старшекурсник. Между строк легко прочесть, что такой-то красивый с виду проект на самом деле был учебным заданием по одному из курсов. Но можно поговорить с кандидатом и понять, присущ ли ему тот пытливый, любознательный, дотошный склад ума, который я так ценю в людях.

Какие у него есть интересы помимо профессиональных? Способен ли он схватывать на лету, любопытен ли? Такие вещи видны сразу. У меня сложился некий идеальный образ работника в стиле BBN, который включает в себя сообразительность, любопытство, обучаемость, заинтересованность и широту кругозора. И я всегда присматривался, не такого ли типа человек передо мной.

Сейбел: Как вы сказали, в Microsoft любят задавать кандидатам головоломные задачки. А вы любите головоломки? Как по-вашему, могут они дать представление о потенциале человека?

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

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

Хорошим примером может послужить история с кубиком Рубика. Когда эта головоломка появилась в Европе, до нас начали доходить слухи о ней. И вот один из наших сотрудников привез из командировки в Англию целую сумку этих кубиков. Никаких инструкций или готовых решений, и во всех Соединенных Штатах их тоже никто не знал. Просто необычная головоломка. И мы начали ее решать. Вскоре несколько наших сотрудников смогли собрать кубик, причем каждый, что интересно, сделал это по-своему. Теперь очевидно, что это были как раз самые талантливые люди в BBN. Таких людей я и ищу.

Не знаю, могут ли головоломки, которые дает Microsoft, — или тесты на сообразительность, которые, как я слышал, устраивает Google, или еще что-то такое, — показать, обладает ли человек нужными качествами. Но вот на что смотрю я. Готов ли человек работать в стиле BBN? Часто я вижу, что нет. Это может быть замечательный человек и гениальный программист, но в нем нет искры. Я всегда искал искру и едва ли смогу точно объяснить, как.

Сейбел: Думаете, программирование — это занятие для молодых?

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

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

Сейбел: Во многом энергичность — это просто физическая способность работать по много часов в день. Это необходимость или просто одно из последствий увлечения работой?

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

Один из лучших сотрудников BBN умудрялся работать по совершенно нормальному графику и при этом закончить докторскую диссертацию просто за счет своей феноменальной организованности. Каждую субботу он целиком посвящал научной работе, дополнительно возвращаясь к ней в будни по вечерам. Думаю, организованность — важное слагаемое успеха. Гораздо проще делать что-то, имея четкий план, откладывать работу в сторону и вновь приниматься за нее в определенное время, зная, что в нерабочее время можешь о ней не думать. Я понял это недавно, поскольку сейчас моя жизнь стала более размеренной. Сам я программирую достаточно бессистемно, откладывая работу и снова принимаясь за нее позже. Я обнаружил, что если перерыв в работе над какой-то программой составляет больше двух недель, включиться в нее снова бывает очень трудно. Часто, когда я работаю над каким-то маленьким личным проектом и мне действительно хочется его закончить, я говорю сам себе: «Ладно, попробую составить график. Буду работать по два часа каждое утро». И это почти никогда не срабатывает. В какой-то момент мне надоедает такой темп, я сажусь и заканчиваю все за день-другой непрерывного труда.

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

Сейбел: Вы бы назвали себя ученым, инженером, художником, ремесленником или кем-то еще?

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

Сейбел: Начнем с инженерной составляющей. Многие, как Уотте Хамфри и сотрудники Института программной инженерии (SEI), считают, что программирование нужно преподавать как техническую дисциплину, вроде строительства мостов. Человека можно научить строить мосты, рассчитывать, сколько времени на это потребуется, и их мосты, как правило, не рушатся.

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

Но в определенном смысле программирование действительно является инженерной дисциплиной. Ты должен знать, что делаешь. Трезво оценивать свои возможности. На своем уровне я должен был уметь охватить взглядом все детали, чтобы собрать их воедино. Должен был интуитивно понимать, что будет работать быстро, а что медленно; что будет легко сделать, а что — нет. И в результате, подобно инженеру, подготовить проект.

Художественная составляющая заключается в том, что программа должна быть элегантной. В нашем деле это важно, так как искусностью написания программы определяется ее долговечность. Часть того, что я называю художественным программированием, — это искусство написать программу так, чтобы твои последователи могли легко изменять ее, не разрушая. Это не имеет ничего общего с функциональностью, но тем не менее определяет будущую жизнь программы.

Сейбел: Итак, для вас красота кода тесно связана с тем, что люди будут его изменять.

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

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

Сейбел: А как быть с противоречием между ясностью и эффективностью? Подчас простой, легко читаемый код не является самым быстрым.

Козелл: Программисты — худшие оптимизаторы в мире. Они всегда оптимизируют то, что им интересно оптимизировать, и почти никогда то, что действительно в этом нуждается. В результате получаются островки бесполезно сложного кода. Я всегда говорю тем, кто работает со мной: «Программируй так легко, прозрачно и просто для понимания, как можешь. Будь проще. Со скоростью разберемся потом, если понадобится. Если ты все сделаешь правильно, внести доработки будет несложно».

Когда-то давным-давно в исходном коде одной из версий Emacs была страница с большим черепом и скрещенными костями в комментариях, где говорилось примерно следующее: «Здесь очень запутанный код». То был кусок в самой глубине поискового кода, или чего-то такого, и он был заоптимизирован до смерти. Исключительно сложный для понимания код. Как черный ящик с надписью «Не влезай, если не уверен».

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

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

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

Козелл: Совершенно верно. По-моему, прекрасная схема. Отлично готовит к трудностям реальной жизни.

Сейбел: Беседуя с Кеном Томпсоном, я спросил его, есть ли у языка Си врожденные пороки, которые привели к проблемам с безопасностью. И он сказал, что на самом деле все было в порядке. Преподавая компьютерную безопасность, как вы прокомментируете это?

Козелл: Не хотел бы скрещивать с ним шпаги, но в своем курсе говорю, что самые большие проблемы с безопасностью у современных компьютеров бывают как раз из-за Си. Он был создан как язык системного программирования и оказался таким удачным, что его стали использовали во всех важных проектах. Мы пишем на нем операционные системы и системы реального времени.

Я помню, какие войны кипели в эпоху Паскаля. Говорилось, что компьютер должен сам помогать тебе; что Си слишком опасен как язык программирования. Помнится, эту позицию отстаивали два авторитета — Вирт и Дейкстра. По другую сторону баррикад находились все известные мне системные программисты, включая меня самого. Я писал все на Си. Этот язык, можно сказать, смел тогда всех конкурентов.

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

Но когда-то это было просто спасение для системных программистов. От мысли о том, что мы могли бы писать системы на ассемблере, а приложения — на Паскале, у меня мурашки по спине бегут. Не думаю, что это было бы правильно. Но имея опыт написания как систем, так и приложений на Си, должен сказать, что этот язык не оправдал наших ожиданий. Работать в нем оказалось слишком сложно.

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

Для системы IMP я написал сложный набор ассемблерных макросов, позволявших объявлять, что делаешь. Дойдя до прерывания, пишешь объявление вроде: «Я обрабатываю данные из модема» или «Я в высокоприоритетном или низкоприоритетном таймере». И когда программа ассемблируется, для каждой инструкции проставляется метка и на каком уровне прерывания она выполняется, а затем запускается постпроцессор, написанный мною, кажется, на макросах ТЕСО, и проверяет, нет ли проблем с разделением времени. Если он обнаруживает переменную, доступ к которой осуществляется из двух разных уровней, то пишет: «Обнаружен конфликт прерываний». И ошибка с разделением времени сама собой исправляется. Программист быстро привыкает к тому, что если он пишет правильные объявления, система сама удерживает его от ошибок. Я специально ездил в Венгрию, чтобы показать, как не разбирающиеся в проблемах разделения времени программисты могут с помощью этого метода писать соответствующие программы на хорошем уровне.

Вот, если вкратце, что я думаю о Си. Уверен, что есть хорошие программисты, возможно, и я в их числе, которые могут писать на этом языке хорошие программы. Но это дается нам труднее, чем должно было быть. В современном мире эта проблема усугубилась, потому что вокруг становится все больше и больше программ на Си, и у программистов все больше работы по преодолению их недостатков. Это одна из причин, по которым мне нравится программировать на Perl. Perl медленный. Думаю, это один из самых медленных языков программирования, но зато в нем нет тех проблем с безопасностью, которые есть в Си. Что происходит в Perl, если информация не влезает в массив? Массив увеличивается в размерах, только и всего.

Этот язык знает, куда указывают его указатели, так что вы никогда не сможете «сбиться с пути»: нужно просто сказать системе, чтобы проследила путь и узнала, куда он ведет. Я уверен в этом языке, потому что на протяжении многих лет люди работают с его ядром, и оно очень стабильно. Не думаю, что в написанных на нем программах попадается много ошибок выделения памяти или проблем с указателями; фактически их вообще трудно допустить в коде Perl. He приходится надеяться только на программистов.

И даже после этого бывают случаи вроде того хрестоматийного, когда кто-то написал веб-страницу, искавшую имена в таблицах, а неизвестный хакер написал в строке ввода что-то вроде «Joe;drop all tables». Такое еще случается. Это, конечно, не вина языка Си, но видно, что программисты подчас бывают недостаточно осторожны. Они не продумывают все варианты, а в Си их слишком много. Все это кажется мне слишком опасным. Справедливости ради нужно добавить, что я программировал на Си на пять лет меньше Кена. Мы с ним в разных весовых категориях, но все же у меня большой опыт общения с Си, я знаю, как это непросто, и думаю, что дело тут, по большей части, в самом языке.

По мере того как приложения будут становиться все более и более сложными, построенными на все более и более сложных библиотеках, — и все окончательно перестанут понимать, где в них «дыры» из-за их чрезвычайной сложности, — наверное, нам придется перейти к программированию приложений на менее располагающем к ошибкам языке. Процессоры становятся потрясающе быстрыми, а память — удивительно дешевой. Не могу сказать, какой он — завтрашний язык программирования. Не думаю, что Си или его дальнейшие модификации, вроде C++, станут подходящей платформой, на которой программирование приложений — даже развитие систем — сможет двигаться дальше.

Java не кажется мне выходом. Мои старые рефлексы не подводят. Этот язык неприятно поразил меня своей авторитарностью. Это еще одна причина, по которой я хвалю Perl, — он безопасный, надежный и при этом чертовски разнообразный, так что художник во мне получает достаточное поле для самовыражения и выбора оптимальных путей. Я свободен.

Впервые попробовав Java — еще совсем молодой тогда язык, — я сказал себе: «А, еще один язык, призванный помочь посредственным программистам встать на путь истинный, ограничивая их». Но, возможно, сейчас это и правильно. Пожалуй, сегодня опасно полагаться на хороший, гибкий язык, на котором один или два процента программистов смогут писать высокохудожественные программы, потому что в мире уже 75 миллионов штампованных программистов, пишущих чрезвычайно сложные приложения и нуждающихся в помощи. Так что, вероятно, Java — это то, что нужно. Я не знаю.

Сейбел: До вас я брал интервью у Фрэн Аллен, сотрудницы IBM, писавшей компиляторы для Фортрана. Её Си разочаровал совсем другим — тем, что для него невозможно написать хороший оптимизирующий компилятор, потому что язык слишком низкоуровневый.

Козелл: Ну, она из другого лагеря. Она создает компиляторы и видит Си как ужасный, неудобный этап, от которого никуда не денешься. Когда мы работали с ассемблерами, жонглируя битами, Си был просто глотком свежего воздуха. Понятно, что большинство лучших программистов того времени работали не с Бейсиком и не с Фортраном. Самыми крутыми были, конечно же, те, кто писал ассемблерный код. И мы сразу же перешли на Си — это было как небо и земля. Если вы думаете, что это у Си проблемы с границами массивов, попробуйте написать цикл по массиву на ассемблере. Так что здесь это был настоящий прорыв.

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

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

Козелл: О, да. Это еще одна причина, из-за которой я выгляжу живым динозавром. Ничто не появляется на пустом месте, а развивается из чего-то. Я помню, как на PDP-11 с седьмой версией UNIX мы делали кое-какую анимацию и графику. Это было по-настоящему трудно программировать. Мониторы были громоздкими. Не было библиотек.

Каждое поколение программистов уходит все дальше от того старого оборудования и получает в распоряжение все более совершенные инструменты. Это хорошо, потому что расширяет их возможности. Базовый уровень все выше, а следующий выглядит еще лучше — а через пару лет он сам становится базовым и так далее. Проблема в том, что сложность тоже возрастает. Набор инструкций PDP-1 покажется сущей ерундой по сравнению с тем, что происходит сейчас.

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

У нас была когда-то такая вещь, как IMLAC — одна из первых машин, имевших интегрированный векторный дисплей, подобный установленному на старом PDP-1, но в отличие от него это был мини-компьютер. Для него была игрушка: ездишь в маленькой машинке по трехмерному лабиринту и видишь, как приближаются стены, заворачиваешь за углы. Помню, я был поражен тем, что она удаляла невидимые линии. Это было в ту эпоху, когда журнал «Communications of the ACM» публиковал статьи об алгоритмах. У меня была целая книга о том, как использовать симметричные координаты; и я видел написанный кем-то алгоритм, вычислявший, где пересекаются две линии, так что можно было узнать, где линия пересекает плоскость, то есть место, где ее надо уже прекратить рисовать, потому что дальше она не видна.

Работать со скрытыми линиями в те времена было очень трудно, а та программа делала это. Я был просто поражен. Это было что-то уникальное. Могу сказать, что сегодня видеокарты легко оперируют трехмерными координатами и удаляют невидимые линии. Восемь, девять лет назад наложение текстур и трассировка лучей были чрезвычайно сложными, трудно программируемыми задачами. Нужно было потратить часы, чтобы нарисовать блик на сфере.

Современные видеокарты, насколько мне известно, умеют делать трассировку лучей. Так что сегодня, с одной стороны, мы видим разработчиков NVIDIA и подобные чрезвычайно сложные программы обработки видео, с другой — современного программиста, которому мало нарисовать двумерную стену, а нужно создать полноценную ЗD-среду, основанную на библиотеках, которые становятся все более и более сложными. Работать с ними проще, чем писать код самому, но я все равно не понимаю, как люди справляются. Для меня это слишком сложно.

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

Так что я не завидую современным программистам, им все труднее и труднее. Простые вещи упаковываются в библиотеки, остаются только сложные. Оборудование становится все совершеннее, а запросы людей — выше и выше. Недавно мне показали кое-что поразительное. Это одна из опций системы прокладки маршрута в Google Maps. Можно захватить мышью и перетащить участок маршрута в другую точку, так чтобы система поняла: путь должен быть проложен через нее. И Google переделывает маршрут соответствующим образом. Теперь я знаю, как это работает: большой кусок кода в JavaScript отслеживает передвижения мыши. Когда отпускаешь кнопку мыши, он формирует запрос на Ajax XML, сообщая материнской системе, что выбран новый пункт маршрута. После этого вычисляется новый маршрут. Я просто не представляю, как это можно было так здорово запрограммировать! Люди жалуются, что им проложили маршрут через огороды и тому подобное, но проблема выбора оптимального маршрута — одна из старейших в компьютерной науке: как найти кратчайший маршрут на произвольном графе? Сногсшибательно.

С одной стороны, я восхищен. С другой, думаю про себя: «Боже, как здорово, что в мои времена такого не было». Я бы никогда не написал код для решения такой задачи. Как они это делают? Наверное, выросло целое поколение программистов, превосходящих меня. Я рад, что некогда заработал репутацию хорошего программиста и не должен больше ее подтверждать, потому что я бы просто не смог.

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