Фантазия или программирование?

Periculum in mora (лат) -
Опасность в промедлении.

Казалось бы, что еще нужно программистам и пользователям? Программы или их отдельные части работают, и даже параллельно, сообщения снуют туда-сюда и обрабатываются вроде бы как надо. О чем еще можно мечтать, когда и объектное программирование на подъеме, и визуальное "в самом соку"? Почему нет-нет, да и возникают разговоры о кризисе, в то время как компьютерный бизнес приносит большие прибыли, а пример Билла Гейтса многим программистам не дает покоя?

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

Кто виноват, или Учитесь быть осторожнее

Рассуждать на тему "Кто виноват?" - занятие безнадежное. Кто себя признает виноватым?! С "миной замедленного действия" - системой Windows - мы разбираемся, когда она сработала и "поезд уже ушел". Но раз уж мы попали в эту колею и покинуть ее сразу не в силах, то давайте подумаем, как сделать свою поездку комфортнее. Разберемся, так ли уж неудобна поездка и очень ли разбита колея. Мне кажется, ответ может звучать достаточно оптимистично.

В силу каких причин возникла эта проблема - низкое качество современных программных разработок? Многие склонны обвинять Windows и Билла Гейтса - мол, не туда завел. Однако не будем забывать: споткнувшись или набив себе шишку, лучше не обвинять кого-то, а задуматься если не о своей вине, то хотя бы об осторожности.

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

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

Но вот уже совсем недавно с экрана телевизора тот же Е. Велихов убежденно говорил, что учиться лучше в Кремниевой долине и что "пусть уезжают - все равно вернутся". С первым утверждением трудно не согласиться: сейчас там действительно лучше, так как здесь учиться скоро будет совсем не у кого - последние учителя или уйдут на пенсию, или уедут. А вот когда вернутся те, кто выучился, и вернутся ли вообще?.. И тогда, и сейчас такой "подход" и такая "агитация" у меня вызывали и вызывают гораздо больше вопросов, чем дают ответов.

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

Что делать?

Итак, что делать? Я предлагаю "обустраивать" теперь ту колею, в которую мы попали отнюдь не только по милости упомянутых Билла Гейтса и Евгения Велихова. В конце концов, силком нас никто не тянул, да и неправота инициаторов перехода на персоналки вовсе не очевидна: еще неизвестно, что было бы, например, в условиях господства DEC. (Заметьте, что о господстве отечественных технологий говорить уже никто не решается. А какие были планы развития вычислительной техники к 2000 году!) Хотя то, что разработчики VMS принимают самое активное участие в разработке Windows NT, тоже кое о чем говорит.

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

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

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

Измерения программы

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

Первое и второе измерение

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

Второе измерение появляется у программы, когда мы (явно или неявно) вводим возможность управления последовательностью выполнения команд. В процедурном программировании для такого управления служат операторы управления, в непроцедурном часто используются системы правил и соглашений. Механизмы управления позволяют вносить "управляемый хаос" в поток последовательности выполнения команд программы. Двумерная программа столь же разительно отличается от одномерной, как рисунок на плоскости - от отрезка прямой (пусть даже и очень длинного).

Большинство широко применяемых языков программирования в предложенной классификации должны быть отнесены к двумерным. Это относится и к объектно-ориентированным языкам, которые, несмотря на отличия в структуре программы, обладают в принципе теми же механизмами управления операторами, функциями программы (методами классов), что и процедурные языки. Интересно, что классы и объекты фактически одномерны, хотя и им второе измерение не помешало бы (о том, как это сделать, рассказано в моей статье "Игры с автоматами" - "Софт-Маркет", 1996, # 28-29).

Третье измерение

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

Идея параллелизма, несмотря на кажущуюся простоту, не так тривиальна. Более того, она настолько сложна, что сейчас нет общей теории и модели параллельных процессов. И этот пробел в теории приводит в реальной жизни к множеству параллельных решений, даже беглое рассмотрение которых оказывается очень сложным. Здесь и параллельный "старичок" Фортран, и операционные системы с "тяжелой" многозадачностью и "легкой" схемой конкурентного исполнения, и процессы и нити в Windows, и проблемы создания динамических виртуальных миров в Internet на базе языка VRML - столь обширный диапазон способен привести в уныние любого исследователя. Как же отделить решения, имеющие только два измерения, от действительно трехмерных?

Для этого следует использовать алгоритм или программу, которые будут правильно работать только в программной системе, имеющей три измерения. Здесь можно провести следующую аналогию. В одной из моих любимых книг - "Фантазия или наука..." Дмитрия Поспелова (Поспелов Д. А. Фантазия или наука: на пути к искусственному интеллекту. М.: "Наука", 1982) приводится задача: сложить из шести спичек четыре равносторонних треугольника. На плоскости задача решения не имеет, но с выходом в третье измерение оно появляется (спички нужно расположить в форме тетраэдра).

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

Одной из универсальных задач, тестирующих трехмерные свойства языка программирования, программной среды или системы, является задача моделирования RS-триггера. Она заключается в создании отдельных моделей-программ для составляющих RS-триггер логических элементов, между которыми для построения результирующей модели организуются связи в соответствии со схемой триггера. Устройство и схема работы триггера на двух логических элементах (И-НЕ или ИЛИ-НЕ) весьма просты и, пожалуй, известны любому программисту - они входят в "компьютерную азбуку".

Таблица истинности для RS-триггера

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

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

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

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

Выводы

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

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

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

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

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

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