Интервью с Саймоном Пейтоном Джонсом

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

В этом интервью Саймон расскажет о себе, о работе в Microsoft Research, о своем взгляде на тенденции развития языков программирования вообще и Haskell в частности, о пользе езды на велосипеде и о своем отношении к Erlang.


Simon Peyton Jones is known as one of the key people in the creation of the Haskell language, the architect and main developer of the GHC compiler. He is also an editor of the Haskell Report, the language’s formal definition. Besides, Simon gave the language its unofficial motto: “avoid success at all costs”.

In this interview Simon will speak about himself, about his work at Microsoft Research, about his views on the trends in the development of programming languages and Haskell in particular, about the usefulness of biking and about his attitude to Erlang.


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

Саймон:  Отношение компании Microsoft к исследовательской деятельности достаточно зрелое. Если вы хотите организовать исследовательскую лабораторию, можно, конечно, попытаться предугадать, какие направления исследований окажутся прибыльными, и вкладываться в них. Но выбрать таким образом удачное направление очень сложно. Как знать, что окажется полезным, а что нет? Поэтому Microsoft использует более обширный подход. Отношение компании к исследованиям можно примерно описать так: мы наймём лучших исследователей и фактически предоставим им свободу делать то, что получается у них лучше всего. Прямо скажем, Microsoft демонстрирует определённую смелость, беря на себя риск и финансируя группу людей, чья работа не имеет прямого отношения к продукции компании, но может оказаться крайне важной в дальнейшем. На мой взгляд, так было в компании Bell Labs. Они финансировали работу, не ориентированную непосредственно на развитие продуктов компании и при этом получившую многочисленные Нобелевские премии, провели много успешных фундаментальных исследований, результаты которых находят применение много лет спустя. Я считаю, это замечательно, что компания Microsoft готова финансировать не только исследования, направленные на развитие продуктов, но и такие, которые расширяют границы наших знаний. И кстати, это даже закреплено в формулировке миссии Microsoft Research. По-моему, она состоит из трёх частей. Первая — расширение границ знаний; буквально так. Вторая — внедрение технологий в продукты компании и третья — формирование своего рода резерва экспертных знаний, которые могут понадобиться компании в коммерческих целях, если возникнет необходимость совершать резкие скачки в направлении деятельности. Деятельность Microsoft Research в целом соответствует этой миссии на протяжении уже двадцати лет своего существования. Microsoft делает очень полезное дело. Меня это, конечно, весьма радует.


—  Говоря о практическом применении исследований, связанных с Haskell, как Вы можете прокомментировать неудачную, в конечном итоге, попытку внедрения Software Transactional Memory в C#?

Саймон:  Я не участвовал в принятии решения о невнедрении. В моём понимании, рантайм .NET — большой и сложный зверь. Чтобы добавить транзакционную память, они пытались решить задачи гораздо сложнее тех, с которыми столкнулись мы в Haskell STM, где побочные эффекты являются не правилом, а исключением. Они работали с рантаймом, для которого побочные эффекты не являются исключением. И поскольку побочные эффекты должны отслеживаться системой транзакционной памяти и такое отслеживание является дорогой операцией, их исходная позиция была менее выгодна. Они собирались внедрить и многие другие сложные сущности, такие как открытые вложенные транзакции, а также модификацию адресов памяти как внутри транзакции, так и снаружи. В Haskell STM переменные делятся на два класса. Переменные класса TVar могут быть изменены внутри транзакции, но не снаружи. Переменные класса IORef могут изменяться снаружи, но не внутри. Подобное разделение значительно облегчает управление состояниями. Разработчики, которые делали CLR STM, довольно глубоко об этом задумывались, на мой взгляд. Они решили, что, мол, вы знаете, наверное хочется создать структуру, часто в единственном потоке, а затем «раздать» её другим. Пока эта структура создаётся, вы не всегда хотите, чтобы она строилась исключительно внутри какой-то транзакции. Разработчики хотели иметь возможность модифицировать состояние внутри и снаружи транзакций. Но это приводит к большому количеству трудностей, гораздо большему, чем я ожидал. Почитайте статью Тима Харриса (Tim Harris) об этом. Короче говоря, они столкнулись с гораздо более широкой задачей, чем мы, разработчики Haskell STM. Остаётся только гадать, получили бы они куда более дешёвое решение, как в плане времени исполнения, так и в плане сложности реализации, возьмись они за более узкую задачу. Тогда, будь они менее амбициозны, возможно, всё это закончилось бы работоспособным прототипом, а не таким, который, похоже, оказался слишком тяжёл.


—  Ограничение спектра возможностей некоторым безопасным документированным набором могло бы обеспечить STM безопасное отступление. Это могло бы…

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


—  Да, какими видами спорта Вы занимаетесь и чем увлекаетесь?

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


—  Что в Вашем образе жизни Вы считаете особенно полезным?

Саймон:  Из приближённого к спорту — я много езжу на велосипеде. Я езжу по всему Кембриджу и провожу на велосипеде много времени. Я не склонен к продолжительным двадцатимильным загородным поездкам, вместо этого я просто езжу из пункта А в пункт Б. Это мой способ перемещения.

Что ещё помогает мне в моих исследованиях?.. Я придаю большое значение сотрудничеству. Мне непросто заниматься исследованиями в одиночку, поэтому я всё время сотрудничаю с людьми. Практически каждая моя статья написана в соавторстве. Я не знаю, можно ли это считать образом жизни, но для меня исследования — это социальная, а не индивидуальная деятельность.


—  Следующая тема будет близка сердцам многих российских исследователей, испытывающих трудности с финансами. Один из первых вопросов, которые они задают: каково финансовое положение исследователей в Microsoft?

Саймон:  В отличие от представителей академической среды, исследователи получают хорошее индивидуальное финансирование. Исследователи в университетах вынуждены подавать заявки на гранты. У них есть с полдюжины студентов-исследователей и несколько ассистентов, таким образом, они фактически получают внешнее финансирование на построение команды. В Microsoft этого меньше, если, конечно, вы не делаете что-то, непосредственно связанное с продуктами компании (в этом случае компания оплачивает работу тех, кто будет помогать с разработкой программного обеспечения). В каком-то смысле моя ситуация в проекте GHC (Glasgow Haskell Compiler) исключительна — Microsoft выдаёт мне некоторую сумму денег на поддержку проекта. Поддержка первого уровня обеспечивается консультантами на контрактах, что довольно нетипично. Что я хочу сказать: команды, как правило, малочисленны, если, конечно, исследователи не соберутся вместе большой компанией и не решат, что они хотят делать что-то большое. Компании нравятся амбициозные внутренние проекты. Если вы придёте и скажете: «нам очень хочется сделать вот эту сказочную штуку в средний срок; нас несколько человек и для выполнения задачи нам нужны вот такие дополнительные ресурсы», то для обсуждения подобных вещей существуют свои механизмы.


—  Как Вы думаете, существуют ли декларативный и императивный способы мышления? Считаете ли Вы, что естественное мышление человека принадлежит к той или иной категории?

Саймон:  Я всегда с подозрением отношусь к фразе «это естественно». Обычно люди говорят, что что-то является естественным, потому что оно естественно для них. Совсем необязательно это будет естественным для кого-то ещё. Я вполне могу сказать, что декларативное мышление и мышление чисто функциональное, или даже преимущественно функциональное, заставляет вас применять иной подход к задачам. Чтобы писать поистине функциональные, а не императивные программы, действительно необходимо в некоторой степени перестроить мозги. И не слегка. Это очень существенная перестройка. Я не хочу сказать этим, что какой-то из способов мышления более естественен, чем другой. Главным двигателем моей исследовательской программы и причиной, по которой я считаю, что компании Microsoft полезно финансировать мои исследования и в частности Haskell, является то, что цена, которую приходится платить за неограниченные побочные эффекты, присутствующие в широко распространенной императивной модели, становится всё выше по мере того, как мы создаём всё более грандиозные программные продукты, от которых мы хотим корректности, а также параллелизма. Наблюдаемая повсюду ничем не ограниченная масса побочных эффектов на деле обходится нам всё дороже. Функциональный подход всё более оправдывает себя. Мне не важно, естественно это или нет. Суть в том, что его ценность непрерывно растёт. Я не знаю, все ли начнут использовать Haskell через 10 или 20 лет. Но я уверен, что те языки, которые будут популярны через 10 или 20 лет, так или иначе будут иметь механизмы контроля, управления и отделения побочных эффектов. Как бы то ни было, если вы хотите контролировать побочные эффекты, за идеями следует обращаться к сообществу чистых функциональщиков. Я отношусь к Haskell как к своеобразной лаборатории для развития подобных идей. Вне зависимости от того, используется ли именно Haskell, идеи остаются прежними и могут применяться в другом обличье. Не только в рамках того, что носит название H-A-S-K-E и двойное L.


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

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

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


—  В чем слабые места Haskell?

Саймон:  Он сложный. Пожалуй, это его самое слабое место. Думаю, в каком-то смысле он таким и задуман. В GHC я хотел реализовать множество фич и посмотреть, как они будут сочетаться и какие понравятся людям. Но в результате, несомненно, получился сложный язык. В некоторых отношениях Haskell прост. Он остался верен своим принципам — чистому функциональному программированию и ленивой стратегии вычислений. Но нынешняя система типов очень сложна. Думаю, самое сложное в Haskell — это то, что это очень большой язык. Надеюсь, однажды кто-нибудь выделит из Haskell лучшие части и соберет из них что-то поменьше. Не знаю, что из этого может выйти. Мы понемногу пытаемся его упрощать, убираем некоторые возможности. В стандарте Haskell 2010 отсутствуют n+k-шаблоны, потому что они в целом довольно избыточны. Мне нравится GHC как платформа для исследований — у него открытый исходный код. Кто угодно может внести изменения. Если у вас есть идея для системы типов или оптимизатора, можете реализовать ее и посмотреть, что получится. Но все же, несмотря на мои попытки переписывания и упрощения, это по-прежнему огромный программный продукт. Многих людей это отталкивает. Мне нравится, например, что есть Jhc — намного более компактная и существенно отличающаяся от GHC реализация, над которой работает Джон Мичэм (John Meacham). Думаю, одна из проблем Haskell с точки зрения практиков состоит в том, что для его использования приходится мыслить иначе. У Haskell особый подход к программированию. Если он вам незнаком, то изучить его с нуля довольно трудно. Если посмотреть на использование Haskell в индустрии, то выяснится: многие используют его едва ли не тайком. Это не начальник сказал им — «мы будем использовать Haskell, изучите его». Мы изучили Haskell. Мы считаем, что это круто. Мы будем использовать его как бы втихаря. Их начальник не хочет использовать его для чего-то существенного, так как задается вопросами, удастся ли нанять программистов на Haskell и как обучить ему остальных программистов. Здесь проблема курицы и яйца. Думаю, это общая проблема всех новых языков. Какие еще слабости? Что скажете?


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

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


—  Да, действительно.

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


—  Кстати о внимании, Вы действительно это заметили? Я заметил, что в районе 2005 и 2006 годов произошел огромный скачок интереса к функциональным языкам вообще и к Haskell в частности.

Саймон:  Я обычно рисую график популярности Haskell медленно вырастающим до нескольких тысяч пользователей в течение первых 15 лет его существования. А затем в последние пять лет, примерно с 2005 года, интерес очень резко повысился. Трудно сказать, почему именно. Цикл жизни этого языка необычен. Обычно язык либо приобретает популярность довольно быстро, как Perl, Clojure, Ruby, Python или С++, либо не приобретает популярность вообще. Haskell далек от этой тенденции: резкий рост интереса через 15 лет после создания языка очень необычен.


—  Что Вы думаете о JIT-компиляции; Вы занимались какими-нибудь исследованиями о компромиссе между статическими оптимизациями в GHC и динамическими, в стиле JIT?

Саймон:  В общем-то нет — я вообще не занимался такими исследованиями. Когда появилась идея JIT-компиляции, она преподносилась как механизм дистрибуции. Можно было передавать JIT-код через всю планету, и он был бы переносимым. Можно было компилировать его на лету. Умные JIT-компиляторы (а они действительно очень умные) используют, скажем так, информацию о поведении программы в динамике. Часто вызываемые методы компилируются более тщательно или специализируются в конкретном контексте вызова. Это намного труднее в случае статической компиляции, когда неизвестно, какие методы будут вызываться часто. Во время выполнения можно выяснить эти методы. Честно говоря, не знаю, занимался ли кто-либо такими оптимизациями для функциональных программ. Было бы довольно интересно попробовать. Думаю, в каком-то смысле это сделано в языках вроде Scala или F#, поскольку они компилируются в виртуальных машинах с помощью их мощных JIT-компиляторов и динамических оптимизаторов. Эти языки могут выиграть от такого подхода. Мои же исследования посвящены оптимизации кода на той стадии, пока он еще представляет собой функциональную программу и не превращен в последовательность машинных инструкций. Думаю, когда в вашем распоряжении есть больше информации, чем просто тело метода, можно сделать намного больше.


—  Если уж на то пошло, как Вам кажется, трудно ли будет применить этот подход к оптимизации Haskell, или большой разницы нет? У нас есть пример — F#. Haskell — особый случай?

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


—  Насколько я понимаю, две активных области исследований сейчас — Data Parallel Haskell и суперкомпиляция.

Саймон:  Я только что вернулся из России, с конференции Meta 2010, которая была во многом посвящена суперкомпиляции. Сейчас эта тема меня особенно интересует. Эта технология компиляции существует уже давно. Ее создал русский ученый, Валентин Турчин. Он выразил ее в терминах своего языка РЕФАЛ, о котором больше никому не было известно. Лишь позднее Роберт Глюк (Robert Glück) и его студент Мортен Соренсен (Morten Sørensen) объяснили суперкомпиляцию более понятно для остальных. Но и это было достаточно давно. Я недоумевал, почему никто не применяет суперкомпиляцию для построения настоящих оптимизирующих компиляторов? Теперь я кое-что понимаю! На первый взгляд кажется, что эту технологию можно просто реализовать по статье, но на самом деле там много «ручек». Нужно принять много архитектурных решений. И неочевидно, какие именно решения надо принять.

Вместе с Максом Болингброком (Max Bolingbroke) — аспирантом, с которым я работаю — мы построили довольно интересный модульный суперкомпилятор. Если посмотреть, как устроен суперкомпилятор, то видно, что он состоит из нескольких частей, слепленных в один запутанный клубок. Когда я попытался по-настоящему понять, как работают суперкомпиляторы, это оказалось очень трудно. Было очень трудно понять статьи. Я читал их одну за другой. Я говорил себе, «Кажется, теперь понятно», но потом осознавал, что на самом деле ничего не понятно. Кажется, теперь мы придумали, как разбить эти задачи на несколько задач поменьше. И как в том же духе разбить суперкомпилятор, сделав его более модульным. Теперь исследование различных архитектурных решений выглядит более реалистичным. Я очень рад этому. Кажется, мы начинаем понимать, как можно применить суперкомпиляцию на практике в настоящем компиляторе. Я очень надеюсь сделать оптимизатор GHC суперкомпилятором. Посмотрим, что из этого выйдет. Макс работает над этим в рамках своей докторской.

Для меня было большой честью быть приглашенным на Meta 2010 и встретиться с такими людьми, как Сергей Романенко, сыгравшими важную роль в развитии суперкомпиляции.


—  Еще один вопрос. У Вас есть какая-то безумная научная идея, в осуществимость которой никто не верит, а Вы — верите и пытаетесь осуществить?

Саймон:  В общем, можно просто сказать «чистое функциональное программирование». Это не только моя идея. Эту безумную идею разделяют еще сотни людей. Но сообщество программистов в целом пока в нее не верит. Если же говорить более конкретно — я думаю, идея вложенного параллелизма (nested data parallelism) выглядит интересно и многообещающе. Я до сих пор не знаю, можно ли по-настоящему заставить это работать. Вот почему это интереснейшая область для исследований. На самом деле я имею в виду не только параллелизм по данным. Это идея Гая Блеллоха (Guy Blelloch), над которой работали Мануэль Чакраварти (Manuel Chakravarty), Роман Лещинский (Roman Leshchinskiy), Габриэль Келлер (Gabriele Keller) и я. Получить выигрыш в производительности оказалось труднее, чем мы думали. Это очень гибкая парадигма программирования. Если у нас действительно получится реализовать преобразование из программ с «вложенным» параллелизмом в «плоский» без сильного замедления, это было бы просто потрясающе. Не уверен, что можно сказать, что никто не верит в осуществимость этого. Скорее всего, для 99.99% мейнстрима это так — они просто никогда об этом не слышали. Это для них за горизонтом. Но мне все равно кажется, что это достойная цель.


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

Саймон:  Сейчас в области функционального программирования я усиленно работаю над повышением выразительности системы типов. Типизация — самый успешный, притом с большим отрывом, из формальных методов в программировании. Тип — это нечто вроде слабой спецификации функции. Программисты все время пишут типы, а компиляторы при каждой компиляции их проверяют. Этот формальный метод очень активно используется. По мере того, как системы типов становятся более выразительными, выясняется, что солидная часть работы на начальном этапе проектирования программы — придумывание и записывание типов. Люди иногда спрашивают, «Что служит аналогом UML для Haskell?» Когда меня впервые спросили об этом 10 лет назад, я подумал, «Ума не приложу. Может быть, нам стоит придумать свой UML». Сейчас я думаю, «Это просто типы!» Люди рисуют UML-диаграммы, чтобы понять общую схему программы. Именно этим занимаются программисты на функциональных языках и на Haskell, когда придумывают сигнатуры типов для модулей и функций в этих модулях.

Одно из интересных направлений развития этого явно успешного метода — инструмента, которым программисты пользуются каждый день — повышение его выразительности, чтобы типы были более «говорящими», а спецификации — более богатыми. Тогда станет можно доказывать более интересные свойства программ. Эта тенденция существует, и, я думаю, будет продолжаться, по крайней мере в мире функционального программирования. В области типизации функциональное программирование далеко ушло от императивного. В мире функциональных языков с типизацией происходит множество интересных вещей, вовсе не заметных, к примеру, в Java. Scala, например, впитала в себя многое из функционального программирования. Вероятно, этот язык лидирует по сложности системы типов среди императивных языков. Мне кажется, стоит следить за системами типов.


—  Что из Ваших творений вызывает у Вас наибольшую гордость, если оставить в стороне Haskell, или, возможно, даже исследовательскую деятельность вообще?

Саймон:  Сейчас я много времени уделяю так называемой рабочей группе «Computing at School» В британских школах студентам преподают предмет под названием ICT, «Информационные и коммуникационные технологии». Он ужасно скучный. Мы берем самую интересную в мире тему, информатику, и заставляем детей поверить, что она очень скучная. Что они узнают из ICT? Они узнают об электронных таблицах, базах данных, PowerPoint и Word. Они изучают Microsoft Office, и не один раз. Это все делается с добрыми намерениями, поскольку это все-таки полезные умения. Но они вообще не занимаются настоящими вычислениями. Они вообще не имеют дела с настоящей информатикой. Я принимаю активное участие в рабочей группе, которая пытается исправить ситуацию, по крайней мере в Великобритании. В США есть так называемая «Ассоциация Преподавателей Информатики», CSTA. В США она играет похожую роль. Я горд, что рабочая группа по преподаванию информатики выросла от идеи до 300–400 человек за пару лет. Кажется, к ней начинают всерьез прислушиваться.


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

Этот документ был получен из LATEX при помощи HEVEA