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

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

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

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

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

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

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

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

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

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

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

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

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