Система документации. Из всех инструментов больше всего труда может сберечь компьютеризированная система редактирования текста, действующая на надежной машине. Наша система, разработанная Дж. У. Франклином (J. W. Franklin), была очень удобна. Я думаю, без нее руководства по OS/360 появились бы значительно позднее и оказались бы более запутанными. Есть люди, которые станут утверждать, что двухметровая полка руководств по OS/360 является следствием недержания речи, и сама ее объемистость являет собой новый тип непостижимости. И доля правды в этом есть.
Но у меня есть два возражения. Во-первых, хотя документация по OS/360 и ошеломляет размерами, план ее изучения тщательно изложен. Если использовать его избирательно, то чаще всего можно не обращать внимания на большую часть всей массы. Документацию по OS/360 нужно рассматривать как библиотеку или энциклопедию, а не материал для обязательного чтения.
Во-вторых, это гораздо лучше, чем крайняя недостаточность документации, характерная для большинства систем программирования. Я охотно соглашусь, тем не менее, что в некоторых местах текст можно было значительно улучшить, и результатом лучшего описания стал бы меньший объем. Некоторые части (например, «Концепции и средства») сейчас очень хорошо написаны.
Эмулятор производительности. Лучше его иметь. Разработайте его «снаружи внутрь», как описано в следующей главе. Используйте одинаковое проектирование сверху вниз для эмулятора производительности, эмулятора логики и самого продукта. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.
Сегодня два важнейших инструмента системного программирования — это те, которые не использовались при разработке OS/360 почти десятилетие назад. Они до сих пор не очень широко используются, но все указывает на их мощь и применимость. Это: а) языки высокого уровня и б) интерактивное программирование. Я убежден, что только инертность и лень препятствует повсеместному принятию этих инструментов, технические трудности более не являются извинениями.
Языки высокого уровня. Главные основания для использования языков высокого уровня — это производительность и скорость отладки. Производительность мы обсуждали раньше (глава 8). Имеющиеся данные, хотя и немногочисленные, указывают на многократный рост, а не на увеличение на несколько процентов.
Улучшение отладки происходит благодаря тому, что ошибок становится меньше, а находить их легче. Их меньше, поскольку устраняется целый уровень образования ошибок, уровень, на котором делаются не только синтаксические, но и семантические ошибки, такие как неправильное использование регистров. Их легче находить, поскольку в этом помогает диагностика компилятора и, что еще важнее, очень легко вставлять получение отладочных моментальных снимков.
Меня эти возможности производительности и отладки ошеломляют. Мне трудно представить себе систему программирования, которую я стал бы создавать на языке ассемблера.
Ну, а как с классическими возражениями против этого инструмента? Их три: я не могу сделать то, что хочу; результирующая программа слишком велика; результирующая программа слишком медленна.
Что касается возможностей, возражение, я думаю, больше не состоятельно. Все свидетельствует в пользу того, что можно делать то, что хочется, потрудившись найти способ, но иногда для этого приходится изловчиться.
Что касается памяти, то новые оптимизирующие компиляторы начинают показывать весьма удовлетворительные результаты, и их усовершенствование продолжается.
Что касается скорости, то оптимизирующие компиляторы иногда порождают код, который зачастую выполняется быстрее, чем написанный вручную. Более того, проблемы скорости можно обычно решить, заменив от 1 до 5 процентов скомпилированной программы кодом, написанным вручную, после ее полной отладки. [5]
Какой язык высокого уровня следует использовать для системного программирования? Сегодня единственный достойный кандидат — PL/I. [6] У него очень полный набор операторов; он соответствует окружению операционной среды; имеется целый ряд компиляторов с разными особенностями — интерактивных, быстрых, с улучшенной диагностикой, с высокой степенью оптимизации. Лично я быстрее разрабатываю алгоритмы с помощью APL; затем я перевожу их в PL/I для соответствия системному окружению.