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

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

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

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

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

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

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

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

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

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

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