понятном языке. Естественный это язык или искусственный — роли не играет, важно лишь, чтобы правильность решения была ясна и людям, и машине.

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

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

Составлять этюды, однако, не так просто, как может показаться. Все еще слишком часто задачки из книжек по программированию представляют собой просто технические «упражнения для пальцев». Полезные для выработки навыков уверенного использования простейших языковых конструкций, они редко бывают «высокохудожественными», что требуется от этюда в определении, приводимом в энциклопедическом словаре. Несмотря на то что этюд — упражнение, «основанное на определенном техническом приеме исполнения» (см. тот же словарь), хороший этюд должен быть достаточно большим, чтобы ощущалась взаимосвязь этого приема с другими областями программирования. Все это наталкивает на мысль взять задачи непосредственно из жизни. «Настоящие» задачи, однако, изобилуют несущественными деталями, требуют обработки массы данных, порождают гору результатов и к тому же меняются чуть ли не каждый день, так как руководство никак не может принять окончательное решение. Из студента, способного освоить профессию прямо в производственном коллективе, конечно, выйдет прекрасный специалист, но слишком многие из обучающихся программированию таким образом не выдерживают и, отчаявшись, бросают. Так что этюд должен лежать где-то посередине между реальной жизнью и тривиальными упражнениями. Две области — игры и информатика — породили, в сущности, почти все эти этюды и наделили их рядом полезных черт. Программисты, как правило, интересуются и тем, и другим приложением (уж лучше бы только информатикой, разумеется). Поскольку культура — всеобщее достояние, большинство игр доступно пониманию каждого; объяснить прикладную задачу в наше время также нетрудно. Очень часто поведение игровой программы или, скажем, транслятора поддается строгому описанию, так что корректность решения можно проверить. Входные данные обычно невелики по объему, и готовить их легко; выходные данные легко воспринимаются. Обе упомянутые области требуют применения весьма развитых алгоритмов и структур данных, так что вряд ли какие-либо сложности в прикладных программах смогут впоследствии поставить студента в тупик. Наконец, в обеих этих областях ЭВМ предстает перед нами как мощный объект абстрактного «разума» (такой подход принят в задачах искусственного интеллекта); возможно, в нашем подборе задач чувствуется давний интерес к «разумным» машинам. Имеется, конечно, много задач и из других прикладных областей. При их отборе мы руководствовались в основном легкостью объяснения ситуации, которая приводит к постановке задачи. Тем, кому некоторые этюды покажутся легкомысленными, мы напомним, что Гайдн создал симфонию из колыбельной песни.

Как исполнять этюд

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

Каждый этюд распадается на разделы (некоторые из них необязательные). В первом разделе описывается реальная ситуация, во втором — конкретная программа, которую предстоит написать. Обычно ситуация разъясняется достаточно подробно, а постановка задачи — совсем короткая. Затем следует обсуждение трудностей, которые могут встретиться при реализации, и намеки на возможные пути решения. Рассматриваются только существенные моменты. Затем следуют разделы, в которых обсуждается выбор языка и длительность исполнения этюда^[4]. Временные оценки, которые рассчитаны на аспирантов первого года обучения, выделяющих для решения задачи четверть своего рабочего времени, могут оказаться малы для программистов, работающих не столь увлеченно. Кроме того, временные оценки могут увеличиваться под влиянием условий доступа к машине. В конце этюда часто содержится расширение поставленной задачи и аннотированная библиография. Решение, найденное с использованием дополнительной литературы, более полезно для студента.

Конечно, результатом работы над этюдом должна быть понятная и четкая программа, стиль и комментарии которой соответствовали бы задаче и выбранному языку. Но этого мало. Еще необходим набор тестов, достаточный для демонстрации работы программы и ее реакции на экстремальные ситуации и неправильное обращение. Наряду с самой программой требуется краткое словесное описание методов решения. Особый упор в нем следует сделать на положенные в основу решения алгоритмы и структуры данных. Наряду с описанием программы программист должен с достаточной степенью правдоподобности хотя бы неформально проиллюстрировать ее правильность (при недостатке времени можно ограничиться рассмотрением ключевых мест). Наконец, должен быть произведен подсчет затраченных ресурсов, как людских, так и машинных; особое внимание следует обратить на обоснование затрат. Также следует указать, чему программист научился на примере этой задачи (на этот вопрос легко ответить, если сформулировать его в виде: «Что я в следующий раз сделаю иначе?»). Такой объем документации может показаться избыточным. Заметим, однако, что умению вовремя поставить точку тоже очень полезно научиться. Решение небольшой задачи не следует перегружать документацией. Один знакомый автору преподаватель определяет оценку на 40% тем, что студент убедил его в правильности программы, на 50% легкостью, с которой его удалось убедить, и только на 10% отличным программированием. Очень хорошая оценка — это 80% и более. А поскольку часть документации — результаты машинных прогонов, такая отметка означает, что