Конец восьмидесятых. Всего два года я отсутствовал на родном
предприятии, а меня встретил уже меняющийся компьютерный мир. В
отделах стали появляться персоналки: у кого IBM-PC/XT, у кого
Правец, а у кого ЕС-1840. Число пользователей БЭСМ-6 и даже ЕС и
СМ-4 стало асимптотически приближаться к нулю. На фоне новых
возможностей все их фишки сразу побледнели. Например, смешно, что
еще недавно какая-нибудь замена терминала VT-340 на VT-52100 c
памятью на 5 страниц, позволяющей вводить текст еще до включения
БЭСМ, казалась важной.
Расстаться со старыми заделами и навыками психологически мне было
даже проще, чем многим, поскольку после двухлетнего отсутствия я
вернулся на работу уже в другой отдел и, так сказать, сразу отрекся
от старого мира и отряхнул его прах со своих ног.
Впрочем, последние годы работа с БЭСМ-6 через диалоговую программу Пульт разработки МГУ, как раз очень напоминала работу за первыми персоналками и поэтому переход был несложным.
А вот задачи стали другие. Отдел занимался разработкой ПО
системы управления Энергия-Буран. Точнее, отдел занимался
комплексацией, верификацией, взаимодействием с наземным ПО и т.п.,
а собственно разработкой занималось сразу несколько отделов. Я
впервые принимал участие в проекте, где были заняты десятки
программистов. Язык программирования ПРОЛ-2 разработки ИПМ АН
СССР.
Вообще-то, девичья фамилия этого языка была Пролог-Ц от
ПРОграммирования ЛОГики. А литера Ц - это, вероятно, ЦУП. Но
поскольку в то время на слуху был японский Пролог с его
транспьютерами, вероятно разработчикам надоело отвечать на вопросы
о применении транспьютеров в Буране, поэтому вторая версия языка
вышла под таким скромным и безликим именем.
Язык был специфический, для задач управления. Типичный алгоритм
выглядел так: выдать такую-то команду, подождать 0.3 миллисекунды,
проверить такую-то переменную. Если она нулевая выдать другую
команду и запустить такой-то процесс. И все в таком духе.
Разумеется, инструментальных средств под x86 еще не было. Поэтому в
отделе родилась идея, а затем предложение указание распоряжение
создать отладочный или, точнее, проверочный транслятор для
персоналки. Во-первых, он облегчит процесс комплексирования и
верификации, а во-вторых, возможно, несколько увеличит
производительность и в других отделах, сократив число подходов к
штатному транслятору (на ЕС ЭВМ).
Сказано-сделано. Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.
В то время было модно извлекать из внутреннего динамика персоналки разные звуки. Ребята из моего бывшего отдела даже спаяли простой АЦП на параллельный разъем и через микрофон от древней Яузы-5 мы записали ряд сигналов и фраз.
Например, при отсутствии замечаний проверочный транслятор
бесцветным голосом произносил (больше подходит: сипел) половинку
подходящего к случаю т.н. заходеризма (афоризма Б. Заходера):
если взглянуть формально, все обстоит
нормально.
А описываемая история произошла в момент, когда в почти
торжественной обстановке состоялся первый прогон через проверочный
транслятор множества уже готовых и проверенных модулей.
Для повышения надежности в языке ПРОЛ-2 описание нелокальных
переменных должно было включать и права доступа в виде списка имен
процедур, которым разрешается к этой переменной обращаться.
Отдельный список прав на чтение и отдельный список прав на
запись.
Так вот, проверочный транслятор выдал большое число сообщений, что
идет обращение к переменным без права доступа. Отдельческое
начальство поморщилось: дескать, уж такую несложную ветку в
проверочном трансляторе можно было бы сделать с первого раза и без
ляпов. Штатный транслятор давно отлажен и многократно проверен.
Таких нарушений он бы просто не пропустил. Откуда в проверенных
программах взялись сотни ошибок доступа?
Но разбирательство показало, что таки-да, в штатном трансляторе
помарка. Вероятно, она проникла в транслятор, когда выяснилось, что
ресурсов одной БЦВМ не хватает и приняли решение поставить в Буране
две машины, разделив ПО между ними. Транслятор подправили для двух
ЭВМ, но он перестал проверять права доступа переменной из процедуры
на соседней БЦВМ (или, наоборот, на той же, я уже не помню). В
общем, выключилась одна из проверок.
После выяснения этого факта даже было совещание. Не столько на тему
помарки в трансляторе, сколько на тему философии и технологии
разработки. Ведь рассчитывали на что? Что разработчики
проанализируют область действия каждой переменной и явно и
осмысленно укажут множество объектов, которые могут эту переменную
читать/писать.
А что получилось в реальности? Разработчики чихали на анализ и
совали свои модули в транслятор. Ругнулся он по поводу прав так и
быть допишем список, не ругнулся и так сойдет. И при этом все
работало нормально и казалось, что защита от порчи чужих данных
хорошо обеспечена.
Лично я не считаю допустивших это программистов какими-то
балбесами, не соблюдающими элементарные правила. Все силы и
внимание уходили на разработку самих алгоритмов, отработку их
взаимодействия на стенде, анализ парирования нештатных ситуаций и
т.п. А на правила записи уже не хватало ни внимания, ни
желания.
А что, разве при отработке не было случаев, когда один процесс
портил переменную другому процессу? Конечно, были. Только во всех
этих случаях как раз с правами доступа все было хорошо.
С тех пор прошло уже десятка три лет. Программирование и
теоретически и практически ушло далеко вперед и добилось больших
успехов.
Но когда я читаю о новом языке, который просто не позволит вам написать ошибочную конструкцию, о том, что какая-нибудь инкапсуляция или запрет преобразования типов автоматически сделают вашу программу надежной и правильной и о прочих, ежедневно отливаемых серебряных пулях, я нет-нет, да и вспомню ту давнюю историю, как иллюстрацию того, что формальные методы борьбы за правильность и надежность чаще всего дают и формальные же результаты.
В духе так и не озвученной нами в трансляторе второй половины афоризма Бориса Заходера.