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

Я составлял списки того, что хотел задать на входе и получить на выходе, иногда приводил краткие примеры. Недавно я нашел одну из своих ранних программ на APL. Мне тогда было лет 15-16. То был кусок кода на APL - я набросал его на бумаге, прежде чем попробовать запустить. Рядом лежал другой клочок бумаги - примеры того, что у меня должно было быть на входе и на выходе. Там были ошибки, примеры были несовместимы с кодом, но, по крайней мере, я пытался дать примеры использования этой программы. Примеры того, что как я думал, увижу на терминале.

Когда я стал работать в проекте Maclisp, структура была уже определена. Почти все, что я делал, было добавлением новых функций к их и без того солидному набору. Там уже были готовые примеры документирования функций, надо было просто добавлять свои в том же стиле.

Сейбел: Вы говорили, что Йонл передал вам работу над интерпретатором, - до того он занимался и интерпретатором, и компилятором.

Стил: Мы вместе занимались проектированием, я был младшим программистом. Он мог сказать: “Нам нужна такая-то функция, работающая так-то, - давай, напиши код”. Но чаще мы получали запросы от разработчиков Macsyma - мол, нам надо то-то и то-то, - и мы с Йонлом вместе выдумывали интерфейс, а потом я писал для него код.

Сейбел: Значит, в интерпретаторе и компиляторе надо было отразить новые языковые свойства, которые приобрел Maclisp?

Стил: Да, языковые свойства. Многие из них системно-ориентированного характера - управление ресурсами, выделение страниц. Я ввел новый тип данных, который назвал “hunk”, и это оказалось настоящей катастрофой. Он представлял собой cons-ячейку более чем с двумя указателями. Это был акт отчаяния, потому что мы вышли за пределы адресного пространства PDP-10, которое, напомню, было 18-битным. Половина указателей в списке уходила на то, чтобы поддерживать структуру списка, в то время как в цепочке данных типа hunk на это уходила всего лишь восьмая часть указателей. В результате память использовалась лучше.

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

Стил: Мы пару раз серьезно все переписывали. А однажды полностью пересмотрели структуру программы и реализацию всех операций ввода/вывода в языке - кажется, в 1975 или 1976 году. Старая система позволяла иметь один поток данных на входе и один на выходе и могла взаимодействовать с терминалом. Мы поняли, что получим гораздо более гибкую систему, если Лисп-объекты станут каналами ввода/вывода. И таких одновременно открытых каналов могло быть до 15.

Другим поводом было то, что Maclisp начали портировать на другие операционные системы. В разных местах использовался свой вариант операционной системы PDP-10, и, посмотрев на список клиентов, мы поняли, что придется поддерживать полдюжины различных операционных систем: TENEX, TWENEX, ITS, TOPS-10, WAITS и вариант CMU.

И вот тем летом мы с Джоном создали новый набор API. Тогда этот термин еще не употреблялся - были описания функций, пригодных для создания файловых объектов, их открытия и закрытия, систематизации процессов удаления и переименования и для получения перечня файлов в каталоге.

В какой-то момент я получил свежую распечатку всего Maclisp и на неделю засел в летнем доме родителей с шестью руководствами по ОС. Каждый день я шесть часов переделывал код.

Надо было разработать каждое свойство, например функцию “переименовать”, потому что процесс взаимодействия с ОС при переименовании файла сильно различался во всех шести вариантах. В целом образовалось три основных группы вариантов - TOPS-20, TOPS-10 и ITS.

И я неделю занимался этим, проектировал, разрабатывал реализацию, и все это на бумаге, без компьютера. Потом я приехал в MIT и месяц набивал все это, занимался отладкой и тестированием.

Сейбел: Почему именно так?

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

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

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

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

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

Сейбел: Если не рассматривать возможность реализации, как вы оцениваете интерфейс?

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

Я спроектировал много чего и теперь могу сказать, насколько хорошо это вышло. Сейчас я иногда проектирую вещи, родственные тем, что делал раньше. Например, создавая спецификации для числовых функций в Java, я вспоминаю, что уже делал это для Common Lisp. А еще я документировал числовые функции для Си. Я знаю, в чем подводные камни, если говорить о реализациях и спецификациях для таких вещей. Я потратил много времени, исследуя пограничные случаи. Об этом я вычитал у Тренчарда Мора, который разработал теорию массивов данных для APL. Он считал, что если прояснить все с пограничными случаями, промежуточные прояснятся сами собой. Правда, Мор не говорил об этом прямо, этот вывод сделал я сам.