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

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

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

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

Сейбел: Думаю, многие после такой лекции сказали бы: “Занятно!” - и вернулись к своему 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-е. Пожалуй, мы пошли немного не той дорогой, но все это было крайне захватывающим.

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

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

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

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

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

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

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

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

Сейчас мне кажется, что ленивые вычисления важны, так как позволяют сохранить чистоту. Я уже говорил об этом по другим поводам. Я люблю эти вычисления и, если есть выбор, всегда возьму ленивый язык. По-моему, они полезны в какой угодно области программирования. Вы, конечно же, читали статью Джона Хьюза “Why functional programming matters” (О важности функционального программирования). Это, вероятно, первое открытое выступление на тему того, что ленивые вычисления - не просто игрушка. Главное - они помогают создавать модульные программы.

Ленивые вычисления позволяют писать генераторы. Хьюз пишет: давайте сгенерируем все возможные ходы в шахматной игре, независимо от потребителя, который лазает по дереву и делает альфа-бета-отсечение с помощью минимакса. Если же вы генерируете всю последовательность приближений к ответу, потребитель говорит, когда нужно остановиться. Поэтому, отделив генераторы от потребителя, мы получаем модульное строение программы. А если вы занимаетесь генерированием вместе с потребителем, говорящим, когда остановиться, показатель модульности существенно понижается. Модульность означает, что в разных местах идут разные процессы, которые можно комбинировать. Джон в своей статье приводит прекрасные примеры того, как потребитель или генератор могут быть заменены независимо друг от друга; это позволяет соединять вместе различные программы, что было бы намного труднее, если бы это была одна тесно переплетенная программа.

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