На практике нам приходится разбивать задачи на кусочки. За каждый кусочек отвечает человек, который исходит из собственного опыта и культурного багажа. То, что он создает на своем пространстве, хуже, чем могло бы быть, - человеку не хватает времени. В итоге весь ансамбль тоже выглядит хуже, чем мог бы. Плюс отрицательное влияние наследства прежних систем.
Это наследство - как ядро каторжника, которое мы волочим за собой. И в этом отношении удачей стал Haskell. Оглядываясь, я всегда вижу перед собой принцип, который мы в него заложили: "Избегать успеха любой ценой". Теперь это что-то вроде мема - люди запомнили эту фразу и мне же ее цитируют.
В этом есть доля правды - именно потому, что мы не хотели быть слишком успешными и слишком поспешными, у нас было какое-то время, чтобы изменять Haskell на протяжении его жизни. Я даже переживаю из-за того, что Haskell стал более успешным, - мне приходит больше сообщений об ошибках, больше запросов новых функций. Все больше людей говорят: "Прошу вас, не ломайте мою программу". Раньше такого не было.
Сейбел: Вы несколько раз упоминали о красоте кода. Каковы признаки красивого кода?
Пейтон-Джонс: Тони Хоар замечательно сказал: нужен код, совершенно очевидно свободный от ошибок, а не код, свободный от очевидных ошибок. Думаю, красивый код - это код, который совершенно очевидно правилен. Абсолютно прозрачный код.
Сейбел: А как насчет перлов - небольших замысловатых, но интересных фрагментов кода, - они тоже красивы?
Пейтон-Джонс: Иногда что-то правильно, но этого не понять без умственных усилий. Иногда нужно предварительное знание. Если взглянуть на код для АВЛ-дерева, не зная, в чем его смысл, не понятно, зачем нужны все эти вращения. Но если вы знаете, какой инвариант тут поддерживается, то видите: ага, если поддерживается этот инвариант, мы получаем логарифмическое время поиска. Вы смотрите на каждую строку кода и понимаете, что здесь поддерживается инвариант. Инвариант дает нам предварительное знание и позволяет судить о том, что код совершенно очевидно правилен.
Я полностью согласен с тем, что простого изучения кода может быть недостаточно. Если вы смотрите на код и видите, что он правилен, это еще не характеристика красивого кода. Возможно, кто-то должен объяснить, почему код правилен. Но после этого, поняв, что тут делается, выработав свою точку зрения, вы говорите: да, это на самом деле правильно.
Сейбел: Есть ли верхняя граница, если говорить о размере, вплоть до которой код все еще может считаться красивым?
Пейтон-Джонс: Не знаю, связано ли это с размером. Знание, необходимое, чтобы убедить себя, что он правильный, направлено в сторону большей уверенности в его коррекности. В очень больших программах всегда есть недочеты или даже несомненные ошибки. Но ликвидировать их сразу же бывает нецелесообразно. Это справедливо в отношении GHC и еще более - в отношении программ Microsoft.
Однако все эти большие программы управляемы - в них есть инварианты, есть общие спецификации, указывающие, как должна работать программа и что в ней должно быть верно. Возьмем опять для примера GHC, в котором есть такой инвариант: все промежуточные программы должны быть хорошо типизированы. При желании это можно проверить и во время работы программы. Мощный инвариант, позволяющий отследить, что происходит с программой. Вот поэтому я не уверен, что дело в размере.
Конечно, внутренние связи в итоге приводят к тому, что большая программа рушится под собственным весом. Иногда в исследовательской работе есть еще и то преимущество, что можно переписать кусок кода на основе своего обогащенного знания о том, какова цель программы и как ее достичь. Мы говорили о рефакторинге бэкенда GHC. Будь я сильнее связан коммерческими соображениями, я бы не смог позволить его себе. Надеюсь, благодаря этому GHC в долгосрочном плане станет легче для понимания и обслуживания.
Есть ли верхняя граница, если говорить о размере? Не знаю. Но мне кажется, что продолжая создавать хорошие абстракции, можно строить мосты через Атлантику. У нас есть программы, которые работают, - пусть не идеально, но на удивление хорошо, учитывая их размер.
Сейбел: Вопрос в том, можно ли построить здание - большое, приспособленное для проживания и красивое одновременно.
Пейтон-Джонс: С красотой будет непросто. Код часто бывает красивым или, по крайней мере, не уродливым, сразу после рождения. Но это свойство трудно сохранить в течение всей его жизни, то есть при поддержке. Долгоживущие программы плохи тем, что постепенно становятся уродливыми. Не то чтобы безобразными - но негодными, бесполезными.
Сейбел: И единственный выход - признать, что программа отжила свое, и начать делать новую?
Пейтон-Джонс: Надо переработать какие-то ее куски. Если не можешь позволить себе переработку в то время, как программа разошлась и используется, то не исключено, что лет через десять придется ее выкинуть и задуматься о новой. А если можешь, если программа обновляется так, как самообновляются клетки нашего тела, получается то, что, надеюсь, происходит с GHC.
Самый угнетающий момент в жизни программиста - когда сталкиваешься с чужим кодом или, что еще хуже, со своим и не находишь сил его переделать. Это угнетает.
8. Питер Норвиг
Питер Норвиг - теоретик широкого профиля и хакер в душе. В свое время он написал программу для нахождения в истории поиска 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. Мне пришлось править грамматику, роясь в таблицах, и я решил: если вот здесь у нас переход в новое состояние, я создам свое состояние, и переход будет к нему.
Сейбел: Это было правильное решение? Вы не думали о том, чтобы просто написать новый парсер?
Норвиг: Наверное, так и надо было поступить. Но ведь я сделал лишь одну небольшую правку.
Сейбел: А не получилось так, что им каждые три недели приходилось сталкиваться с очередным изменением в грамматике?
Норвиг: Я тогда уже ушел в магистратуру, и это уже была не моя проблема.
Сейбел: Уже не ваша... Итак, вы защитили диссертацию. Вы бы хотели, чтобы ваше обучение программированию шло по-другому?
Норвиг: В конце концов я занялся промышленной разработкой ПО. Возможно, стоило заняться этим раньше. Постепенно я всему научился, но много времени провел в колледже и магистратуре. Правда, мне нравилось, так что ни о чем не жалею.
Сейбел: А чему вам пришлось учиться, если говорить о промышленной разработке ПО?
Норвиг: Планировать работу и делать так, чтобы довольны были все - разработчики, клиенты, менеджеры. В магистратуре ведь все это не нужно - просто приходи к своему руководителю время от времени.
Важнейший шаг - переход от индивидуальной работы к командной: начинаешь понимать, как люди взаимодействуют друг с другом. Этому тоже не учат в колледже. Сейчас в некоторых колледжах обратили на это внимание, но в мои времена к командной работе относились плохо - считали ее жульничеством.
Сейбел: Какие навыки, кроме умения писать код, нужны тем, кто приходит в индустрию ПО?
Норвиг: Надо уметь уживаться с другими. Уметь понимать заказчика: знать, что именно ты создаешь и правильным ли путем идешь. Уметь взаимодействовать с клиентами и со своими коллегами. Уметь взаимодействовать с клиентом и своим начальством в одно и то же время. Это все разные социальные отношения, требующие разных навыков.
Сейбел: Программирование стало более социальным?
Норвиг: Думаю, да. Компьютерщики были больше обособлены от всех остальных. Раньше в основном шла пакетная обработка, интерфейсы были куда проще. Можно было работать по модели "водопада": ввод - колода карт, вывод - отчет с таким-то номером в такой-то колонке.
Возможно, это была не лучшая модель для спецификаций, и с самого начала нужно было теснее взаимодействовать с клиентом. Но так сохранялась обособленность. Сейчас все намного подвижнее, больше взаимодействия, и лучше не составлять полную спецификацию в начале, а сесть вместе с клиентом и устроить мозговой штурм.
Сейбел: А были особенно памятные случаи, которые подчеркивают разницу между одиночной и командной работой?
Норвиг: Особенно памятных, пожалуй, не было. Просто пришло осознание того, что я не могу сделать все сам. Программирование - это в немалой степени способность держать в голове столько, сколько можешь, но это работает только до какого-то предела. По крайней мере, у меня это так. А потом надо полагаться на других, чтобы получить хорошие абстракции и использовать то, что у них есть. Теперь я все чаще думаю в терминах "Вероятно, это уже сделано. И как?", а не "Я знаю, как это сделано, потому что сам это сделал". По идее, вот так - а если не так, надо понять почему и научиться это использовать.
Сейбел: Освоение командного подхода позволяет самому браться за вещи большего размера, чем раньше? Вы как бы сам себе команда, только растянутая во времени?