Сложность, конечно, в том, что коробочные пакеты разработаны как самостоятельные объекты, функции и интерфейсы которых метапрограммисты не могут изменить. Кроме того, более существенно то, что разработчики коробочных пакетов, кажется, не слишком стремятся сделать свои продукты пригодными в качестве модулей более крупных систем. Думаю, что такое понимание неверно, и существует неудовлетворенный рынок для пакетов, способствующих использованию метапрограммирования.

Так что же требуется? Можно выделить четыре уровня пользователей коробочных продуктов:

• Пользователь как таковой, просто использующий приложение и удовлетворенный функциями и интерфейсом, предоставленными разработчиками.

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

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

• Метапрограммист, использующий одно и, в особенности, несколько приложений в качестве компонентов более крупной системы. Это пользователь, чьи нужды сегодня слабо удовлетворяются. Это тот вид использования, который обещает наибольший рост производительности при создании новых приложений.

Для этого последнего типа пользователей коробочный продукт должен иметь дополнительный документированный интерфейс — интерфейс

метапрограммирования. Он должен предоставлять несколько возможностей. Прежде всего, метапрограмма должна управлять ансамблем приложений, несмотря на то, что каждое приложение, как правило, считает, что управляет самим собой. Этот ансамбль должен управлять интерфейсом пользователя, хотя обычно само приложение считает, что делает это. Ансамбль должен быть в состоянии вызвать любую функцию приложения, как если бы его командная строка исходила от пользователя. Выходные данных приложения должны передаваться ему, а не на экран, причем в виде логических блоков подходящих типов данных, а не текстовой строки, которую нужно отобразить. В некоторых приложениях, например, FoxPro, есть дырочки, позволяющие передать командную строку, но возвращаются скудные и неразобранные данные. Такая дырочка — заплатка на скорую руку, в то время как требуется общее проработанное решение.

Большие возможности дало бы наличие языка сценариев для управления взаимодействием приложений, входящих в ансамбль. Такого рода функции впервые предоставила Unix с помощью каналов и стандарта файлов в формате ASCII-строк. Сегодня неплохим решением является AppleScript.

Состояние и будущее программной инженерии

Однажды я попросил Джима Феррелла (Jim Ferrell), председателя химико-технологического факультета университета штата Северная Каролина поведать о

развитии химических технологий вне связи с химией, на что он экспромтом выдал мне замечательный рассказ, продолжавшийся час, начиная с существовавших с античных времен различных производственных процессов для многих продуктов — от стали до хлеба и парфюмерных изделий. Он рассказал, как профессор Артур Д. Литтл (Arthur D. Little) в 1918 году основал в МТИ факультет прикладной химии для исследования, разработки и обучения общим фундаментальным технологиям всех процессов. Сначала были практические правила, затем эмпирические номограммы, затем рецепты проектирования отдельных компонентов, затем математические модели распространения тепла, масс, количества движения в отдельных емкостях.

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

Тем не менее характер и временные рамки развития химической технологии приводят меня к мысли, что программная инженерия в возрасте 27 лет не столько безнадежна, сколько является незрелой, какой химическая промышленность была в 1945 году. Лишь после Второй мировой войны химики-технологи реально обратились к взаимосвязанным поточным системам с замкнутым циклом.

Сегодня характерные задачи программной инженерии звучат точно так же, как они изложены в главе 1:

• Как проектировать и строить программы, образующие системы.

• Как проектировать и строить программы и системы, являющиеся надежным, отлаженным, документированным и сопровождаемым продуктом.

• Как осуществлять интеллектуальный контроль в условиях большой сложности.

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

В моей памяти все еще живы удивление и восторг, с которым я — мне тогда было 13 лет — читал отчет от 7 августа 1944 года об освящении компьютера Mark I, архитектором которого был Говард Айкен (Howard Aiken), а проектировщиками — инженеры Клер Лейк (Clair D. Lake), Бенджамин Дурфи (B. M. Durfee) и Фрэнсис Гамильтон (F. E. Hamilton). Такой же вызывающей ощущение чуда была статья Ванневара Буша (Vannevar Bush) «That We May Think» в апрельском 1945 года номере «Atlantic Monthly», в которой он предложил организовать знания в виде огромной гипертекстовой паутины и обеспечить пользователей машинами для переходов по существующим ссылкам и создания новых ассоциативных следов.

Новый толчок моя страсть к компьютерам получила в 1952 году, когда, работая летом на IBM в Эдинкоте, штат Нью-Йорк, я получил практический опыт программирования для IBM 604 и формальное обучение программированию для IBM 701, их первой машины с хранимой программой. Аспирантура у Айкена и Иверсона в Гарварде сделала реальностью мои мечты о профессии, и я связал с ней всю свою жизнь. Немногим Бог дает право зарабатывать на жизнь тем, чем они с радостью занимались бы по собственной воле, по увлечению. Я благодарен судьбе.

Для человека, влюбленного в компьютеры, трудно было бы придумать иное время, когда так радостно было жить. От механических устройств до вакуумных ламп, транзисторов и интегральных схем шло бурное развитие технологии. Первый компьютер, на котором я работал сразу после выпуска из Гарварда, был суперкомпьютер IBM Stretch. Этот компьютер царствовал над миром как самый быстрый с 1961 по 1964 годы; было изготовлено 9 экземпляров. Мой сегодняшний Macintosh Powerbook не только быстрее, с большей памятью и большим диском, но и в тысячу раз дешевле (в пять тысяч раз дешевле с учетом инфляции). Мы были свидетелями того, как поочередно произошли компьютерная революция, революция электронных компьютеров, революция миникомпьютеров и революция микрокомпьютеров, в результате каждой из которых компьютеров становилось на порядки больше.