Кодеры за работой. Размышления о ремесле программиста - Сейбел Питер

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

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

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

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

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

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

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

Сейбел: А как вы сами начали заниматься функциональным программированием?

Пейтон-Джонс: Я ничего о нем не знал до последнего года в Кембридже, когда прослушал небольшой курс Артура Нормана. Норман был блестящим, слегка эксцентричным лектором. Он интересовался символической алгеброй, так что хорошо разбирался в Лиспе. На лекциях он объяснял нам, как составлять двунаправленные списки без каких-либо побочных эффектов. Отлично помню это, потому что впервые столкнулся с такой удивительной вещью — составляешь список, выделяешь ячейки и заполняешь их так, чтобы они указывали друг на друга. Кажется, будто нужно как-то использовать побочные эффекты.

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

Сейбел: Думаю, многие после такой лекции сказали бы: «Занятно!» — и вернулись к своему BCPL. Почему же вы пошли дальше, занялись исследованиями, стали объяснять людям, как пользоваться этими программами?

Пейтон-Джонс: Еще сыграли роль статьи Дэвида Тернера о комбинаторах S и К, которые помогают преобразовывать и затем выполнять лямбда-вычисления. О лямбда-вычислениях я знал немного больше — тогда эта идея набирала популярность. Тернер показывал, как преобразовывать лямбда-вычисления в три комбинатора: S, К и I, которые представляют собой закрытые лямбда-термы. Фактически речь шла о том, чтобы преобразовать сколь угодно сложные лямбда-термы в эти три комбинатора. Можно даже обойтись без I, так как он равен SKK.

Довольно странное преобразование — берешь лямбда-терм, который хоть как-то понимаешь, и получаешь набор из S и К, в котором не понимаешь ничего. Но вот применяешь их к аргументу, и случается чудо — ответ выходит тот же, что и с применением изначального терма. Что-то очень умное — для меня по тем временам невероятное. Но это всегда работает!

Я обратился к функциональным программам по вдохновению. Отчасти, думаю, потому, что был связан с «железом», а это выглядело способом реализации лямбда-вычислений. Ведь сперва кажется, что в них вообще нет механизма реализации, что это чистая математика, далекая от компьютеров. A S-K комбинаторы, как мне показалось, позволяют применять их на практике — и так оно и было.

Сейбел: Значит, вы решили, что достаточно заложить эти комбинаторы в машину, а потом уже на их основе выполнять операции?

Пейтон-Джонс: На самом деле именно этим занимались мои друзья. Уильям Стой, Томас Кларк и еще несколько человек создали компьютер SKIM, или SKI Machine, который напрямую выполнял S и К. Я не участвовал в их проекте, но тогда все развивалось в этом направлении. Статья Джона Бэкуса «Can programming be liberated from the von Neumann style» (Может ли программирование освободиться от стиля фон Неймана) была невероятно популярна. Он получил Премию Тьюринга за эту статью, и он — изобретатель Фортрана — фактически заявил: «Будущее за функциональным программированием».

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

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

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

Сейбел: Например?

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

Сейбел: Со временем.

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