Создание сайтов: лендинг, визитка, интернет магазин. Продвижение, поддержка, реклама.

Конец восьмидесятых. Всего два года я отсутствовал на родном предприятии, а меня встретил уже меняющийся компьютерный мир. В отделах стали появляться персоналки: у кого IBM-PC/XT, у кого «Правец», а у кого ЕС-1840. Число пользователей БЭСМ-6 и даже ЕС и СМ-4 стало асимптотически приближаться к нулю. На фоне новых возможностей все их «фишки» сразу побледнели. Например, смешно, что еще недавно какая-нибудь замена терминала VT-340 на VT-52100 c памятью на 5 страниц, позволяющей вводить текст еще до включения БЭСМ, казалась важной.

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

Впрочем, последние годы работа с БЭСМ-6 через диалоговую программу «Пульт» разработки МГУ, как раз очень напоминала работу за первыми персоналками и поэтому переход был несложным.

А вот задачи стали другие. Отдел занимался разработкой ПО системы управления «Энергия-Буран». Точнее, отдел занимался комплексацией, верификацией, взаимодействием с наземным ПО и т.п., а собственно разработкой занималось сразу несколько отделов. Я впервые принимал участие в проекте, где были заняты десятки программистов. Язык программирования – ПРОЛ-2 разработки ИПМ АН СССР.

Вообще-то, девичья фамилия этого языка была «Пролог-Ц» от ПРОграммирования ЛОГики. А литера «Ц» – это, вероятно, ЦУП. Но поскольку в то время на слуху был японский Пролог с его транспьютерами, вероятно разработчикам надоело отвечать на вопросы о применении транспьютеров в «Буране», поэтому вторая версия языка вышла под таким скромным и безликим именем.

Язык был специфический, для задач управления. Типичный алгоритм выглядел так: выдать такую-то команду, подождать 0.3 миллисекунды, проверить такую-то переменную. Если она нулевая – выдать другую команду и запустить такой-то процесс. И все в таком духе.

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

Сказано-сделано. Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.

В то время было модно извлекать из внутреннего динамика персоналки разные звуки. Ребята из моего бывшего отдела даже спаяли простой АЦП на параллельный разъем и через микрофон от древней «Яузы-5» мы записали ряд сигналов и фраз.

Например, при отсутствии замечаний проверочный транслятор бесцветным голосом произносил (больше подходит: сипел) половинку подходящего к случаю т.н. «заходеризма» (афоризма Б. Заходера): «если взглянуть формально, все обстоит нормально».

А описываемая история произошла в момент, когда в почти торжественной обстановке состоялся первый прогон через проверочный транслятор множества уже готовых и проверенных модулей.

Для повышения надежности в языке ПРОЛ-2 описание нелокальных переменных должно было включать и права доступа в виде списка имен процедур, которым разрешается к этой переменной обращаться. Отдельный список прав на чтение и отдельный список прав на запись.

Так вот, проверочный транслятор выдал большое число сообщений, что идет обращение к переменным без права доступа. Отдельческое начальство поморщилось: дескать, уж такую несложную ветку в проверочном трансляторе можно было бы сделать с первого раза и без ляпов. Штатный транслятор давно отлажен и многократно проверен. Таких нарушений он бы просто не пропустил. Откуда в проверенных программах взялись сотни ошибок доступа?

Но разбирательство показало, что таки-да, в штатном трансляторе помарка. Вероятно, она проникла в транслятор, когда выяснилось, что ресурсов одной БЦВМ не хватает и приняли решение поставить в «Буране» две машины, разделив ПО между ними. Транслятор подправили для двух ЭВМ, но он перестал проверять права доступа переменной из процедуры на соседней БЦВМ (или, наоборот, на той же, я уже не помню). В общем, выключилась одна из проверок.

После выяснения этого факта даже было совещание. Не столько на тему помарки в трансляторе, сколько на тему философии и технологии разработки. Ведь рассчитывали на что? Что разработчики проанализируют область действия каждой переменной и явно и осмысленно укажут множество объектов, которые могут эту переменную читать/писать.

А что получилось в реальности? Разработчики чихали на анализ и совали свои модули в транслятор. Ругнулся он по поводу прав – так и быть допишем список, не ругнулся – и так сойдет. И при этом все работало нормально и казалось, что защита от порчи «чужих» данных хорошо обеспечена.

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

А что, разве при отработке не было случаев, когда один процесс портил переменную другому процессу? Конечно, были. Только во всех этих случаях как раз с правами доступа все было хорошо.

С тех пор прошло уже десятка три лет. Программирование и теоретически и практически ушло далеко вперед и добилось больших успехов.

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

В духе так и не озвученной нами в трансляторе второй половины афоризма Бориса Заходера.