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

После чего понадобилось еще два года, чтобы найти человека, который смог бы меня заменить. После чего потребовалось еще два года, чтобы по-настоящему передать ему все дела. К 2002 году я уже “наелся”. Я уже не мог больше видеть Ghostscript.

Поэтому я сказал: “Ладно, отдохну полгодика, осмотрюсь и решу, чем заняться дальше”. Мне тогда было 55 лет, и я не чувствовал себя старым. Я чувствовал, что могу сделать еще один крупный проект, если захочу что-то сделать. Поэтому я стал смотреть, что же происходит вокруг.

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

И вот была эта небольшая преуспевающая группа, которая доказывала теоремы; я о них писал в своей диссертации, и мне всегда это было интересно. И они добились потрясающего результата, работая над арифметическим блоком центрального процессора AMD. И я подумал: “Хм, эта группа обладает множеством хороших качеств: они занимаются интересными мне вещами; ими управляет человек, с которым я знаком и который мне нравится; их технология базируется на Лиспе. Это действительно по мне”.

Поэтому я отправился туда и прочитал там лекцию о том, как доказывание теорем могло бы - если, конечно, могло в принципе - помочь повысить уровень надежности Ghostscript. К тому времени у системы отслеживания ошибок Ghostscript была уже богатая история. Я нашел 20 ошибок, более или менее в произвольном порядке, взглянул на каждую из них и сказал: “Так, для того чтобы технологию доказывания теорем можно было бы с пользой применять для обнаружения или предотвращения этой проблемы, что должно еще произойти? Что здесь еще должно было бы появиться?”

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

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

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

Я не мог ни на что решиться. Я много лет пел в хоре. Летом 2003 года мы отправились в турне - дали шесть настоящих концертов в старых церквях в Италии. Вместе со мной ездил мой партнер, и мы решили остаться после этого турне в Европе на 2-3 недели.

Мы отправились в Вену и делали то, что люди делают в Вене. Дворец Хофбург был к тому моменту разделен на десять отдельных небольших специализированных музеев. Я прочитал в путеводителе, что там есть музей старинных музыкальных инструментов.

Я пошел в этот музей, состоящий из длинной анфилады старинных гостиных с высокими потолками. Он начинается с очень старых музыкальных инструментов - может быть, эпохи неолита - и дальше до современных. Естественно, большинство музыкальных инструментов там датированы последними двумя столетиями и сделаны в Западной Европе. Я на самом деле не все там посмотрел; я не дошел до конца одну-две гостиные, когда увидел фортепиано, принадлежавшее Леопольду Моцарту. И фортепиано, на котором репетировал Брамс. И фортепиано, которое стояло дома у Гайдна.

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

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

Сейбел: Но вы до сих пор программируете.

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

Первый - это технология спам-фильтра для моего почтового сервера. Я бы сказал, что это не очень прикольно, но достаточно интересно. Судя по логам, которые я время от времени просматриваю, фильтр действительно отсеивает - в зависимости от того, кто в тот или иной момент выигрывает в гонке вооружений, - от 80 до 95% входящего спама.

Другой значительный проект, связанный с ПО, к которому я постоянно возвращаюсь, - это музыкальный редактор. И делаю я это потому, что достаточно глубоко исследовал эту область. Мне приходилось пару раз работать с Finale - в гостях у одного знакомого. Полный отстой. Качество этой системы настолько низкое, что даже не знаю, как вам его описать. Я раздобыл диск с Sibelius. Нет, сначала я обзавелся ноутбуком Макинтош, чтобы запустить этот диск. И обнаружил, что пользовательский интерфейс там устроен так, что без клавиши Num Lock с этой программой практически невозможно работать. В ноутбуках Макинтош нет клавиши Num Lock. В их пользовательском интерфейсе были и другие моменты, которые мне не понравились. Поэтому я решил сделать собственный редактор.

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

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

(adsbygoogle = window.adsbygoogle || []).push({});