Читаем Кодеры за работой полностью

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

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

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

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

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

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

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

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

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

Сейбел:

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

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

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

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

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

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как «Человеческий фактор». Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела.В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

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

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги