Другим поводом было то, что 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. Он считал, что если прояснить все с пограничными случаями, промежуточные прояснятся сами собой. Правда, Мор не говорил об этом прямо, этот вывод сделал я сам.

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

Сейбел: Работая в MIT, вы были причастны к рождению Emacs. Но ранняя история Emacs несколько туманна. Можете ли вы что-нибудь прояснить?

Стил: Я занимался стандартизацией. Был избран такой способ отображения, что ТЕСО становился чем-то вроде WYSIWYG-редактора. На наших экранах размером 24x80 21 строка предназначалась для отображения тех строк, что были в буфере, а нижние 3 строки относились к командной строке ТЕСО. Там надо было вводить команды ТЕСО, и они исполнялись лишь при двойном нажатии клавиши Alt. Был и режим редактирования в реальном времени — там этого нажатия не требовалось. ТЕСО реагировал немедленно на каждый введенный символ как на команду. Вводишь один символ — исполняется команда, вводишь другой — исполняется другая. А большинство печатных символов вставлялось автоматически. Для перемещения вперед, назад, вверх и вниз служили управляющие символы. Это выглядело как очень примитивная версия Emacs.

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