кода?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня Норвиг - глава исследовательского отделения Google, ранее руководил отделением качества поиска. До прихода в Google возглавлял подразделение вычислительной техники исследовательского центра НАСА, а до того, в конце 1990-х, был одним из первых сотрудников интернет-стартапа Junglee. Норвиг - лауреат Премии НАСА за выдающиеся достижения (2001), член Американской ассоциации искусственного интеллекта и Ассоциации вычислительной техники.

Благодаря опыту работы в Google, НАСА и Junglee Норвиг знаком как с “ха-керским”, так и с “инженерным” подходом к созданию ПО. В нашей беседе он коснулся преимуществ и недостатков каждого из них. Как у бывшего профессора информатики, а ныне сотрудника одной из крупнейших корпораций по производству ПО, у него есть интересный взгляд на отношения между академической компьютерной наукой и промышленной практикой.

Мы говорили о том, как изменилось программирование за последние годы, почему никакие методы проектирования не помогут тому, кто не понимает, что делает, и в чем НАСА может выиграть, применяя менее надежное, но дешевое ПО.