Пейтон-Джонс: Программа для извлечения 24-значных квадратных корней и помещения их в 99 ячеек памяти - это еще для школьного компьютера.
Сейбел: И одна оставалась в запасе!
Пейтон-Джонс: Правильно. Что-то вроде метода Ньютона-Рафсона для квадратных корней. Я страшно гордился этим. Что же было потом? Потом, наверное, тот самый компилятор, который мы забросили, на BCPL. Мы многое с ним связывали и разрабатывали его детально. Системы типизации не было, так что у нас имелись только громадные листы распечаток с картинками, схемами и стрелками.
Сейбел: В BCPL не было системы типизации?
Пейтон-Джонс: Нет. Поэтому мы рисовали типы на больших листах бумаги и ставили стрелки. Это и была наша система типизации. Программа оказалась слишком большой для наших возможностей, мы ее так и не закончили.
Сейбел: Вы извлекли уроки из этой неудачи?
Пейтон-Джонс: Я впервые понял, что если пишешь очень большую программу, то она просто не умещается у тебя в голове. До того все, что я писал, целиком помещалось в голове без особых проблем. И вот тогда я сделал первую попытку создать долговременную документацию.
Сейбел: Но даже ее оказалось недостаточно?
Пейтон-Джонс: Ну, у нас были и другие заботы - надо было получать степень бакалавра. А компьютерами мы занимались по вечерам и ночью.
Сейбел: Что вам не нравится в том, как вы учились программированию?
Пейтон-Джонс: Никто меня этому не учил. Но не уверен, что это большой пробел. Самый большой пробел - то, что я на глубинном уровне так и не приобрел познаний в объектно-ориентированном программировании. Нет, я знаю, конечно, как писать объектно-ориентированные программы. Но делать это в большом масштабе - дело совсем другое. Если писать большие программы, использовать сложным образом разные иерархии классов, создавать фреймворки - вот тогда приходит глубинное понимание. Это не то же самое, что прочесть книгу.
Я считаю это пробелом, так как не могу авторитетно высказываться насчет того, что можно и чего нельзя делать в объектно-ориентированном программировании. Я всегда очень осторожен в своих высказываниях, особенно стараюсь не говорить отрицательно об императивном программировании - это невероятно сложная и богатая парадигма программирования. Но жизнь сложилась так, что мне ни разу не пришлось в течение нескольких лет писать большие программы на C++. Так приобретаются глубинные познания на уровне рефлексов, и у меня их нет.
Сейбел: Что было после Кембриджа?
Пейтон-Джонс: Я подумал: "Надо бы поработать с компьютерами". И я год занимался послеуниверситетской подготовкой по компьютерным наукам; это мое единственное официальное образование в компьютерной области.
Сейбел: Что-то вроде магистратуры?
Пейтон-Джонс: Что-то вроде магистратуры. То был очень полезный для меня год. Думаю, это примерно соответствовало сегодняшней степени бакалавра по компьютерным наукам, но было рассчитано на студентов, которые начинают с нуля.
Сейбел: Вы несколько лет провели в индустрии, прежде чем вернуться в науку. Чем вы занимались?
Пейтон-Джонс: Это была крошечная компания. Мы производили оборудование и программы для компьютеров, которые устанавливались в приборы измерения веса на ленточных транспортерах. Помню, я спроектировал штуку, наблюдавшую за ячейкой загрузки углепогрузочного транспортера. Она контролировала скорость ленты в зависимости от наполнения ячейки, чтобы соблюдать норму перемещения угля за единицу времени. Небольшая система, но оперировавшая в реальном времени; я использовал для нее PL/Z, слегка похожий на Алгол. Я писал программу на компьютере Z80 с операционной системой Chromix - урезанный UNIX, так сказать.
В компании обычно работало человек шесть, временами больше - до пятнадцати. Из-за ее крошечных размеров все было довольно ненадежно. Денег то было много, то совсем не было. После двух лет я решил, что предпринимательство не для меня. Это был мой главный опыт, если говорить о мелких компаниях; чтобы стать успешным предпринимателем, надо извлекать энергию из стрессовых финансовых ситуаций, а у меня в таких случаях энергия, наоборот, расходуется. Мой начальник был управляющим директором компании. Чем хуже шли дела, тем энергичнее он выглядел. Он бегал вокруг, порождал новые идеи насчет программ, трудился как пчела и был счастлив. Именно так и нужно себя вести, а если стресс высасывает из тебя энергию, то постоянно ходишь как вареный.
Я решил, что столько напряженной работы не для меня, стал искать работу и пошел преподавателем в Лондонский университетский колледж. У меня не было ни степени, ни опыта исследовательской работы. И декан факультета облегчил мне нагрузку, чтобы я мог заниматься исследовательской работой. Но у меня не было ни малейшего понятия насчет того, что делать. Я сидел в своем кабинете перед чистым листом бумаги и ждал Великих Идей. В полной тишине я обводил комнату взглядом в поисках Великих Идей. И все.
Джон Уошбрук, старший научный специалист факультета, взял меня под свое крыло и сказал кое-что очень важное. "Начни хоть с чего-нибудь, пусть даже мелкого", - сказал он. Это относилось не к программированию, а к исследованиям. Пусть тема будет мелкой, неоригинальной, маловажной - надо взять и написать статью. Я так и сделал. Совет Джона очень много значил для меня.
Я повторял его потом каждому аспиранту. Так и нужно начинать. Как только все завертелось, компьютерные науки превращаются в некий калейдоскоп - все интересно, потому что предмет развивается быстрее тебя. Это не какая-то неподвижная вещь, которую ты изучаешь, а то, что постоянно расширяется и приближается.
Сейбел: Итак, вы вернулись в науку, но степень так и не получили. Почему?
Пейтон-Джонс: Сейчас занять должность на факультете без степени было бы крайне трудно. Тогда - это был 1982, 1983 год - я подал заявку в Лондонский университетский колледж. Моя сестра изучала там компьютерные науки и сказала мне: "Там читают лекции по этой теме, почему бы тебе не пойти туда?" И меня, к моему удивлению, приняли. Видимо, тогда преподавателей не хватало, поэтому принимали каждого, кто хоть как-то зарекомендовал себя в этой области. Иначе как бы они наняли человека без степени?
После семи лет преподавания в колледже я начал задумываться о степени. Однако писать диссертацию - это так муторно! Выяснилось, что в Кембридже можно получить степень особым образом - представить опубликованную работу и, если повезет, станешь доктором. Я начал хлопотать об этом, но тут получил место профессора в Глазго. Теперь уже никому не было дела, есть у меня степень или нет, и я оставил эту мысль. У Робина Милнера ее тоже нет, так что я оказался в неплохой компании. На этом все и закончилось.
Сейбел: А в наши дни степень имеет значение? Кто-то говорил мне, что это зависит от призвания - если хочешь быть преподавателем, то она нужна, но если нет, то не имеет смысла. Применимо ли это к компьютерным наукам?
Пейтон-Джонс: Совершенно верно. Это необходимое, хотя и недостаточное условие, если делать исследовательскую карьеру в академических учреждениях или, например, в лабораториях Microsoft Research либо Google, то есть в научных центрах крупных компаний. Без степени вы застрянете на стартовой отметке.
Если же вы не намерены заниматься исследованиями, то прислушайтесь к внутреннему голосу. Если работаешь над чем-то с воодушевлением, продуктивность возрастает пятикратно. Если вам нравится что-то и вы хотите всерьез в этом копаться, написание диссертации - фантастическая возможность провести в Британии три года, а в Штатах еще больше, занимаясь исследованиями. Невероятная свобода, потому что в некотором роде паразитируешь на обществе. Если нет желания полностью посвящать себя науке, можно сесть за диссертацию просто потому, что пытлив и полон энтузиазма. Но, вообще говоря, странная это вещь - работать для себя и писать пухлую работу, которую не прочтет почти никто, - люди будут читать только ваши статьи. Это нестандартный способ заниматься исследованиями.
Получив степень, вы начинаете работать в сотрудничестве с другими людьми над более мелкими проблемами. По-моему, написание диссертации - странный способ подготовиться к дальнейшей карьере, даже исследовательской. Совсем странный в Британии, поскольку у вас очень мало времени. В Штатах, мне кажется, иначе - там можно плодотворно поработать с другими, пока не сосредоточишься на собственных исследованиях.
Сейбел: Раз уж речь зашла о науке, надо сказать, что функциональное программирование популярно среди исследователей, но остальные часто считают его слишком близким к математике и далеким от типичных программистских задач. Это верно?
Пейтон-Джонс: Наполовину. Для меня функциональное программирование - чисто функциональное программирование, где побочные эффекты выделены в свой собственный мир; это элегантный и дерзкий вызов всей индустрии создания программ. Дерзкий, поскольку знаменует собой разрыв с тем, что есть.
А что у нас есть сейчас? Есть крупные компании, которые тратят огромные деньги на экосистемы, редакторы, профилирование, инструменты, программистов, повышение квалификации и так далее. Те, кто делает погоду, мыслят сугубо практично. Ну, а элегантное и дерзкое функциональное программирование намного менее обеспечено такой инфраструктурной поддержкой. Но погоня за этой поддержкой не всегда оправданна. Ведь только пока кто-то занимается чем-нибудь элегантным и дерзким, вы можете изменять господствующую тенденцию в лучшую сторону. Но вы никогда не достигнете тех же высот, что они.
Поэтому, на мой взгляд, прелесть академических исследований в том, что ученые могут с головой уйти в свои безумные вещи без необходимости отвечать на вопросы о том, что это дает на практике. Что-то окажется потом фантастически важным, что-то не очень, но ничего предсказать заранее невозможно. Главное оправдание для людей вроде меня, которые занимаются чисто функциональным программированием, состоит в том, что с ним связаны большие надежды. Программисты не обязательно пойдут именно по этой дороге, но с функциональным программированием связаны большие надежды. Песчаник императивного программирования выветривается, и под ним обнаруживается гранит функционального программирования.
При этом чисто функциональное программирование первоначально было слишком эксцентричным и академичным, слишком тесно связанным с математикой. За последние 20 лет - те, что я с ним работаю, - оно становится все более ориентированным на практику, не обращаясь к абстрактным идеям, а пытаясь убрать одно за другим препятствия, мешающие реальным программистам использовать функциональные языки для создания приложений. Развитие Haskell может служить примером.
Хорошо, что есть люди, может быть, слегка непрактичные, которые идут впереди общей массы. Перспективы чисто функционального мира могут стать для этой общей массы путеводной звездой. Собственно, так и происходит. Многое в системах типизации и обобщенных типах изначально было разработано в контексте языков функционального программирования - они послужили своего рода лабораторией. Еще один пример: генераторы и "ленивые" потоки. В Python есть списковые выражения на синтаксическом уровне. Есть много индивидуальных находок. Если они переходят на текущий уровень программирования, то получают новые названия, слегка видоизменяются. Не хочу показаться великим поставщиком идей, но здесь действительно есть кое-что, нигде до того не реализованное. Так что это сослужило свою службу.
Сейбел: Какова, по-вашему, связь между исследованиями и собственно программированием?
Пейтон-Джонс: Они активно взаимодействуют. Моя область исследований - языки программирования. Для чего, в конце концов, они создаются? Чтобы легче было программировать. Язык - не что иное, как пользовательский интерфейс программы. Поэтому программирование и исследования в области языков тесно между собой связаны. У нас пока плохо получается наблюдать за программистами. Нужно проводить формальное изучение того, как программисты пишут программы, чтобы понимать, что они делают. Это очень затратно, и к тому же деятельность у программистов довольно нечеткая - результат не всегда выходит однозначный.
Культура сообществ вокруг языков программирования ориентирована на доказательство качества и полноты систем типов. Мы же стараемся ответить на более важный, но и более сложный вопрос - делают ли они людей более продуктивными? На него, однако, трудно дать убедительный ответ. Что будет эффективнее для выполнения одной и той же операции - функциональная или объектно-ориентированная программа? Даже если вы потратите кучу денег на серьезные эксперименты, сомневаюсь, что люди будут заинтересованы в их результатах.
Сейбел: А вы делали опыты хотя бы в небольшом масштабе? Вы работаете на Microsoft, у которой полно денег. Почему не посадить за одну и ту же задачу команду опытных Haskell-программистов и команду опытных С#-программистов? Ведь вам именно это нужно?
Пейтон-Джонс: Да, вы правы. Отчасти это вопрос денег. Но не только: это также вопрос времени и внимания. Для такого эксперимента нужна новая методология. Нужно повернуть по-другому свое сознание. Кроме того, со стороны кажется, будто у нас много денег, но стандартная картина для Microsoft - это одинокий исследователь за своим компьютером. Мы не можем просто так взять и потратить деньги на какой-нибудь проект. Если бы могли, было бы здорово. Ближе к переднему краю стоят лаборатории в Редмонде - там исследуются прототипы продуктов. Новые версии Visual Studio проходят там широкую проверку на потребительские свойства.
Сейбел: Вероятно, там больше занимаются взаимодействием с пользователями, чем языками программирования.
Пейтон-Джонс: Они также делают кое-что интересное в плане тестирования API. Стивен Кларк и его редмондские коллеги стараются регулярно наблюдать за программистами, получившими новый API, - о чем те говорят, что пытаются сделать. Проектировщики данного API сидят за стеклянной перегородкой и наблюдают.
Иногда эти проектировщики говорят программистам: "Нет-нет, не делайте так! Это неправильно!" Часто такие ситуации бывают очень поучительными. Потом API меняют там, где нужно. Честно говоря, в этом отношении исследования языков не столь продвинулись. Отчасти потому, что там нужно решать более сложные проблемы. Кроме того, в культурном смысле мы еще мало к этому адаптированы. Я считаю это нашей слабостью. И я не чувствую лично себя в состоянии предложить для этого решение.
Сейбел: Если исследователи выдвигают интересные идеи насчет улучшения процесса программирования, достаточно ли быстро они внедряются на практике?
Пейтон-Джонс: В кратчайшее время... Даже не знаю. Я часто разговариваю с людьми, которые занимаются производством продуктов, нужных покупателю, - покупатель готов платить за них. И многое из того, что заботит меня, лежит вообще вне поля их зрения.
Им надо сделать то, что потребитель готов оценить сегодня. У них просто нет времени заморачиваться с тем, что может работать в принципе или даже с тем, что может работать прямо сейчас, но пока еще не совсем доделано.
Тут есть небольшой разрыв - снова старая задача про курицу и яйцо. Порой идеи, развитые исследователями, требуют дополнительных инженерных усилий - не фундаментальных исследований, а приспособления к практическим нуждам.
Я не хотел бы утверждать, что компьютерные "практики" зомбированы и не желают внедрять хорошие идеи, которые могут облегчить им жизнь. То, что они делают, имеет под собой основания. Расстояние между прототипами и практически применимыми вещами часто бывает большим. Думаю, Microsoft здесь неплохо справляется. Microsoft Research позволяет сократить это расстояние и располагает кое-какими механизмами - инкубационными группами и так далее, - которые сближают исследователей и разработчиков ПО, позволяют пересечь разделяющую их границу. Поэтому я считаю, что MSR полезен настолько, насколько дает возможность преодолеть эту границу.
Если копнуть глубже, встают новые вопросы. Для разработчика-практика, имеющего дело с Java, дело не только в том, что функциональное программирование - принципиально иной подход. Дело еще и в способности программ к взаимодействию. Достаточно ли книг и библиотек? Способ программирования формирует вокруг себя целую экосистему - люди, навыки, библиотеки, операционные среды, инструменты и так далее.
Если таких камней преткновения довольно много, застреваешь. Мне кажется, различные элементы исследовательских подходов к языку живут в разных точках спектра. Некоторые довольно близки к тому, что уже есть. Вы можете сказать, что эта штука подключается прямо в фреймворк, не требует модификации Java, это инструмент статического анализа, позволяющий найти ошибки в коде. Ура! Такие вещи воспринимаются куда легче, чем "вот вам полностью новый способ программирования".
Если же говорить конкретно о функциональном программировании, то отношение к нему сильно изменилось в последнее время. Гораздо больше народа знают теперь, что это такое. Уже не приходится всякий раз объяснять, что такое Haskell. Некоторые говорят: "Я читал про него недавно на Slashdot, по-моему, это круто". Еще несколько лет назад такого не было.
Но что за этим реально кроется? Случайный всплеск интереса? Или просто все больше бывших студентов, узнавших в университете о функциональном программировании, занимают теперь менеджерские и руководящие должности? Возможно, и так. Но, может быть, причина в том, что с усложнением программных систем становится все важнее справляться с последствиями неконтролируемых побочных эффектов, иметь больше гарантий корректности и лучше использовать параллелизм. Думаю, стрелка на шкале "цена-качество" постепенно смещается.
Сейбел: А как вы сами начали заниматься функциональным программированием?
Пейтон-Джонс: Я ничего о нем не знал до последнего года в Кембридже, когда прослушал небольшой курс Артура Нормана. Норман был блестящим, слегка эксцентричным лектором. Он интересовался символической алгеброй, так что хорошо разбирался в Лиспе. На лекциях он объяснял нам, как составлять двунаправленные списки без каких-либо побочных эффектов. Отлично помню это, потому что впервые столкнулся с такой удивительной вещью - составляешь список, выделяешь ячейки и заполняешь их так, чтобы они указывали друг на друга. Кажется, будто нужно как-то использовать побочные эффекты.
Но он показал, как в чисто функциональном языке делать это без побочных эффектов. Я понял, что функциональное программирование, о котором я тогда знал очень мало, - это средство создания интересных программ, а не только безделушек.