Эдсгер Дейкстра - Научная фантастика и научная реальность в информатике

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

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

Для многих такое заключение неприемлемо, и как результат существует школа мышления — или, если вам так больше нравится, школа недомыслия, — которая утверждает, что ситуация не столь серьёзна, что нам не следует быть столь строгими, что инженеры всегда допускали периодические сбои своих компонентов, что стремление к совершенству быстро начинает препятствовать производительности, и что лучше бы нам научиться жить в реальном мире с системами и подсистемами, которые обычно делают то, что мы от них ожидаем. Это соблазнительное предложение. Разве не замечательно — достичь превосходства без гонки за совершенством?

(Тем более что в крайне популистском обществе последнее социально неприемлемо). Такова позиция, ныне принятая под знаменем «программной инженерии».

Однако то, что сторонники называют «прогрессом программной инженерии», страдает несколькими непреодолимыми противоречиями.

Одно из них — это то, что стремление к совершенству находится в противоречии с производительностью в том смысле, что сделает разработку программного обеспечения чересчур дорогостоящей. Но в чём основная причина заоблачных цен на неё? Дороже всего обходится как по людским ресурсам, так и по непредвиденным задержкам отладка, и можно немало сэкономить, вложив больше средств в предотвращение будущих ошибок, поставив разработку на первое место. Поскольку ошибки обходятся столь дорого, в конечном счёте высококачественный дизайн обходится куда дешевле. Другая важная причина состоит в том, что многие системы построены на зыбком фундаменте в том смысле, что базовое программное обеспечение в виде операционных систем и компиляторов слишком неустойчивы, поэтому каждый новый релиз этого базового программного обеспечения требует возможно дорогой адаптации базирующейся на нём прикладной части. Наконец, многие инструменты, с которыми собирается работать программист, настолько плохо документированы, что вынуждают его выяснять экспериментальным путём, чем же они могут оказаться для него полезными. Поскольку эти эксперименты могут быть весьма дорогостоящими и длительными, бедный программист оказывается в поистине незавидном положении, поскольку вынужден полагаться лишь на свои догадки. Так что вы видите здесь три основных источника роста цены, след от которых ведёт к чьему-то предположению, что стремление к совершенству противоречит производительности!

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

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

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

Ошибка очевидной неуправляемости этих двух документов кроется ни в двух группах, составивших их, ни в принятом ими формализме, а лишь в самом языке: сами не обеспечив формального определения, могут ли его разработчики скрыть, что они предлагают неуправляемого монстра. То, что Ada уменьшит проблемы программирования и увеличит надёжность наших разработок до приемлемых границ, — это лишь одна из тех сказок, в которые могут поверить только люди с военным образованием. Самое лучшее, что я могу сказать об этом, — это упорные слухи, что даже военного образования недостаточно, чтобы поддерживать веру в этот Философский Камень. Я упомянул про Ada, поскольку это замечательный пример того, на что я указывал в начале доклада: её принятие — это политический процесс, в котором информатике, предостережения которой рассматривались как досадная помеха, не было дозволено оказывать никакого влияния. Следовательно, даже простое согласие с чьим-то обоснованным сомнением на этот счёт, даже без вмешательства в контроль и намерения, становится действием с политическим душком.