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

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

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

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

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

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

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

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

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

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

Сейбел: То есть они в основном настраивали клавиши?

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

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

Сейбел: Одним из этих парней был Ричард Стеллмен?

Стил: Нет, Стеллмен занимался реализацией и поддержкой ТЕСО. Ричард снабдил его встроенной системой редактирования в реальном времени, хотя, кажется, над ранней версией работал Карл Миккельсен. Он реализовал функцию назначения сочетаний клавиш, которая сделала все это возможным.