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

Пейтон-Джонс: Тони Хоар замечательно сказал: нужен код, совершенно очевидно свободный от ошибок, а не код, свободный от очевидных ошибок. Думаю, красивый код — это код, который совершенно очевидно правилен. Абсолютно прозрачный код.

Сейбел: А как насчет перлов — небольших замысловатых, но интересных фрагментов кода, — они тоже красивы?

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

Я полностью согласен с тем, что простого изучения кода может быть недостаточно. Если вы смотрите на код и видите, что он правилен, это еще не характеристика красивого кода. Возможно, кто-то должен объяснить, почему код правилен. Но после этого, поняв, что тут делается, выработав свою точку зрения, вы говорите: да, это на самом деле правильно.

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

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

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

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

Есть ли верхняя граница, если говорить о размере? Не знаю. Но мне кажется, что продолжая создавать хорошие абстракции, можно строить мосты через Атлантику. У нас есть программы, которые работают, — пусть не идеально, но на удивление хорошо, учитывая их размер.

Сейбел: Вопрос в том, можно ли построить здание — большое, приспособленное для проживания и красивое одновременно.

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

Сейбел: И единственный выход — признать, что программа отжила свое, и начать делать новую?

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

Самый угнетающий момент в жизни программиста — когда сталкиваешься с чужим кодом или, что еще хуже, со своим и не находишь сил его переделать. Это угнетает.

8. Питер Норвиг

Питер Норвиг — теоретик широкого профиля и хакер в душе. В свое время он написал программу для нахождения в истории поиска Google трех последовательных запросов от одного пользователя, так чтобы они складывались в хокку (один из знаменитых примеров: «Java ЕСС/эллиптическая криптография Java/FAQ „Плейбоя"»).

На сайте Норвига вы найдете самые обычные ссылки: написанные им книги, слайды выступлений, фрагменты его кода. Но там есть также ссылки на его работы, опубликованные в «McSweeney's Quarterly Concern», на искрометный рассказ о создании программы для генерации самого длинного палиндрома и на пародийную PowerPoint-презентацию Геттисбергской речи Линкольна, отмеченную Эдвардом Тафти и появляющуюся на первых страницах результатов, если ввести «powerpoint» в строке поиска Google.