Кодеры за работой. Размышления о ремесле программиста
Шрифт:
При этом чисто функциональное программирование первоначально было слишком эксцентричным и академичным, слишком тесно связанным с математикой. За последние 20 лет — те, что я с ним работаю, — оно становится все более ориентированным на практику, не обращаясь к абстрактным идеям, а пытаясь убрать одно за другим препятствия, мешающие реальным программистам использовать функциональные языки для создания приложений. Развитие Haskell может служить примером.
Хорошо, что есть люди, может быть, слегка непрактичные, которые идут впереди общей массы. Перспективы чисто функционального мира могут стать для этой общей массы путеводной звездой. Собственно, так и происходит. Многое в системах типизации и обобщенных типах изначально было разработано в контексте
Сейбел: Какова, по-вашему, связь между исследованиями и собственно программированием?
Пейтон-Джонс: Они активно взаимодействуют. Моя область исследований — языки программирования. Для чего, в конце концов, они создаются? Чтобы легче было программировать. Язык — не что иное, как пользовательский интерфейс программы. Поэтому программирование и исследования в области языков тесно между собой связаны. У нас пока плохо получается наблюдать за программистами. Нужно проводить формальное изучение того, как программисты пишут программы, чтобы понимать, что они делают. Это очень затратно, и к тому же деятельность у программистов довольно нечеткая — результат не всегда выходит однозначный.
Культура сообществ вокруг языков программирования ориентирована на доказательство качества и полноты систем типов. Мы же стараемся ответить на более важный, но и более сложный вопрос — делают ли они людей более продуктивными? На него, однако, трудно дать убедительный ответ. Что будет эффективнее для выполнения одной и той же операции — функциональная или объектно-ориентированная программа? Даже если вы потратите кучу денег на серьезные эксперименты, сомневаюсь, что люди будут заинтересованы в их результатах.
Сейбел: А вы делали опыты хотя бы в небольшом масштабе? Вы работаете на Microsoft, у которой полно денег. Почему не посадить за одну и ту же задачу команду опытных Haskell-программистов и команду опытных С#-программистов? Ведь вам именно это нужно?
Пейтон-Джонс: Да, вы правы. Отчасти это вопрос денег. Но не только: это также вопрос времени и внимания. Для такого эксперимента нужна новая методология. Нужно повернуть по-другому свое сознание. Кроме того, со стороны кажется, будто у нас много денег, но стандартная картина для Microsoft — это одинокий исследователь за своим компьютером. Мы не можем просто так взять и потратить деньги на какой-нибудь проект. Если бы могли, было бы здорово. Ближе к переднему краю стоят лаборатории в Редмонде — там исследуются прототипы продуктов. Новые версии Visual Studio проходят там широкую проверку на потребительские свойства.
Сейбел: Вероятно, там больше занимаются взаимодействием с пользователями, чем языками программирования.
Пейтон-Джонс: Они также делают кое-что интересное в плане тестирования API. Стивен Кларк и его редмондские коллеги стараются регулярно наблюдать за программистами, получившими новый API, — о чем те говорят, что пытаются сделать. Проектировщики данного API сидят за стеклянной перегородкой и наблюдают.
Иногда эти проектировщики говорят программистам: «Нет-нет, не делайте так! Это неправильно!» Часто такие ситуации бывают очень поучительными. Потом API меняют там, где нужно. Честно говоря, в этом отношении исследования языков не столь продвинулись. Отчасти потому, что там нужно решать более сложные проблемы. Кроме того, в культурном смысле мы еще мало к этому адаптированы. Я считаю это нашей слабостью. И я не чувствую лично себя в состоянии предложить для этого решение.
Сейбел:
Пейтон-Джонс: В кратчайшее время... Даже не знаю. Я часто разговариваю с людьми, которые занимаются производством продуктов, нужных покупателю, — покупатель готов платить за них. И многое из того, что заботит меня, лежит вообще вне поля их зрения.
Им надо сделать то, что потребитель готов оценить сегодня. У них просто нет времени заморачиваться с тем, что может работать в принципе или даже с тем, что может работать прямо сейчас, но пока еще не совсем доделано.
Тут есть небольшой разрыв — снова старая задача про курицу и яйцо. Порой идеи, развитые исследователями, требуют дополнительных инженерных усилий — не фундаментальных исследований, а приспособления к практическим нуждам.
Я не хотел бы утверждать, что компьютерные «практики» зомбированы и не желают внедрять хорошие идеи, которые могут облегчить им жизнь. То, что они делают, имеет под собой основания. Расстояние между прототипами и практически применимыми вещами часто бывает большим. Думаю, Microsoft здесь неплохо справляется. Microsoft Research позволяет сократить это расстояние и располагает кое-какими механизмами — инкубационными группами и так далее, — которые сближают исследователей и разработчиков ПО, позволяют пересечь разделяющую их границу. Поэтому я считаю, что MSR полезен настолько, насколько дает возможность преодолеть эту границу.
Если копнуть глубже, встают новые вопросы. Для разработчика-практика, имеющего дело с Java, дело не только в том, что функциональное программирование — принципиально иной подход. Дело еще и в способности программ к взаимодействию. Достаточно ли книг и библиотек? Способ программирования формирует вокруг себя целую экосистему — люди, навыки, библиотеки, операционные среды, инструменты и так далее.
Если таких камней преткновения довольно много, застреваешь. Мне кажется, различные элементы исследовательских подходов к языку живут в разных точках спектра. Некоторые довольно близки к тому, что уже есть. Вы можете сказать, что эта штука подключается прямо в фреймворк, не требует модификации Java, это инструмент статического анализа, позволяющий найти ошибки в коде. Ура! Такие вещи воспринимаются куда легче, чем «вот вам полностью новый способ программирования».
Если же говорить конкретно о функциональном программировании, то отношение к нему сильно изменилось в последнее время. Гораздо больше народа знают теперь, что это такое. Уже не приходится всякий раз объяснять, что такое Haskell. Некоторые говорят: «Я читал про него недавно на Slashdot, по-моему, это круто». Еще несколько лет назад такого не было.
Но что за этим реально кроется? Случайный всплеск интереса? Или просто все больше бывших студентов, узнавших в университете о функциональном программировании, занимают теперь менеджерские и руководящие должности? Возможно, и так. Но, может быть, причина в том, что с усложнением программных систем становится все важнее справляться с последствиями неконтролируемых побочных эффектов, иметь больше гарантий корректности и лучше использовать параллелизм. Думаю, стрелка на шкале «цена-качество» постепенно смещается.
Сейбел: А как вы сами начали заниматься функциональным программированием?
Пейтон-Джонс: Я ничего о нем не знал до последнего года в Кембридже, когда прослушал небольшой курс Артура Нормана. Норман был блестящим, слегка эксцентричным лектором. Он интересовался символической алгеброй, так что хорошо разбирался в Лиспе. На лекциях он объяснял нам, как составлять двунаправленные списки без каких-либо побочных эффектов. Отлично помню это, потому что впервые столкнулся с такой удивительной вещью — составляешь список, выделяешь ячейки и заполняешь их так, чтобы они указывали друг на друга. Кажется, будто нужно как-то использовать побочные эффекты.