Format C:

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

Как-то раз я уже жаловался во всеуслышание на летние глюки своего ноутбука, на что получил от одного сердобольного читателя ответ примерно следующего содержания: «А не фига пользоваться всякими альтернативными платформами». Увы, платформа самая что ни на есть безальтернативная - Intel+Microsoft. С одной стороны, давно пора применить стандартный пользовательский прием «Format C:» и так далее, с другой - жалко отлаженную и проработавшую всего пару недель инсталляцию, да и ошибка столь нетипична, что интересно понять причину - а вдруг не только мне поможет решение? Процесс интимного общения с упомянутым аппаратно-программным комплексом уводит в мистические дебри: когда абсолютно исправные по отдельности компоненты, будучи собраны вместе, дают в сумме абсолютно неработоспособную систему, поневоле задумаешься о вмешательстве высших сил. Благо, инженерно-техническое образование не позволяет углубиться в подобные размышления.

Вместо этого с грустью вспоминаются времена старых добрых ОС RSX/RSTS/RT11 и даже MS-DOS, вопрос о стабильности работы которых не возникал вообще. Разумеется, мне могут возразить, что количество ошибок пропорционально объему кода и по моим давним прикидкам, хороший программист делает в среднем одну ошибку на сотню написанных команд. Результат нехитрого подсчета получается удручающим: при таких «входных данных» даже 99-процентное вылавливание ошибок на этапе тестирования должно оставить мне тысячи потенциальных причин происходящего.

Предположим, аппаратную платформу, работающую без ошибок, реализовать можно. Другое дело, что любая нынешняя компьютерная «железяка» давно уже не чисто аппаратная - сплошь и рядом ее работой управляет встроенный микрокод, а вопросы ошибок в программах скоро можно будет выносить в отдельную научную дисциплину. Компьютерные теоретики до сих пор спорят о том, каким должен быть идеальный язык программирования. Вернее, пытаются найти оптимум на отрезке между «все, что не разрешено, - запрещено» и «все, что не запрещено, - разрешено», иначе - компромисс между количеством ошибок, отлавливаемых на этапе компиляции и легкостью написания программы. Первая крайняя точка отрезка - языки, берущие начало из работ Никлауса Вирта: тот же классический PASCAL - отрада теоретиков, никогда не писавших чего-либо более практичного, чем итерационная процедура вычисления квадратного корня. На противоположном конце - нечто близкое к C++, столь милому сердцу любителей поковыряться во внутренностях компьютера и ненавидящих структурные типы данных. За годы развития «персоналок» и ПО для них признание получил именно этот язык -всегда приятно, когда все разрешено всё. Приверженцы структурного программирования в результате вынуждены были отступить и, сохранив лозунг, принять в свои ряды отщепенцев. А что же им было делать, когда красивая и абсолютно структурная программа с использованием, например, рекурсии, вдруг натыкается на вызов системной функции, не являющейся реентерабельной? Основатели нынешней софтверной империи о теоретической красоте заботились мало, иначе неизвестно еще стала бы империя империей…

Объектно-ориентированные средства позволяют немного подняться над этой суетой, но, будучи сами «выходцами из народа», несут на себе тяжкое наследие: насколько помнится, та же Delphi создана на C++, не говоря уж о ее компонентах. В комбинации с написанным «задней левой» API получается гремучая смесь.

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