Не ходите, дети, в Африку гулять

Вадим Артамонов

Не ходите, дети, в Африку гулять

Косяки в программах в роли аллигатора

Ошибки в программе так же неисчерпаемы, как и атом.
В. Тихонов. Теория ошибок

    Когда-то, давным давно, когда у ХТ был флоппи на 360К и память размером в 640К, программы были менее глючными. Это были еще те времена, когда dBase III пользовали с командной строки, а Ассистент с менюшками больше мешал, чем помогал. Так вот, за dBase тех времен особых глюков не замечалось. Все работало так, как должно работать. С переходом на монстров типа Windows ситуация изменилась. Библиотеки с нескольких сотен функций разрослись до нескольких тысяч, причем синтаксис вызова даже частоупотребимых приходилось сверять с "внешней памятью" в виде справочника.
    Впрочем, роль Главного Аллигатора сыграло даже не это, а массовый переход на С++ и объектно-ориентированное программирование (ООП). Некоторые, кстати, расшифровывают ООП как Определенно Оригинальный Прикол.
    Во многом с этим я согласен. Когда Керниган и Ричи делали UNIX, то они "сварганили" язык С для вполне конкретных нужд. А именно - для написания самой операционной системы и утилит к ней. Зато потом многие ринулись писать на С прикладные программы. Один программист говорил мне: "Написать программу - это не главное. Если ты за день написал ее, то еще дней десять будешь вылавливать ошибки".
    С приходом "гениально придуманного" С++ ситуация осложнилась. Если в таких языках как Pascal и Modula-2 то, как исполняются различные конструкции, вполне детерминировано и предсказуемо, то в С++ все это совершенно неочевидно, что приводит к весьма интересным результатам, вплоть до того, что код исполняется не в том порядке и не тот, который, по замыслу программиста, должен там присутствовать. Поэтому переход на ООП с библиотеками, по объему не хуже коллекции энциклопедий, является потенциальным провокатором на "встраивание" (естественно, неумышленное) ошибок в программы, выловить которые при размере программы больше мегабайта кода, является не такой уж легкой задачей. Жесткая верификация исходного текста программ (речь идет не о синтаксисе) помогает, но не так сильно, как хотелось бы.
    Давайте перейдем к примерам. Сподобился я поставить MS Office 2000 на компьютер. Поставил. Только вот при его запуске можно было увидеть морду доктора Ватсона, который с упоением сообщал, что программа благополучно грохнулась. Но при этом все остальные программы работали нормально. Падал только Офис. Попинав его пару дней, я так и не понял, где MS Office оказался несовместимым с MS Windows. Плюнул я на это дело и переустановил Винду с нуля, а первой установленной после таких зверств программой стал именно MS Office. Заработал, но факт остается фактом - при объеме в два компакта глюков и ошибок в этом ожиревшем монстре вполне хватает для того, чтобы жизнь не казалась медом. И это, надо заметить, финальный релиз!
    Бродят, кстати, слухи, что MS Office XP будет поставляться на четырех компактах, работать только в Windows 2000 или лучше и для запуска потребует 128М памяти. Еще бродят слухи, что в Microsoft нет компьютеров с диском меньше 20Гбайт. Ладно, поживем - увидим.
    Достаточно забавными на этом фоне выглядят косяки в Mozilla 0.8. Им простительно - бета все-таки.
Вот фрагментик html-кода, который генрируется Composer`ом:

<body>
<i> Вадим Артамонов</i><br>
<h2> Вперед, к мечте идиота</h2><br>

   Не так давно я мучил <a href="../a221100.html">Netscape Communicator 6.0</a>. А вот недавно

Ну в очень интересном месте стоят теги <br>. А еще М0.8 считает, что расширение .html является расширением "по умолчанию", поэтому сам он расширение "забывает" подставлять.

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

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

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