Windows как предмет научного исследования

Мы уже говорили об эргономических недостатках Windows с точки зрения конечного пользователя ("Мир ПК", 5/96). Попробуем теперь на этом же ярком материале исследовать вопрос о возможности изучения современного инструментального программного обеспечения научными методами.

О науке вообще

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

Каждый объект или явление действительности характеризуется определенной степенью научной проработанности (изученности). Таких степеней можно выделить три:

1) высокая: для изучения объекта достаточно чтения литературы;

2) средняя: для изучения объекта необходимо обращение к не зафиксированному в письменном виде (возможно, и не вербализованному, т. е. не сформулированному словами) опыту профессионалов;

3) минимальная: для изучения объекта необходимы специальные научные исследования.

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

1) постановка задачи;

2) метод исследования (обычно выбирается из общепризнанных научных методов);

3) методика исследования, состоящая в применении метода к поставленной задаче;

4) выводы (обобщенные и осмысленные результаты).

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

Ниже мы попробуем показать, что инструментальное программное обеспечение в его современном состоянии имеет третью (минимальную) степень изученности, т. е. для получения знаний о нем требуется специальное научное исследование, и что для осуществления такого исследования имеются все необходимые предпосылки. Мы будем основываться на опыте переноса интегрированного статистического пакета Stadia (см. "Мир ПК", 3/92) из среды DOS в среду Windows с использованием пакета Delphi 1.0. Этот пакет мы считаем лучшим из доступных инструментов; в другом случае выводы могли бы быть существенно печальнее.

Изложение вынужденно будет носить тезисный характер: в деталях оно значительно превысило бы возможности журнальной публикации.

Общее состояние

Современное состояние и тенденции развития программных средств можно вкратце охарактеризовать следующим образом.

1. Свалки инструментов. Поскольку при переносе на каждую новую платформу пакет для разработки программ "обрастает" все новыми инструментами, а старые при этом сохраняются (по уверениям разработчиков, ради совместимости), все современные пакеты стали напоминать свалки, забитые всевозможным хламом. Вдобавок, несмотря на обилие инструментальных средств, разработка серьезных приложений невозможна без использования низкоуровневого Windows-инструментария (API-интерфейса), а соответствующие библиотеки в не меньшей степени замусорены плохо документированными функциями, определениями с историческими дубликатами и вариантами.

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

2. Ошибки и упущения. Многие вновь введенные компоненты, несмотря на всемирное распространение, полны очевидных ошибок и упущений, которые никто даже не пытается исправлять. Создается впечатление, что либо никто в мире никогда серьезно с этими компонентами не работал, либо разработчики не заинтересованы в контактах с пользователями и не считают своим долгом быстро реагировать на полученные замечания.

В ряде случаев упущения и ошибки делают компонент совершенно бесполезным в практике, что не мешает ему привлекать внимание потенциальных потребителей обилием возможностей и вселять в них надежду на значительное сокращение затрат личного труда в будущем. К такого рода побрякушкам-безделушкам в Delphi и Visual Basic следует отнести графопостроитель ChartFx и пакет-компаньон Visual Solution Pack (с электронной таблицей, графопостроителем и текстовым процессором). Есть серьезные упущения и в базовых средствах для разработки текстовых редакторов (Memo) и графопостроителей (Canvas, Image), в средствах работы с большими массивами и другие.

3. Совместимость несовместимого. О проблемах совместимости можно говорить отдельно и долго. Взять хотя бы шрифты. Действительно, для творцов из метрополии проблемы, связанные с национальными языками и шрифтами, интереса не представляют. Они придумали для себя в API несколько способов заказа шрифтов и еще кучу неопубликованных (и забытых ими самими) правил о том, как эти заказы будут интерпретироваться в каждой из подверсий Windows и в каждом из неимоверного множества сочетаний уже установленных шрифтов. В результате вы покупаете некий метропольный инструмент (пусть, например, это будет известный Picture Publisher 4.0), вставляете его в свое собственное приложение и продаете это приложение тысячам потребителей по всей необъятной Евразии. После этого вам начинают непрерывно звонить с Таймыра, с Чукотки или из "Президент-отеля" и возмущаться: "После установки CorelDraw в Windows для чтения надписей в вашем пакете нужна не просто лупа, а и постоянное присутствие опытного криптолога!"

Заявления о совместимости последовательных версий одного и того же продукта часто оказываются, мягко говоря, несколько преувеличенными - здесь обычны множественные неафишируемые изменения. Иногда такие новшества приводят к тому, что после загрузки вашего приложения в новой версии Windows все другие приложения вдруг начинают реагировать на нажатие любой клавиши выдачей сообщения об ошибке. Правда, это происходит только в некоторых модификациях среды и далеко не во всех возможных ее конфигурациях. "Что поделать, - скажут вам, - принципы распределения памяти изменились, и невозможно было прогнозировать, как это проявится в миллионах жизненных ситуаций!" Единственный выход - срочно вылететь в один из их соединенных штатов и проводить на месте дознание с перекрестным допросом, к примеру, специалистов Borland International и Microsoft Corporation...

4. От непонятного - к непонятнейшему. Над многомегабайтными инструментальными пакетами громоздятся еще надстройки вроде CASE-технологий или нейронных сетей. Искусственный интеллект, несмотря на свое поражение в 80-х годах, никак не может примириться с первенством естественного. Четверть века назад нейронные сети научились с грехом пополам возить тележки на колесиках. За это время в области вождения тележек они мало продвинулись, зато очень хорошо научились водить за нос бизнесменов и банкиров.

Сколько же ошибок и лакун можно при наличии желания (и времени) найти в суперсложных (и элитарных) CASE-системах, если они кучей навалены даже в простейших (и массовых) программных средствах?! Но все искусственно-интеллектуальные системы срабатывают одинаково, толкая человека заниматься любимым делом - предаваться наивной и слепой вере в близкое счастье и избавление от каждодневных проблем.

А мечты о том, что по мере развития компьютерных технологий будет упрощаться и ускоряться процесс программирования, и не думают сбываться. Создание приложений в среде Windows многократно усложнилось, поэтому и цена Windows-продуктов стала в полтора-два раза выше цены их аналогов для среды DOS. Скачок цен произошел несмотря на значительный рост объемов продаж. Уместно ли в такой ситуации говорить о прогрессе в разработке программ?

Объектно-ориентированное программирование

С приходом Windows идеология ООП начала распространяться со скоростью массового психоза. ООП считали панацеей от всех бед (в частности, от процедурно-ориентированного программирования). Вместо того чтобы мыслить забивание гвоздя в терминах действий: взять молоток и гвоздь, приставить гвоздь острием к стене и ударять молотком по гвоздю до достижения нужного результата, ООП предлагает решать задачу в терминах индивидуальных физических свойств гвоздя, молотка и стены и их реакций на внешние события.

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

Начальное внедрение ООП в интерпретации Си++ превратило программирование в сущий кошмар, когда разработчику приходилось следить за синхронизацией обработки сотен событий с неимоверной по объему и рутинности детализацией. Положение до некоторой степени спасла концепция визуального программирования (обобщение и системная реализация - упрятывание типовых штампов) в интерпретации Visual Basic и Delphi. К счастью, ее авторы своевременно осознали необходимость глобального процедурирования и создали для его реализации ряд замаскированных приспособлений типа режима Show Modal (обеспечивает задержку выполнения вызывающей процедуры до закрытия вызванного окна).

Полезно вспомнить, что творилось в прессе всего лишь год назад: сплошные победные реляции по поводу завоеваний объектным программированием очередных вражеских территорий. Затем массовый психоз перекинулся на системы клиент-сервер, далее - на Всемирную паутину. Нет, жить в таком мире совсем не скучно!

ООП действительно весьма эффективно, но только в том крайне ограниченном классе областей, где основную роль играют объекты (окна в современном диалоговом интерфейсе, документы в канцелярской и банковской деятельности и т. п.), и только тогда, когда с такими объектами связаны строго определенные и независимые процедуры обработки.

Программная документация и опыт специалистов

Можно ли изучить современный программный продукт, пользуясь прилагаемой к нему документацией? По-видимому нет, ведь ее объемы уже приближаются к монументальным собраниям сочинений, значительно превосходя обычные человеческие способности к запоминанию и осмыслению.

Но это еще полбеды! Буквально на каждом шагу возникает ситуация, когда, перелистав многие тома документации или исколесив вдоль и поперек необозримые экранные справочники, можно так и не найти ответ на самый элементарный вопрос просто из-за того, что его там нет. С другой стороны, бывает и так, что в одном разделе дается одно определение чего-то, а в другом - другое, прямо противоположное первому. Именно поэтому книжные магазины оказались завалены руководствами и сборниками советов по каждому популярному пакету, растолковывающими то, что забыли сказать авторы. Почему-то в эпоху DOS дело обстояло совершенно иначе.

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

Проще всего, конечно, спросить прямо у разработчиков. Но в любой солидной корпорации вас к ним и близко не подпустят. Типичные ответы отдела технической поддержки на принципиальные вопросы (а не на вопрос о том, каким пальцем на какую кнопку лучше нажимать) будут следующими: 1) такого у нас еще не встречалось (ждите ответа...); 2) попробуйте еще раз, может, вы просто ошиблись; 3) приобретите модернизированную версию, вдруг там будет лучше; 4) мы уже не сопровождаем этот продукт (и не знаем, кто сопровождает); 5) обратитесь в наш европейский филиал (оттуда вас пошлют в п. 6); 6) обратитесь к своему дилеру (оттуда вас пошлют в корпорацию, см. п. 1).

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

Кто виноват?

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

Теперь, если в каком-то компоненте готового пакета какой-то дотошный пользователь обнаруживает ошибку, то исправлять ее уже некому. В отсутствие автора (автор уже совсем в другом месте и решает совсем другие задачи) затраты на изучение компонента и локализацию ошибки (сколь бы исчерпывающей ни была сопроводительная документация) сравнимы с затратами на научно-исследовательскую работу (это все равно что для починки кухонной сковородки приглашать мастера Фаберже). Проще или совсем отказаться от этого компонента, или написать его заново. Тем более что у корпорации готова уже следующая версия пакета, призванная сокрушить всех конкурентов. Снова платите денежки, пользователи, - и будете счастливы!

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

Беда наша в том, что все мы подсознательно убеждены: в современную эпоху мощные программные продукты на коммерческом уровне можно создавать, только привлекая большие коллективы исполнителей и распространителей, а также финансовые корпорации. В действительности это не так, и масса примеров показывает, что даже и сейчас один-единственный человек способен не только создать несколько высоконаукоемких и конкурентоспособных продуктов, реализовав в них еще и ряд новых идей, но и собственными малыми силами обеспечить всю необходимую рекламу, маркетинг, сопровождение и развитие (правда, разбогатеть ему на этом вряд ли удастся). Опыт подобной разработки есть и у автора (см. "Мир ПК", 2/94, 8/94, 1/95).

Истоки

Многие были свидетелями, но уже мало кто вспоминает о том, что заря Windows занялась во второй половине 1992 г. с беспрецедентного кругосветного пропагандистского турне руководства Microsoft с массой речей и выступлений на сотнях бизнес-встреч, семинаров и международных выставок. Главной целью этой акции было всколыхнуть мировую общественность, увлечь за собой и привязать к себе ведущих мировых производителей, которые после переориентации своих перспективных разработок (и связанных с этим капитальных вложений) уже не смогут отклониться от магистрального пути. А уж за ними поплетутся массы пользователей, быстро привыкающие считать такой мир единственным (как говорится в рассказе Виктора Пелевина "Вести из Непала", "не знавшие ничего, кроме жизни, они принимают за жизнь и смерть"). Этот замечательный пример показал всем сообразительным, что затраты на рекламу значительно эффективнее, чем затраты на кропотливое "долизывание" продуктов. Поэтому с приходом Windows началась и резкая деградация качества программного обеспечения, и его усложнение. Тем самым несомненной заслугой Билла Гейтса является открытие и наглядная демонстрация сверхмощных механизмов массового порабощения в эру информационной цивилизации. Это - высокий идеал успеха, к которому будут напряженно стремиться еще многие поколения служителей.

Что делать?

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

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