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

Сейбел: Вы сейчас много программируете?

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

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

Сейбел: Вам это доставляет такое же удовольствие, как и в начале?

Пейтон-Джонс: Да, конечно. Это лучшая в мире вещь. Мне кажется, у большинства программистов есть чутье: «здесь должен быть какой-то хороший выход». Работа в исследовательской сфере хороша еще и тем, что надо мной не стоит менеджер, которому нужен результат через неделю. Я могу спокойно сесть и подумать: «Здесь должен быть какой-то хороший выход».

Поэтому я много времени уделяю рефакторингу, вожусь с интерфейсами, создаю новые типы или полностью переписываю большие куски, чтобы их улучшить. GHC довольно велик — не по промышленным стандартам, а по понятиям функционального программирования: в нем 80 000 строк кода на Haskell, а может, и больше. Это компилятор-долгожитель — ему уже пятнадцать лет. Он активно развивается, большие куски переписываются, и нет мест, которые нельзя трогать. Поэтому меня так приятно возбуждает возможность сесть и сказать себе: «Здесь должен быть какой-то хороший выход». Иногда я оставляю что-нибудь на несколько недель — не могу найти хороший выход, зная, что он есть. Это мучительно. Потому что красивый способ должен быть.

Сейбел: Что происходит в эти несколько недель?

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

Сейбел: Как это происходит? Вы просыпаетесь утром и понимаете, что решение найдено? Или снова начинаете восхождение и в конце концов добираетесь до вершины?

Пейтон-Джонс: Скорее второе. Озарения по утрам случаются редко. На исследовательской работе есть время подумать над сделанным, записать свои мысли. Иногда получается настолько интересно, что я пытаюсь соорудить статью. Одна из таких статей называется «The Secrets of the GHC Inliner» (Секреты GHC). В ней описываются техники реализации, примененные нами для некоторых элементов GHC и полезные, как мы считаем, другим разработчикам. Как ученый, я имею возможность абстрагироваться от кода, которому мы на четвертый раз наконец-то придали нужный вид, и написать о нем, чтобы другие смогли применять наши методы.

Сейбел: Что для вас программирование? Вы считаете себя ученым, инженером, ремесленником или кем-нибудь еще?

Пейтон-Джонс: Вы знакомы со статьей Фреда Брукса на этот счет -«The Computer Scientist as Toolsmith» (Компьютерный исследователь как системный программист)? Я недавно ее перечитал — отлично написано. Нельзя забывать, что прежде всего мы конструируем разные вещи. Поэтому программировать так увлекательно.

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

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

Пейтон-Джонс: Это ложное противопоставление. Тут нет никакого «или-или». Для проектировщиков и разработчиков ПО очень сложно внутренне прочувствовать размер артефакта, над которым они работают. Если смотреть на Эмпайр-стейт-билдинг через отверстие в один квадратный фут, очень непросто ощутить его истинные размеры и внутреннюю структуру.

Насколько велик GHC? У меня нет внутреннего чувства на этот счет — такого, какое есть насчет здания. Поэтому, думаю, мы совсем не инженеры-мостостроители. Их шаблоны проектирования настолько отточены, что они действительно могут быть уверены, что мост не развалится. Мы даже близко к этому не стоим. Но это вовсе не значит, что мы не должны заботиться об этом.

И здесь, как мне кажется, функциональное программирование может многое нам дать. Оно позволяет создавать более крепкие конструкции, более легкие для понимания и рассуждения о них. И здесь мы, функциональные программисты, запаздываем — много говорим об описаниях функциональных программ, но мало делаем таких описаний. Я бы хотел видеть больше инструментов, позволяющих понимать программы на языке Haskell, формально рассуждать о них и давать гарантии за пределами его системы типизации. Мы уже поднялись выше других и способны подняться еще выше.

Это по поводу прочности. Чем прочнее ваши материалы, тем меньше вы отвлекаетесь на мелочи и больше думаете о масштабных конструкциях. Конечно, это подвигает нас на создание все более крупных структур, пока они не начинают распадаться.

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

Сейбел: Гай Стил говорил, что закон Мура действовал на протяжении всей его карьеры программиста, но вот насчет всей карьеры своего сына он уже не уверен. Он также рассуждал насчет программирования в ближайшем будущем. Не пора ли уже прекращать эти разговоры -«Построили мост через Ла-Манш, давайте строить через Атлантику»?

Пейтон-Джонс: Нет-нет. С ПО все иначе. Если вы написали программу в десять раз больше предыдущей, это не значит, что вам нужно запускать ее на компьютере, работающем в десять раз быстрее. Программный счетчик тратит 90% времени на 10% кода или как-то так. Участки программы, критичные с точки зрения быстродействия, могут быть невелики по объему.

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

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