Питер Норвиг — теоретик широкого профиля и хакер в душе. В свое время он написал программу для нахождения в истории поиска Google трех последовательных запросов от одного пользователя, так чтобы они складывались в хокку (один из знаменитых примеров: «Java ЕСС/эллиптическая криптография Java/FAQ „Плейбоя"»).

На сайте Норвига вы найдете самые обычные ссылки: написанные им книги, слайды выступлений, фрагменты его кода. Но там есть также ссылки на его работы, опубликованные в «McSweeney's Quarterly Concern», на искрометный рассказ о создании программы для генерации самого длинного палиндрома и на пародийную PowerPoint-презентацию Геттисбергской речи Линкольна, отмеченную Эдвардом Тафти и появляющуюся на первых страницах результатов, если ввести «powerpoint» в строке поиска Google.

Сегодня Норвиг — глава исследовательского отделения Google, ранее руководил отделением качества поиска. До прихода в Google возглавлял подразделение вычислительной техники исследовательского центра НАСА, а до того, в конце 1990-х, был одним из первых сотрудников интернет-стартапа Junglee. Норвиг — лауреат Премии НАСА за выдающиеся достижения (2001), член Американской ассоциации искусственного интеллекта и Ассоциации вычислительной техники.

Благодаря опыту работы в Google, НАСА и Junglee Норвиг знаком как с «хакерским», так и с «инженерным» подходом к созданию ПО. В нашей беседе он коснулся преимуществ и недостатков каждого из них. Как у бывшего профессора информатики, а ныне сотрудника одной из крупнейших корпораций по производству ПО, у него есть интересный взгляд на отношения между академической компьютерной наукой и промышленной практикой.

Мы говорили о том, как изменилось программирование за последние годы, почему никакие методы проектирования не помогут тому, кто не понимает, что делает, и в чем НАСА может выиграть, применяя менее надежное, но дешевое ПО.

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

Норвиг: В старших классах школы. У нас был PDP-8, кажется так, и уроки информатики — мы осваивали Бейсик. Там-то все и началось.

Сейбел: Какой это был год?

Норвиг: Я закончил школу в 1974 — значит, 1972 или 1973. Кое-что осталось в памяти. Помню, как учительница пыталась что-то объяснять, тасуя колоду карт. Алгоритм был примерно такой: используем генератор случайных чисел для выбора двух карт, поменяем их местами, отметив это в битовом векторе, и будем продолжать, пока не поменяются местами все карты. Помнится, я подумал: «Что за идиотизм, глупее не придумаешь. Так можно продолжать до бесконечности, потому что на какую-то пару карт можно никогда не попасть». Я еще не мог сказать тогда, что это n в квадрате, хотя такой алгоритм может быть порядка n. Я просто знал, что алгоритм неправильный. Потом я предлагал алгоритм перестановки, кажется, Кнута — от 0 до 52, затем от 0 до 51 и так далее — алгоритм порядка n. Но помню, что учительница отстаивала свой способ. Тогда я понял, что у меня, видимо, есть способности к программированию, а еще — что учителя тоже не все знают.

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

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

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

Сейбел: Это была первая интересная программа, с которой вы познакомились. А какой была первая интересная программа, которую вы сами написали?

Норвиг: Наверное, Game of Life. Это было домашнее задание, которое я быстро сделал. Конечно, никаких 30-дюймовых мониторов не было — только телетайп с желтой бумагой. Я подумал, что расточительство — печатать на отдельном листе одно маленькое поле (кажется, 10x10), на следующем — еще одно и так далее. Поэтому я решил распечатать пять поколений подряд. В Бейсике не было трехмерных массивов, а я почему-то не мог просто взять несколько двухмерных массивов — памяти не хватало или еще что-то. Мне нужно было пять или шесть двумерных массивов, и тогда я придумал битовые поля.

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

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

Сейбел: В начале своей программистской карьеры вы что-нибудь делали, чтобы улучшить свои навыки? Или просто программировали?

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

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

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

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

Сейбел: Чем вы там занимались?

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

Одним из проектов была программа построения блок-схем — она должна была анализировать готовую программу и генерировать для нее блок-схему. Отличная мысль, потому что блок-схемы нужны. Но на самом деле их всегда рисуют не до, а после написания программ. Эта программа была умная, потому что умела работать с частичной грамматикой, так что при работе с синтаксически некорректной программой пропускала те ее части, которые не могла разобрать. Она должна была уметь разбирать, к примеру, операторы IF, поскольку те образовывали разные блоки, но по поводу других частей говорила: «Сбросим это все в один блок». И вот мы получили контракт на разработку, в котором было указано, что программа должна работать под UNIX. Мы одолжили машину в Массачусетском технологическом институте и применяли для компилятора все инструменты UNIX — yacc и так далее. В последний момент нам сказали: «Нет, использоваться будет VMS». Так что никакой уасс мы уже не могли применять, но решили, что он нам и не нужен — ведь мы брали его только для составления таблиц, а это мы уже сделали.

Сейбел: Пока грамматика не меняется, все в порядке.

Норвиг: Да, так что мы поставили программу, заказчики были счастливы, а потом, разумеется, грамматика изменилась. У нас больше не было доступа к машинам с UNIX. Мне пришлось править грамматику, роясь в таблицах, и я решил: если вот здесь у нас переход в новое состояние, я создам свое состояние, и переход будет к нему.

Сейбел: Это было правильное решение? Вы не думали о том, чтобы просто написать новый парсер?

Норвиг: Наверное, так и надо было поступить. Но ведь я сделал лишь одну небольшую правку.

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

Норвиг: Я тогда уже ушел в магистратуру, и это уже была не моя проблема.

Сейбел: Уже не ваша... Итак, вы защитили диссертацию. Вы бы хотели, чтобы ваше обучение программированию шло по-другому?

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

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

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

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

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

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

Сейбел: Программирование стало более социальным?

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

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

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

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

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

Норвиг: Это так. И я наблюдаю это у молодых программистов. Еще одна разница между «тогда» и «сейчас»: программирование больше похоже на сборку из готовых модулей, чем на создание чего-то с нуля. Сейчас, делая домашнее задание — скажем, сайт, — школьник возьмет для одной части Ruby on Rails, для другой — Drupal, для третьей — скрипт на Python, а потом скачает статистическую программу. И все это связывается между собой с помощью скриптов, а не пишется с нуля. Сегодня важнее понимать интерфейсы и уметь их соединять, чем знать в деталях, что делается внутри ПО.

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

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

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

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

Норвиг: Скорее первое. Стив Йегг написал статью «Good Agile, Bad Agile» (Agile-проектирование: хорошее и плохое), и думаю, в ней он прав. Десять процентов времени имеет смысл уделять коллективной работе, поскольку программисту необходимы понимающие слушатели. Больше — вряд ли стоит.

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

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

Помнится, у IBM была модель «программиста-мастера» — глупее никто еще ничего не придумал. Кто захочет быть на побегушках у опытного программиста?

Сейбел: Удивительно, что вы считаете эту идею настолько глупой. В своей статье «Teach Yourself Programming in Ten Years» (Как самому научиться программировать за десять лет) вы утверждаете, что программирование — навык, который, как и многие другие, требует десятилетнего оттачивания, чтобы человек стал мастером. Во многих ремеслах работает модель мастер/подмастерье/ученик. Может, никому не нравится быть учеником, но что ужасного в том, что человек с десятилетним опытом будет выполнять другую работу, нежели желторотый новичок?

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

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

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

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

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

Норвиг: Отчасти да, есть. Лучший, наверное, пример — проверка моделей, которой Intel не уделила достаточно внимания, и на отзыве ПО из-за найденной ошибки в умножении они потеряли много денег. Тогда они всполошились и пошли на поклон к ученым. Теперь проверка моделей обязательно входит во все их программы. Другой пример, пожалуй, чуть менее яркий — языки программирования. В этой сфере идет напряженная работа, но она мало отражается на новых языках. Операционные системы, в какой-то мере. Мы финансируем лабораторию RAD в Беркли с Дэйвом Паттерсоном и другими. У них есть хорошие идеи относительно надежности систем. Но это тот случай, когда у индустрии есть куда более серьезные проблемы. Не каждую из них удается решить, но поиски здесь идут более интенсивно, чем в университетах.

Сейбел: Значит, вы не считаете, что часть хороших идей, порожденных учеными, не используются просто из-за нежелания перемен? Ведь множество доморощенных PHP-программистов никогда не заинтересуются языком Haskell, пусть даже он будет удобнее?

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

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

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

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

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

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

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

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

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

Код Google — он правилен или нет? Введя в Google этот запрос, вы получите десять страниц. Если поисковик даст сбой, код неправилен. А если он даст вот эти десять ссылок вместо вон тех десяти — правилен или нет? Можно говорить о том, что вам больше нравится, но дальше этого вы не пойдете. Это немного не то, о чем мы привыкли думать. Как только сталкиваешься с задачами такого рода или задачами вроде передвижения роботизированного автомобиля по улицам города, чтобы он никого не сбил, логические доказательства отбрасываются очень быстро.

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

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

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

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

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

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

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

Норвиг: Выбор велик, тут можно пойти разными путями. Надо прочесть что-нибудь про алгоритмы — программист не должен становиться только склейщиком программ. Можно взять Кнута, а можно Кормена, Лейзерсона и Ривеста. Есть и другие авторы, например Салли Голдман. В ее последней книге алгоритмы рассматриваются с практической стороны. Довольно интересно написано. Кроме того, что-нибудь про идеи абстракции. Мне нравится труд Абельсона и Сассмана, но он не единственный.

Надо досконально знать свой язык. Читайте справочники. Читайте книги, где объясняется механика языка и одновременно способы отладки и тестирования, — «Beautiful Code» или что-нибудь подобное. Но я бы не стал советовать читать исключительно это, а не что-нибудь другое.

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

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

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

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

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

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

Норвиг: Как узнать, чего именно не знаешь?

Сейбел: Вот именно.

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

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

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

Сейбел: Значит, надо рыться в старых статьях?

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

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

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

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

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

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

Сейбел: Для такого рода задач подсчеты на салфетке или симуляции полезнее, чем написание кода.

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

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

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

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

Сейбел: Как насчет разработки через тестирование?

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

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

Еще мне не нравится вот что — мы в Google то и дело сталкиваемся с этим: программа не укладывается в простую булевскую модель теста. В тесте есть assertEqual, assertNotEqual, assertTrue и так далее. Это хорошо, но нам нужно также иметь assertAsFastAsPossible. Нам нужны утверждения относительно огромной базы данных возможных запросов: мы получаем результаты, которые оцениваются по стоимости достижения определенной точности, стоимости повторного вызова — и хотим их оптимизировать. Но вот этих статистических или непрерывных значений, которые мы хотим оптимизировать, в тестах нет. А от булевского типа — «верно или нет» — проку мало.

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

Норвиг: Да. Но просто поглядев на методы, применяемые в тестах, вы поймете, что они не годятся для этого, что в них не предусмотрена такая возможность. Я поражаюсь тому, насколько этот подход распространен в Google. Работая в Junglee, я однажды читал об этих вещах лекцию в отделе контроля качества. Мы занимались исследованиями покупок и сказали тогда: «Нужен тест — можем ли мы по такому-то запросу получить 80% верных ответов». Они спросили: «Хорошо, а неверный ответ — это ошибка в программе?» Я сказал: «Нет, один неверный ответ здесь не будет ошибкой». И они удивились: «Как так, неверный ответ не считается ошибкой?» Как будто здесь был выбор только между «да» и «нет», в то время как это скорее напоминало компромисс.

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

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

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

Отличный урок проектирования программ. Мало кто задается вопросом: «Как будет работать моя программа, если отключат электричество?».

Сейбел: А как в этом случае идет работа в Google?

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

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

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

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

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

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

Норвиг: Мы любим чувствовать себя умными и любим завершенность. Мы хотим как можно скорее завершить работу — закончить и двигаться дальше. Мне кажется, так устроен человек — он может чем-то позаниматься, но потом ему хочется сказать: «Все, готово, выкидываю это из головы и иду дальше». Но надо еще подсчитать рентабельность полностью завершенной работы. Это кривая в форме S — после 80- или 90-процентной готовности рентабельность неуклонно снижается. И у вас есть сотня других проектов, где вы находитесь внизу кривой и рентабельность намного выше. В какой-то момент вы говорите: «Хватит с этим, переходим к более рентабельным вещам».

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

Норвиг: Нужна правильная рабочая среда, ориентированная на результат. Думаю, люди способны учиться сами. Вы хотите оптимизировать что-то, но предоставленные сами себе, вы оптимизируете ваше личное удобство. А надо иметь в виду другое, одни говорят — рентабельность, другие — удовлетворенность клиента. Что лучше для клиента — если я закончу эту программу с 95-процентной готовностью или примусь за десять других, где готовность 0%?

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

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

Норвиг: Нет, все эти UML-инструменты мне никогда не нравились. Я всегда считал, что, если это нельзя выразить на самом языке, это недостаток языка. Многое приходится делать на более высоком уровне. В Google немалая часть работы связана с разбиением программ на модули и организацией их параллельного выполнения. Нам нужно запустить программу на большом числе машин, но у нас столько-то пользователей, столько-то данных для приложений — как все это будет работать? Поэтому мы скорее думаем в терминах машин и машинных комплексов, чем на уровне функций и взаимодействий. Если это улажено, можно переходить к частным функциям и методам.

Сейбел: Описания делаются на уровне простого языка?

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

Сейбел: Как оцениваются такие схемы?

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

Сейбел: У вас принято устраивать формальные ревизии проекта? Вы ведь работали в НАСА, а там с этим строго.

Норвиг: Да, строже, чем в НАСА, не бывает. У нас планка ниже — как я уже говорил, мы можем допустить недочет и исправить его. В НАСА первый же недочет будет фатальным, и они вынуждены быть куда внимательнее. А мы не сильно на этот счет беспокоимся. Скорее консультации, чем ревизии.

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

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

Сейбел: Вы рассказывали, как проверяли Гвидо ван Россума на знание Python, а Кена Томпсона — на знание Си, выясняя, способны ли они придерживаться довольно жестких стандартов кодирования. Для проектирования у вас такие же жесткие стандарты?

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

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

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

Сейбел: То есть это эквивалент классической проверки — кто-то смотрит ваш код и подтверждает, что в нем все в порядке.

Норвиг: Да. На самом деле это был первый проект Гвидо. Мы использовали для этого утилиту diff, но это слишком громоздкий способ. А Гвидо создал распределенную систему с красивым интерфейсом и подсветкой, так что ревизии кода облегчились.

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

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

Сейбел: Понятно. А проверяющим нужны какие-то навыки?

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

Сейбел: Чем отличаются хорошие проверяющие?

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

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

Норвиг: У всех разные умения. Один из лучших наших специалистов по поиску не очень хорошо программирует — код выходит средний. Но, допустим, его спрашиваешь: «Вводится новый фактор — сколько раз человек щелкает на этой странице, сделав то и то. Как учесть его в наших результатах поиска?» И он отвечает: «В строке 427 есть альфа-переменная, возьмите новый фактор, возведите в квадрат, умножьте на 1,5 и прибавьте к переменной». Через несколько месяцев экспериментов с разными подходами выясняется, что он был прав, только умножать надо, скажем, на 1,3.

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

Норвиг: Он прекрасно понимает код. Другие пишут лучше, но он сразу прикидывает все последствия изменений в коде.

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

Норвиг: Да, не исключено.

Сейбел: Итак, проверки у вас не такие формальные, как в НАСА. Что еще скажете о разнице между культурой «инженеров» и «хакеров», в лучшем смысле обоих слов?

Норвиг: Разница есть в организационной структуре и в отношении к ПО. Google начинался как компания, производящая ПО, и в те времена были наняты исполнительный директор — PhD компьютерных наук из Беркли, вице-президент по продажам — бывший компьютерный инженер, и так строилась вся фирма. А в НАСА все они специалисты по ракетам! Они мало соображают в программах, считая их необходимым злом. «Линейный код я еще понимаю, но вот циклы — это уже подозрительно. А если там еще и условие внутри цикла — о, это уже слишком далеко от того, что я могу решить через дифференциальное уравнение из теории управления!» Там все настроены очень недоверчиво.

Сейбел: Но так и нужно.

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

Дон Голдин пришел на административную работу в НАСА и сказал: «Лучше, быстрее, дешевле — вот что нам нужно. Запуски обходятся слишком дорого. Лучше делать больше запусков, пусть некоторые будут неудачными, но все равно мы сделаем больше за те же деньги». И поспорить было сложно. К сожалению, политически решение оказалось неверным. Потерять спутник — совсем не здорово, потому что люди запоминают только одно: НАСА потеряла спутник. Разницы между спутником за 100 миллионов и за 1 миллиард они не видят. Так что потерять десять стомиллионных спутников и один миллиардный — разные вещи. Поэтому решение оказалось не совсем верным.

Сейбел: Какова худшая ошибка из всех найденных вами?

Норвиг: С самыми большими ошибками (не моими) я имел дело, когда участвовал в чистке после программных сбоев на Марсе в 1998 году. Первый — из-за того, что вместо ньютонов были указаны футофунты. И второй — преждевременное отключение двигателей из-за сбоя программы, — мы так думали, но без полной уверенности.

Сейбел: Помню один из отчетов по Mars Climate Orbiter — как раз ту историю с футофунтами и ньютонами. Вы там были единственным специалистом по компьютерам. Вы тоже участвовали в разговоре с производителями ПО, выясняя проблему?

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

Сейбел: Это происходило уже во время полета?

Норвиг: Да. И даже во время полета была возможность выловить ошибку. Они знали, что не все в порядке, поэтому и послали письмо, но не отметили это в системе отслеживания ошибок. Если бы они это сделали, в НАСА очень хорошо налажено отслеживание ошибок, и все можно было бы исправить даже на поздней стадии. А вместо этого — неформальное письмо, которое так и осталось без ответа. В JPL считали, что в Lockheed-Martin решили проблему, а в Lockheed считали, что раз JPL больше не спрашивает, значит, волноваться не о чем.

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

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

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

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

Норвиг: Да, они заняли позицию стороннего наблюдателя.

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

Норвиг: Думаю, да. В вашем компьютере миллионы ошибок, но он тем не менее работает.

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

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

Сейбел: Более дешевые и производительные?

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

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

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

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

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

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

Сейбел: Вы делали что-нибудь специально, чтобы научиться на собственных ошибках?

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

Сейбел: Если выяснится, что чем меньше монитор, тем выше эффективность, вас возненавидят.

Норвиг: Верно. Если важна тишина, давайте ее добьемся, но если также важно взаимодействие между членами команды — как увязать одно с другим?

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

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

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

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

Норвиг: Да. Но тревожит то, что я знаю не все. Сегодня я программирую не так много и кое-что подзабыл. И столько нового! Обязательно надо переделать мой сайт и на клиентской стороне использовать JavaScript. Он должен быть на РНР или чем-то подобном, но я все не соберусь освоить их.

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

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

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

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

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

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

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

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

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

Сейбел: Вы говорили о том, как читали в «Scientific American» код программы для шашек. В книге «Как самому научиться программировать за десять лет» вы подчеркиваете важность чтения кода. Какой код вы еще читали, кроме кода Стрейчи?

Норвиг: Много кода Symbolics — он был под рукой, когда я работал в Беркли.

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

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

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

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

Сейбел: Вы читали книги с литературными программами Кнута?

Норвиг: Листал. Не скажу, что читал.

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

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

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

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

Сейбел: Потому что так удобнее?

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

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

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

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

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

Норвиг: До сих пор не знаем.

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

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

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

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

Сейбел: Как вы это определяете? Вы ведь ничего не знаете о тех, кого не позвали или кого не наняли.

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

Сейбел: Вы действительно заносите все это в базу данных?

Норвиг: Заносим. И при вопросе о приеме на работу смотрим, каковы показатели по резюме и собеседованию. Это не Библия, но это помогает принять решение — наряду с другими факторами.

Сейбел: Тем, кто проводит собеседование, эти данные сообщают заранее?

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

Мы ставим оценки от 1 до 4. И «единица» — это надежный показатель будущего успеха.

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

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

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

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

«Программирование со стороны пользователя», «программирование для каждого» — все это не имело успеха. Не уверен, что это так легко. В чем тут дело? В том, что одним это дано, а другим нет? Или в том, что мы не создали модель, — одну простую модель вместо множества индивидуальных попыток программирования?

Сейбел: Многие из тех, у кого я брал интервью для этой книги или по другому поводу, пришли к компьютерам, потому что это доставляло им удовольствие и потому что компьютеры, как им казалось, изменят мир. И сейчас некоторые из моих собеседников разочарованы тем, как мало в результате изменился мир. А вы как думаете?

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