Интервью по языку Форт [Чарльз X. Мур] (pdf) читать постранично, страница - 10

параметры и посмотрев на выходные. Опять-таки, действуя в восходящем
порядке, вы можете быть уверены, что все ранее определённые вами слова работают
правильно, потому что вы их протестировали. Кроме того, в Форте мало условных
операторов. Есть конструкции if-else-then и begin-while. Моя философия, которую
я стараюсь систематически распространять, состоит в том, что количество
условных операторов в программе должно быть минимально. Вместо одного слова,
которое проверяет некое условие, а потом выполняет либо одно, либо другое,
лучше иметь два слова: одно выполняет это, другое - то, а вы решаете, которое
из них применить. В Си так не получится, потому что вызов обходится дорого, и

стараются ввести такие параметры, чтобы одна и та же подпрограмма выполняла
разные действия в зависимости от того, как её вызвали. Отсюда все ошибки и
осложнения в старых программах.
В попытках обойти недостатки реализации?
Чак: Да. От циклов не уйти. Циклы могут быть весьма и весьма полезны. Но в
Форте, во всяком случае, в colorForth, циклы очень просты: у них один вход и
один выход.
Что вы посоветуете новичкам, чтобы они могли программировать эффективно и с
удовольствием?
Чак: Я наверняка не удивлю вас, сказав, что нужно учиться писать код на Форте.
Даже если вы не собираетесь профессионально писать программы на Форте,
поработав с ним, вы извлечёте некоторые уроки, которые пригодятся вам, с каким
бы языком вы ни стали работать. Если бы я писал программу на Си - а я почти не
писал их, - то стал бы делать это в стиле Форта, с множеством простых
подпрограмм. Даже если это потребуетбольше труда, вы облегчите поддержку.
Другой принцип - простота. Чем бы вы ни занимались - проектированием самолёта
или написанием программы, даже обычного текстового редактора, вы неизбежно
начинаете добавлять всё новые и новые функции, пока цена не станет
неприемлемой. Лучше сделать несколько текстовых процессоров, ориентированных на
разные рынки. Глупо писать электронное письмо с помощью Word: 99% его
возможностей окажутся невостребованными. Для электронной почты нужен свой
редактор. Когда-то такой был, но мода идёт в другом направлении. Непонятно
почемую. Будьте проще. Если вы разрабатываете приложение, если входите в
команду проектировщиков, постарайтесь убедить остальных, что нужно стремиться к
простоте. Не нужно прогнозировать. Не нужно решать задачу, которая, как вам
кажется, может возникнуть в будущем. Решайте ту задачу, которая стоит сейчас.
Стремление предугадать неэффективно. Вы рассчитываете на 10 событий, из которых
в действительности случится одно, в результате кучу сил потратите впустую.
Каковы признаки простоты?
Чак: Мне кажется, что наука о сложности только зарождается, и одна из её догм измерение сложности. Мне нравится определение - не знаю, есть ли другие, - что
из двух концепций проще та, у которой короче описание. Если вы описали нечто
короче, значит, описали его проще. Но здесь скрыт подвох, поскольку любое
описание зависит от контекста. Вы напишете очень короткую программу на Си и
будете считать, что она очень проста, но в действительности вы опираетесь на
то, что есть компилятор Си, операционная система и компьютер, где всё это будет
выполняться. Поэтому в более широком контексте у вас окажется не простая, а
довольно сложная вещь. Я бы сравнил это с красотой. Невозможно определить её,
но, видя красоту, вы узнаёте её; простое - значит маленькое.
Как работа в команде влияет на программирование?
Чак: Групповую работу слишком превозносят. Первая задача группы - разбить
задачу на относительно независимые части. Назначьте исполнителя для каждой
части. Руководитель команды отвечает за стыковку отдельных частей между собой.
Иногда могут работать вместе два человека. Обсуждая задачу, они делают её более
понятной. Но интенсивный обмен информацией становится самоцелью. Групповое
мышление не способствует творчеству. И когда несколько человек работают вместе,
наверняка всю работу делает один.
Это происходит в любом проекте? Если требуется богатая функциональность, как в
OpenOffice.org... ведь это достаточно сложно?
Чак: Такие вещи, как OpenOffice.org, разбиваются на подпроекты, каждый из
которых программируется одним человеком, а общение поддерживается на уровне,
необходимом для обеспечения совместимости.
По каким признакам вы узнаёте хорошего программиста?

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