Онлайн-версия CD-ROM приложения к книге Г.Р.Громова
"От гиперкниги к гипермозгу: информационные технологии
эпохи Интернета. Эссе, диалоги, очерки
."

Программирование как точная наука

УСиМ, 1986. №3, с.126- 127

 

От редакции "УСиМ". В 1982 г. руководитель лаборатории программных исследований Оксфордского университета проф. Ч. Хоар опубликовал препринт "Программирование как инженерная профессия", который вызвал большой интерес и был перепечатан радом журналов на английском языке, а в переводе на русский язык - журналом "МП" (Микропроцессорные средства и системы)[2].

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

Такой же точки зрения придерживается значительная часть ученых и специалистов и в нашей стране. Так, например, в сборнике "Вычислительные системы" (Новосибирск, 1983. - № 96, - с.51-74) в статье "О природе программирования" сказано, что ''...программирование как научная дисциплина является частью прикладной математики, а как вид деятельности - разновидностью математической практики, и по своей природе основания программирования являются логико-математическими".

Но есть и другие точки зрения на программирование как науку. Одна из них изложена в публикуемом ниже письме Г. Р. Громова.

Статья Ч. Хоара читается с неослабевающим интересом, волнением узнавании и сопереживания, особенно в той основной ее части, где автор образно живописует старые трудности, новые парадоксы и ожидаемые проблемы становления программирования как инженерной дисциплины. Однако с некоторыми разделами конструктивно-прогностической части статьи согласиться трудно.

Представляется, что отказ от веры в математизацию как основное средство решения проблем программирования вряд ли означает капитуляцию перед этими проблемами. "Летчики, - напоминает Ч. Хоар, - как правило, не разбивают самолеты. Хирурги, как правило, не убивают своих пациентов". Нетрудно заметить, что если эти примеры что-то и доказывают, то отнюдь не необходимость математически строгой формализации процесса программирования, обосновываемую Ч. Хоаром. Приемлемый уровень профессиональной надежности исполнителей достигается здесь не потому, что летчик, прежде чем сесть за штурвал, получает вместе с полетными документами математически строгое доказательство заранее вычисленного алгоритма поведения на борту. Аналогичным образом хирург в предоперационный период не ожидает, что ему вручат какой-либо математический "философский камень", страхующий от возможных ошибок. Ни один хирург еще не провел сколько-нибудь сложной операции без цепи "ошибок" - отклонения от теоретически существующей, идеально бескровной траектории движения скальпеля. И летчик, и хирург, и программист постоянно совершают и исправляют ошибки. Уровень квалификации конкретных исполнителей определяет цену ошибок,[3] строго обоснованной, математически вычисленной траектории в этих профессиях еще не было и, по-видимому, быть не может. Почему? Одним из первых, кажется, попытался дать ответ на аналогичный вопрос А. С. Пушкин:

"Затем, что ветру и орлу,

И сердцу девы нет закона,

Гордись: таков и ты, поэт,

И для тебя условий нет".

Видимо, за определенным барьером сложности начинает работать, по определению Г. Биркгоффа, "математика других чувств". Во всяком случае почти всех высококвалифицированных представителей каждой из трех упомянутых Ч. Хоаром профессий, несмотря на заметную разницу в их возрасте (тысячелетия развития медицины, столетие воздухоплавания на аппаратах тяжелее воздуха и сорок лет программирования), объединяет общий стиль работы: способность уверенно действовать при значительной доле неопределенности в исходных "спецификациях" на задачу и резко изменяющихся условиях ее решения.

"Взлет труден, полет приятен, посадка опасна!" - кратко поясняет инструктор курсантам, что их ждет в воздухе. Автопилот, как известно, включают именно на "приятном", а не на "трудном" и тем более не на "опасном" этапах полета. Не случайно, по-видимому, и в программировании из всего технологического цикла создания программ первым объектом автоматизации был избран наиболее удобный для формализации (а с точки зрения "математизированной ветви" науки программирования, очевидно, наиболее "приятный") этап кодирования, а не "взлет" (постановка задачи и выработка требований к комплексу программ) или "посадка" (операция внедрения готового программного продукта, чреватая, как правило, разрушительным "взрывом").

Существенно более полно, чем образ действий летчика или хирурга, вписывается в логику рассуждений Ч. Хоара его пример с проектированием стационарных технических сооружений, например моста. Понятно, что формализовать процесс разработки программ для решения характерных для эры ЭВМ первого поколения расчетных задач с четко заданными условиями принципиально можно. Есть основания предполагать, что в недалеком будущем почти любой вновь создаваемый такого типа алгоритм будет попадать на вход формально безупречного "автомата", который выдаст на выходе реализующую его программу для машинного хранения и широкого коммерческого использования в качестве проблемного модуля различных пакетов. Следует согласиться с точкой зрения Ч. Хоара, что такой строго формализуемый инструментарий для производства программ по точно заданным спецификациям позволит достичь высокой надежности конечной продукции. Иными словами, вероятность существования необнаруженной ошибки в программных модулях с клеймом АСП (автоматического синтеза программ) окажется в среднем значительно ниже, чем при любой иной технологии. Вес это так, но...

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

Поэтому, если согласиться с подобными оценками, следует признать, что и пример с мостом не проясняет истоки переживаемого сейчас кризиса прикладного программирования. Река, как правило, не меняет многократно своего русла за время проектирования моста (или немедленно после его сдачи заказчику). В то же время в соответствии с принципом неопределенности, сформулированным Дж. Мартином, "...процесс автоматизации задач, которые излагает конечный пользователь, изменяет его представление об этих задачах... Решение проблемы изменяет саму проблему".

В настоящее время уже свыше трех четвертей всех расходов на разработку типичного пакета прикладных программ "съедают" системные аналитики, т.е. та часть программистов, которые заняты анализом предметной области и формулировкой требований к программам. К середине 80-х годов системные аналитики оказались уже самой массовой и все еще быстрорастущей специальностью среди профессиональных программистов. Между тем, исследования исторически первой и поэтому академически наиболее престижной "математизированной ветви" науки программирования вес еще ограничены, в основном, рамками проблем повышения производительности труда на этапах логического проектирования (по точно заданным формальным спецификациям) и кодирования программ. А это значит, что производительность труда профессиональных программистов до сих пор измеряется числом строк кода программы. И это тогда, когда уже свыше половины общей численности мирового корпуса программистов - системные аналитики, которые нередко вообще не пишут ни одной строчки программного кода!

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

Есть основания предполагать, что именно здесь и проходит в настоящее время тот водораздел, который отделяет формальные аспекты науки программирования, традиционно обсуждаемые Ч. Хоаром, Э. Дейкстрой и другими цеховыми классиками, от практически решаемых за миллионами пультов встроенный в хозяйственный механизм промышленно развитых стран ЭВМ конкретных прикладных задач. Здесь уместно подчеркнуть, что сами по себе литературные произведения классиков программирования от этого, разумеется, не становятся ни менее ценными, ни хоть сколько-нибудь менее интересными. Как раз наоборот, и это в некотором смысле закон жанра. Программисты читают работы своих цеховых классиков, в том числе и данную статью Ч. Хоара, с таким же интересом, как, видимо, в свое время химики слушали музыку Бородина, а врачи читали "Записки врача" Вересаева... Разница, возможно, лишь в том, что эстетические достоинства произведений первых великих программистов, к сожалению, еще менее доступны широкой публике, чем музыка Бородина... Иными словами, статья Ч. Хоара, как и  многие из наиболее     известных     научно-публицистических     работ Э. Дейкстры (см., например, его "Избранные письма"), интересна как яркое произведение цехового, "камерного" искусства.

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


 

[2] Хоар Ч. Программирование как инженерная профессия // Микропроцессорные средства и системы. - 1984. - №4. - С. 53 - 60.

 

[3]Наряду с асами в любой профессии есть опасные для коллег и пациентов (заказчиков) посредственности. Их самолеты чаше оказываются в аварийных ситуациях, пациенты мучаются послеоперационными осложнениями, а заказчики программных комплексов ищут спасения в умиротворяющей формуле "и машины ошибаются".