14. Берни Козелл

14. Берни Козелл

В 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”[75] Кнута, которое я когда-то прочитал от корки до корки. Но его едва ли можно рекомендовать как учебный текст.

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

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

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

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

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

Если станет интересно, всегда можно заглянуть в книгу Кнута, но обычно это не требуется. Что действительно нужно изучить студенту, так это структуры данных. Его не должно шокировать, например, создание связных списков в 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 пыль в глаза, рассказывая о том, как все замечательно.

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

Данный текст является ознакомительным фрагментом.