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

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

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

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

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

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

А в нашем случае — ничего подобного. Надо просто написать те вспомогательные определения, которые могут понадобиться, и те, что понадобятся, будут вычислены. Это очень, очень удобный инструмент.

Но вернемся к общим положениям. С ленивым механизмом вычисления сложнее предсказать, когда понадобится вычислить выражение. И если вы хотите вывести что-нибудь на экран, то язык с вызовом по значению, где порядок вычисления явно определен, делает это при помощи «функции» с побочным эффектом — я специально ставлю кавычки, так как это вовсе не функция, — с типом, скажем, string -> unit. При вызове функции она печатает что-то на экране — в виде побочного эффекта. Это есть в Лисп, в ML, в любом языке с вызовом по значению.

А в чистом языке, если есть функция string -> unit, ее никогда не надо вызывать: вы ведь знаете, что она выдаст всего лишь ответ типа unit. Больше она не делает ничего. А каков ответ, вы знаете. Но поскольку функция с побочными эффектами, очень важно вызвать ее. В ленивом языке проблема вот какая: вы говорите «f применяется к print 'привет», а вычисляет ли f свой первый аргумент, для вас неясно. Это все происходит внутри функции. Если же аргументов будет два — print 'привет' и print пока', — она может выполнить один, или оба в любом порядке, или ни одного. Поэтому при ленивых вычислениях делать ввод /вывод при помощи побочных эффектов невозможно. Вы не можете написать таким способом рациональную, надежную, предсказуемую программу. Сначала это было непривычно — нет, собственно, никакого ввода/вывода. И потому долгое время в программах использовалась только функция string -> string. Целая программа делала только это. Строка на входе была вводом, а строка результата — выводом. Вот и все.

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

Смысл в том, что ленивость загнала нас в угол, и пришлось решать вопрос с вводом/выводом. Это была самая важная проблема ленивого программирования. Но начиналось-то все с другого — с того, как это прикольно, как здорово.

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

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

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

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

Сейбел: А в этом языке применена типизация исходного языка?

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

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