Во многом энергичность — это просто физическая способность работать по много часов в день. Это необходимость или просто одно из последствий увлечения работой?
Козелл: Думаю, это индивидуально. Кто-то может отложить работу и вернуться к ней спустя некоторое время, кто-то нет. В BBN было много блестящих профессионалов, которым вполне хватало рабочего дня и которые не проявляли желания трудиться в выходные. Были, конечно, и обратные случаи — так, я одно время спал прямо в компьютерном зале, не желая тратить время на дорогу домой и обратно. Мне было все равно, насколько сумасшедшим меня из-за этого считают. Но не думаю, что такие подвиги необходимы, — скорее это побочный продукт нашей полной вовлеченности в работу.
Один из лучших сотрудников BBN умудрялся работать по совершенно нормальному графику и при этом закончить докторскую диссертацию просто за счет своей феноменальной организованности. Каждую субботу он целиком посвящал научной работе, дополнительно возвращаясь к ней в будни по вечерам. Думаю, организованность — важное слагаемое успеха. Гораздо проще делать что-то, имея четкий план, откладывать работу в сторону и вновь приниматься за нее в определенное время, зная, что в нерабочее время можешь о ней не думать. Я понял это недавно, поскольку сейчас моя жизнь стала более размеренной. Сам я программирую достаточно бессистемно, откладывая работу и снова принимаясь за нее позже. Я обнаружил, что если перерыв в работе над какой-то программой составляет больше двух недель, включиться в нее снова бывает очень трудно. Часто, когда я работаю над каким-то маленьким личным проектом и мне действительно хочется его закончить, я говорю сам себе: «Ладно, попробую составить график. Буду работать по два часа каждое утро». И это почти никогда не срабатывает. В какой-то момент мне надоедает такой темп, я сажусь и заканчиваю все за день-другой непрерывного труда.
Я еще могу концентрироваться на работе, но уже не так хорошо, как когда-то. Вот почему я думаю, что-то увлеченное, вдохновенное программирование, свойственное настоящим хакерам, — это в значительной степени занятие для молодых. Приходится признать, что почти все, кого я знал, кто сделал в молодости какие-то потрясающие вещи, работали над ними интенсивно. Мне трудно представить настоящий шедевр, который его автор делал бы по два часа каждое утро, как рутинную работу. Обычно такие вещи достигаются безумным напряжением сил. Это тяжело, это выматывает. И я в конце концов вымотался.
Сейбел: Вы бы назвали себя ученым, инженером, художником, ремесленником или кем-то еще?
Козелл: Скорее, я что-то среднее. Не считаю себя ученым, так как не считаю свою работу научной. Правильным ответом будет сочетание художника и ремесленника. То, как я программирую, — это комбинация искусства и ремесла.
Сейбел: Начнем с инженерной составляющей. Многие, как Уотте Хамфри и сотрудники Института программной инженерии (SEI), считают, что программирование нужно преподавать как техническую дисциплину, вроде строительства мостов. Человека можно научить строить мосты, рассчитывать, сколько времени на это потребуется, и их мосты, как правило, не рушатся.
Козелл: Именно так. Хорошая аналогия, хотя и не безупречная. На самом деле, парень, который проектирует мост, так чтобы он не обрушился, сам не проверяет стальные канаты на прочность, не замешивает бетон и не делает много другой грязной работы.
Но в определенном смысле программирование действительно является инженерной дисциплиной. Ты должен знать, что делаешь. Трезво оценивать свои возможности. На своем уровне я должен был уметь охватить взглядом все детали, чтобы собрать их воедино. Должен был интуитивно понимать, что будет работать быстро, а что медленно; что будет легко сделать, а что — нет. И в результате, подобно инженеру, подготовить проект.
Художественная составляющая заключается в том, что программа должна быть элегантной. В нашем деле это важно, так как искусностью написания программы определяется ее долговечность. Часть того, что я называю художественным программированием, — это искусство написать программу так, чтобы твои последователи могли легко изменять ее, не разрушая. Это не имеет ничего общего с функциональностью, но тем не менее определяет будущую жизнь программы.
Сейбел: Итак, для вас красота кода тесно связана с тем, что люди будут его изменять.
Козелл: Одна или две моих программы были эдакими «черными ящиками», от которых требовалось только одно — работать, пока компьютер включен. Но остальные представляли собой код, с которым поколения программистов могли потом возиться, не выбрасывая на помойку. Когда я говорю об искусстве и красоте, это значит вот что: приступая к написанию программы, вы имеете большую свободу действий. Как вы организуете ее функции, как расположите их, где добавите комментарии, как назовете переменные, будут ли одинаковыми вызывающие последовательности.
То есть вам приходится смотреть на программу глазами другого программиста, который будет работать с ней сколько-то лет спустя. Какова структура программы? Что она делает? Как она это делает? И почему? Работа художника — это когда тот, следующий парень читает программу и понимает, что вот эта подпрограмма предназначена для того-то. Когда он понимает, что лучше не выбросить вашу программу, а поработать с ней еще, оставив структуру как есть.
Сейбел: А как быть с противоречием между ясностью и эффективностью? Подчас простой, легко читаемый код не является самым быстрым.
Козелл: Программисты — худшие оптимизаторы в мире. Они всегда оптимизируют то, что им интересно оптимизировать, и почти никогда то, что действительно в этом нуждается. В результате получаются островки бесполезно сложного кода. Я всегда говорю тем, кто работает со мной: «Программируй так легко, прозрачно и просто для понимания, как можешь. Будь проще. Со скоростью разберемся потом, если понадобится. Если ты все сделаешь правильно, внести доработки будет несложно».
Когда-то давным-давно в исходном коде одной из версий Emacs была страница с большим черепом и скрещенными костями в комментариях, где говорилось примерно следующее: «Здесь очень запутанный код». То был кусок в самой глубине поискового кода, или чего-то такого, и он был заоптимизирован до смерти. Исключительно сложный для понимания код. Как черный ящик с надписью «Не влезай, если не уверен».
Но если поглядеть на программы, которые мы пишем сегодня, через призму моего опыта, они гораздо больше, уродливее и к тому же медленнее. И это нормально. Сейчас подобные вещи уже не имеют значения. Ребята, которые делают сегодня программы для сведения видео или для компьютерной анимации, просто не могут позволить себе такую роскошь. Для этого требуется много очень аккуратного программирования. Я уже не могу делать такие вещи. Но когда-то это было мне по силам. И я понимаю нынешних программистов. Большая часть программирования сегодня — рутина.
В одном колледже курс программирования длился два семестра, с сентября по май, и уже в самом начале студент должен был составить довольно трудную программу. Но он не подозревал, что в апреле ему придется делать это снова, причем на этот раз к его работе будут предъявлены гораздо более жесткие требования. Идея была в том, чтобы студент понял, насколько трудно вспомнить вещи, о которых полгода назад думал, что хорошо их понимаешь.
Сейбел: То есть все, что ты когда-то лихорадочно делал в последнюю ночь, возвращается к тебе во всей красе.
Козелл: Совершенно верно. По-моему, прекрасная схема. Отлично готовит к трудностям реальной жизни.
Сейбел: Беседуя с Кеном Томпсоном, я спросил его, есть ли у языка Си врожденные пороки, которые привели к проблемам с безопасностью. И он сказал, что на самом деле все было в порядке. Преподавая компьютерную безопасность, как вы прокомментируете это?
Козелл: Не хотел бы скрещивать с ним шпаги, но в своем курсе говорю, что самые большие проблемы с безопасностью у современных компьютеров бывают как раз из-за Си. Он был создан как язык системного программирования и оказался таким удачным, что его стали использовали во всех важных проектах. Мы пишем на нем операционные системы и системы реального времени.
Я помню, какие войны кипели в эпоху Паскаля. Говорилось, что компьютер должен сам помогать тебе; что Си слишком опасен как язык программирования. Помнится, эту позицию отстаивали два авторитета — Вирт и Дейкстра. По другую сторону баррикад находились все известные мне системные программисты, включая меня самого. Я писал все на Си. Этот язык, можно сказать, смел тогда всех конкурентов.
Правительство пыталось поддержать Аду, заключая контракты только на написание программ на Аде. Си пробил и эту стену. Он был просто великолепен. Но и сегодня я не перестаю удивляться тому, что в Си невозможно написать сколько-нибудь сложную программу, не столкнувшись при этом с проблемой безопасности. Этот язык требует от программиста много возни: необходимо каждый раз при копировании информации в буфер тщательно проверять, не выйдет ли она за его пределы; следить, чтобы ни в коем случае не стереть информацию из памяти не вовремя, чтобы указатель где-то в программе не стал неактуальным; следить за тем, чтобы не сохранить что-то, имеющее неправильный размер и способное затереть следующую переменную; эти проблемы нелегко бывает выявить впоследствии.
Но когда-то это было просто спасение для системных программистов. От мысли о том, что мы могли бы писать системы на ассемблере, а приложения — на Паскале, у меня мурашки по спине бегут. Не думаю, что это было бы правильно. Но имея опыт написания как систем, так и приложений на Си, должен сказать, что этот язык не оправдал наших ожиданий. Работать в нем оказалось слишком сложно.
Пример тому — ошибки в программах с прерываниями. Вы можете сказать, что в написании программ с прерываниями ничего сложного. И это действительно так. Нужно всего лишь немного понимания и немного старания. Но я знаю случаи, когда по-настоящему хорошие программисты, обладающие и тем, и другим, делали ошибки в своих программах. Таким, как я, приходилось исправлять эти ошибки, и в конце концов я написал язык в стиле Никлауса Вирта, не дающий программистам ошибиться при работе с прерываниями.