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

Айк: Никто не ожидает встретить получаемые ошибки округления - в пятой степени невообразимые. Округление плохо выполняется в двоичной системе. Поэтому в JavaScript, там, где речь идет о долларах и центах, суммах и разностях, встречаются странные нули с девяткой после них. В одном блоге критиковали Safari и Мак за неправильные математические вычисления. Это стандарт двойной точности IEEE - он встречается везде, и в Java, и в Си.

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

Затем я перешел в Иллинойский университет в Урбана-Шампейне, чтобы наконец получить степень магистра. Я думал, что все уже позади, когда оказался в проекте, для которого IBM набирала специалистов. У них была странная машина 68020, купленная у какой-то компании из Дэнбери (Коннектикут). На этот компьютер они портировали Xenix. Работал он так плохо, что они наняли нашу исследовательскую группу, сделав из нее группу контроля качества. Каждый понедельник появлялся человек в синем костюме и произносил напутственные слова. Преподавателям было, в общем, все равно. Может, я и научился бы чему-нибудь новому, но слышал, о чем говорил в кампусе Джим Кларк, и решил, что хочу работать в Silicon Graphics.

Сейбел: Над чем вы работали в SGI?

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

В конце концов я создал другую реализацию языка - компилятор, который генерировал Си-код на основе описания протокола. Кто-то захотел, чтобы наш анализатор пакетов поддерживал AppleTalk. Это было большое и сложное собрание протокольного синтаксиса для последовательностей и полей разных размеров и зависимых типов... в основном массивов, всякие штуки в этом роде. Это было занятно - трудная задача, которую нужно решить. В итоге мне пригодились некоторые знания о компиляторах из старой “Книги Дракона” Ахо и Ульмана [44] А. Ахо, Р. Сети, Д. Ульман “Компиляторы. Принципы, технологии, инструменты”. - Вильямс, 2003. . Думаю, я сделал клон утилиты unifdef. Дэйв Йост уже сделал до меня что-то подобное, но его программа не работала с выражениями #if и не делала минимизацию выражений в том случае, если одни выражения определялись как U, а другие не определялись. Моя программа до сих пор используется и даже, кажется, применяется в Linux.

Я работал в SGI с 1985 по 1992 г. В 1992 г. один мой коллега из SGI перешел в MicroUnity. SGI мне к тому времени уже поднадоела - она все распухала, скупая другие компании, и постепенно переходила под контроль политиков. Так что я оказался в MicroUnity, о которой Джордж Гилдер тогда писал в журнале “Forbes ASAP”, что это будет очередной компьютерный монстр. Но все закончилось ничем - компания набрала кредитов на 200 миллионов и обанкротилась. Это было крайне поучительно. Там я занимался компилятором GCC и улучшил свои навыки работы с компиляторами. Еще я писал небольшой язык для редактора видеофайлов MPEG2, на котором можно было писать псевдоспецификации, похожие на стандарты ISO или IEC, и он генерировал тестовые битовые потоки с правильным синтаксисом.

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

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

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

Что касается программирования, то я всегда говорил, что занимаюсь низкоуровневым программированием. Объектно-ориентированное программирование, шаблоны проектирования - это не для меня. Я так и не купил книгу Эриха Гаммы. Кое-кто в Netscape потрясал этой книгой как Библией - наши с Джейми Завински враги-коллеги, пришедшие в компанию после ее покупки. Просто невыносимо, учитывая, что это были далеко не лучшие программисты.

Сложись все иначе, я мог бы заниматься и высокоуровневыми вещами. Думаю, работая в Mozilla и имея дело с Firefox, я узнал больше о разработке через тестирование - то был ценный опыт. Было и кое-что еще, например тестирование с использованием случайных данных, которого проводилось много. У нас было много исходных языков, были большие и глубокие конвейеры рендеринга, сильно подверженные ошибкам, связанным с безопасностью доступа к памяти. Вообще, тестирование с использованием случайных данных оказалось самым продуктивным видом тестирования.

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

Сейбел:Статический анализ какого именно вида?

Айк:Анализ языка C++, выполнить который непросто. Обычно при статическом анализе вы анализируете программу целиком и стремитесь, скажем, доказать корректность состояния памяти. Нужно устранить все неоднозначности, а для этого найти в памяти все альтернативные имена - это проблема экспоненциального характера, обычно нерешае-мая ни для одной более-менее крупной программы. Большой прорыв, однако, заключался в том, что больше не надо было волноваться насчет памяти. Если построить полную диаграмму исполнения команд и связать воедино все виртуальные методы с их возможными реализациями, то можно частично оценивать код, не запуская его. Можно найти недостижимый код, можно найти избыточные проверки и пропущенные проверки на NULL.

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