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

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

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

Хорошо, что есть люди, может быть, слегка непрактичные, которые идут впереди общей массы. Перспективы чисто функционального мира могут стать для этой общей массы путеводной звездой. Собственно, так и происходит. Многое в системах типизации и обобщенных типах изначально было разработано в контексте языков функционального программирования - они послужили своего рода лабораторией. Еще один пример: генераторы и “ленивые” потоки. В Python есть списковые выражения на синтаксическом уровне. Есть много индивидуальных находок. Если они переходят на текущий уровень программирования, то получают новые названия, слегка видоизменяются. Не хочу показаться великим поставщиком идей, но здесь действительно есть кое-что, нигде до того не реализованное. Так что это сослужило свою службу.

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

Пейтон-Джонс: Они активно взаимодействуют. Моя область исследований - языки программирования. Для чего, в конце концов, они создаются? Чтобы легче было программировать. Язык - не что иное, как пользовательский интерфейс программы. Поэтому программирование и исследования в области языков тесно между собой связаны. У нас пока плохо получается наблюдать за программистами. Нужно проводить формальное изучение того, как программисты пишут программы, чтобы понимать, что они делают. Это очень затратно, и к тому же деятельность у программистов довольно нечеткая - результат не всегда выходит однозначный.

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

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

Пейтон-Джонс: Да, вы правы. Отчасти это вопрос денег. Но не только: это также вопрос времени и внимания. Для такого эксперимента нужна новая методология. Нужно повернуть по- другому свое сознание. Кроме того, со стороны кажется, будто у нас много денег, но стандартная картина для Microsoft - это одинокий исследователь за своим компьютером. Мы не можем просто так взять и потратить деньги на какой-нибудь проект. Если бы могли, было бы здорово. Ближе к переднему краю стоят лаборатории в Редмонде - там исследуются прототипы продуктов. Новые версии Visual Studio проходят там широкую проверку на потребительские свойства.

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

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

Иногда эти проектировщики говорят программистам: “Нет-нет, не делайте так! Это неправильно!” Часто такие ситуации бывают очень поучительными. Потом API меняют там, где нужно. Честно говоря, в этом отношении исследования языков не столь продвинулись. Отчасти потому, что там нужно решать более сложные проблемы. Кроме того, в культурном смысле мы еще мало к этому адаптированы. Я считаю это нашей слабостью. И я не чувствую лично себя в состоянии предложить для этого решение.

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

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

Им надо сделать то, что потребитель готов оценить сегодня. У них просто нет времени заморачиваться с тем, что может работать в принципе или даже с тем, что может работать прямо сейчас, но пока еще не совсем доделано.

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

Я не хотел бы утверждать, что компьютерные “практики” зомбированы и не желают внедрять хорошие идеи, которые могут облегчить им жизнь. То, что они делают, имеет под собой основания. Расстояние между прототипами и практически применимыми вещами часто бывает большим. Думаю, Microsoft здесь неплохо справляется. Microsoft Research позволяет сократить это расстояние и располагает кое-какими механизмами - инкубационными группами и так далее, - которые сближают исследователей и разработчиков ПО, позволяют пересечь разделяющую их границу. Поэтому я считаю, что MSR полезен настолько, насколько дает возможность преодолеть эту границу.

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

Если таких камней преткновения довольно много, застреваешь. Мне кажется, различные элементы исследовательских подходов к языку живут в разных точках спектра. Некоторые довольно близки к тому, что уже есть. Вы можете сказать, что эта штука подключается прямо в фреймворк, не требует модификации Java, это инструмент статического анализа, позволяющий найти ошибки в коде. Ура! Такие вещи воспринимаются куда легче, чем “вот вам полностью новый способ программирования”.

Если же говорить конкретно о функциональном программировании, то отношение к нему сильно изменилось в последнее время. Гораздо больше народа знают теперь, что это такое. Уже не приходится всякий раз объяснять, что такое Haskell. Некоторые говорят: “Я читал про него недавно на Slashdot, по- моему, это круто”. Еще несколько лет назад такого не было.

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