Национальные информационные ресурсы:
проблемы промышленной эксплуатации.
Г.Р.Громов. Москва, Наука, 1984

 

Математика в программировании: «проблеск надежды»?

В непрекращающихся уже свыше 30 лет попытках любой ценой заложить математические основы науки программирования (Mathematical foundation of software science) нередко упускается из виду то, как развивался процесс математизации в других инженерных дисциплинах.

Как известно, в традиционных областях инженерной деятельности процесс математизации не только не является самоцелью, но и не рассматривается как панацея в борьбе с растущей сложностью решаемых инженерных задач. Математический аппарат является лишь одним из; инструментов, нередко весьма важным, но, как правило, не основным при решении проектных, конструкторских и технологических задач. Было бы заблуждением считать, что такая ситуация сложилась лишь в тех инженерных дисциплинах, которые достигли высокого уровня развития до. первых попыток внедрения туда математических средств; формализации инженерного мышления. Чтобы убедиться,, что это не так, достаточно, например, рассмотреть ситуацию, сложившуюся в радиотехнике, электронике и связи — исторически новых инженерных дисциплинах, которые, с одной стороны, ненамного старше программирования, а с другой — «родились из уравнения», во всяком случае, если иметь в виду уравнения Максвелла.

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

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

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

С началом микропроцессорной революции граница между аппаратными и программными средствами преобразования информации начала расплываться. Инженер-электронщик, который еще в начале 60-х годов, когда программисты уже пользовались преимуществом языка высокого уровня, писал свои «программы» (принципиальные схемы) на языке электронных схем уровня «ниже ассемблера» (дискретные компоненты), к концу 70-х годов с появлением интегральных схем (ИС) повысил этот уровень до эквивалента ассемблера. Затем уже к середине 70-х годов стали широко доступны большие интегральные схемы (БИС), которые поднимают уровень «языка схем» разработчика электронной аппаратуры до сопоставимого с языком программирования высокого уровня, и, наконец, на рубеже 80-х годов массовыми компонентами электронного оборудования, какими в начале 60-х годов были транзисторы, становятся микропроцессорные наборы, а затем и однокристальные микро-ЭВМ. Последний барьер, отделяющий: технологию создания средств аппаратного преобразования  информации от программирования, исчезает в начале 80-х годов, по мере того как основные функции нижнего уровня компонентов электронных схем—микропроцессоров оказывается необходимым задавать  программным  путем.  Какую  часть  схемотехнического решения «паять», а какую  «программировать», определяют уже только конкретные условия поставленной разработчику инженерной задачи.

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

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

Автор монографии «Проектирование микропроцессорных систем», президент исследовательской   фирмы  «Кибернетик микро систем»   («Cybernetic Micro Systems»)   Э.  Клингман подчеркивает,  что  цифровые  блоки  на  интегральных  схемах  «трудно  описать  математически.   При проектировании комбинационных  схем можно  использовать полу матричные методы, такие, как метод карт Карно или методы Квайна и Мак-Класки,  но область их применения в  значительной степени ограничена. При введении сложных временных со­отношений эти методы становятся бесполезными.  Диаграммы переходов являются превосходным инструментом анализа  систем,  однако с точки зрения проектирования стандартных цифровых блоков они оставляют желать много лучшего. Были разработаны классические методы минимизации количества  вентилей, но стоимость  вентилей сейчас невелика и продолжает снижаться так, что целесообразность работы в этом направлении становится сомнительной...» [19, с. 23].

Э. Клингман понимает уровень «академического риска», который связан с любыми сомнениями в истинности основных догматов о неограниченном всесилии математических методов (ведь даже в волшебной сказке лишь самому безответственному и непростительно наивному мальчику разрешал Андерсен громко произнести: «Король голый!»). Есть вещи, о которых в рамках той или иной профессиональной группы многие могут знать, но говорить о них, тем более в печати, не примято. Поэтому Э. Клингман, объясняв реальную ситуацию (без чего он, как и Э. Йодан. просто не смог бы дать в последующих главах книги какою-либо представляющего практическую ценность изложения исследуемой им технологии), считает нужным объясниться с оппонентами уже па их языке: «Проработав в течение десяти лет в области математической физики, я могу себе представить, что это утверждение может обескуражить некоторых читателей, полагающих, что всякая область знаний, не имеющая математической основы, сомните льна. Среди тех, кто понимает красоту и мощь строгого математического утверждения, существует тенденция упускать из виду некоторые ограничения, присущие математическому языку в отличие от естественного. Во многих областях математика становится настолько трудной для понимания, что в качестве вспомогательного средства в интуитивном аналою используют диаграммные методы. В течение длительного периода ото было характерно для таких областей, как химия и электротехника, по в последнее время и в теоретической физике появились диаграммы Фейнмана и Голдстоуна. В большинстве случаев при проектировании цифровых систем достаточно использовать диаграммы логических схем, дополняемые описаниями па естественных языках. Некоторые фирмы и университеты используют в системах машинного проектирования более мощные полуматематические1 методы, которые, по всей видимости, получат дальнейшее развитие» [19, с. 23].

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

За четверть века до того, как печально знаменитая формула: «Отлаженная программа никому не нужна» — оказалась общей эпитафией для 90% профессионально создаваемых прикладных программ, Р. Хемминг заложил два краеугольных камня в основание науки программирования: 1) цель машинной обработки — понимание, а не числа; 2) прежде  чем решать задачу, подумай, что делать с ее решением.

Однако хотя книга «Численные  методы» [20], в которой Хемминг (один из первых президентов АСМ, руководитель математического отделения «Белл лабс») в каждой ее главе в разной форме, но с одинаковой настойчивостью подчеркивал эти два основных положения прикладного программирования, и оказалась  настольной для нескольких  поколений программистов, отмеченные  им  основные положения (видимо, из-за их простоты и очевидности) не встретили того внимания и практического интереса, как математические выкладки, которые они сопровождали.

Потребовалось еще 25 лет развития вычислительной техники, бурное расширение областей приложений ЭВМ, выз­ванное микропроцессорной революцией, чтобы к началу 80-х годов стало ясно, что в 9 случаев из 10 единственным, но фатальным методологическим упущением при создании прикладных программ оказывается несоблюдение двух простых по смыслу, но труднейших в реализации требований Хемминга.

По основному своему содержанию книга Хемминга посвящена, казалось бы, лишь вычислительным, т. е. наиболее математическим, аспектам программирования, однако всякий раз, когда Хемминг как математик ставит в ней ключевые вопросы организации вычислительного процесса, он подчеркивает, что ответы на них «должны быть найдены в первоначальной задаче, а не в математических трактатах2 или даже книгах по численному анализу» [20, с. 99]. Пытаясь обратить внимание математиков и программистов на особое значение этих обычно остающихся в тени аспектов молодой инженерной дисциплины, только еще выкарабкивающейся на свет божий из своего математического кокона, Хемминг выделяет следующий текст курсивом: «Здравая вычислительная практика требует постоянного исследования изучаемой задачи не только перед организацией вычислений, но также в процессе его развития и особенно на той стадии, когда полученные числа переводятся обратно и истолковываются на языке первоначальной задачи» [20, с. 99].

Но как выполнять эти исследования предметной области (по Хеммингу — первоначальной задачи)? Отметив, что он тоже, как, по-видимому, и читатель, этого не знает, Хемминг затем подчеркивает, что здесь вообще начинается наиболее трудная не только для программирования область исследований. Указав на две разделенных тысячелетиями классические работы, посвященные постановке математических задач: «Метод» Архимеда и «Как решать задачу» Пойа, он подчеркивает причину принципиальной несводимости прикладного программирования к решению математических задач: «Однако оба этих автора занимались решени­ем точно сформулированных задач, тогда как нам интересно, что делать, когда задача поставлена нечетко и столь же неопределенны условия, которым должны удовлетворять результаты» [20, с. 392].

В эпоху расцвета «культа» центрального процессора, когда только формировалось ядро элиты элит профессиональных программистов — системные программисты, которым предстояло разработать операционные системы и орга­низовать пакетный режим обработки данных (надолго отлучив, таким образом, пользователей от пульта ЭВМ)Г Хемминг убеждал: «Если ставится задача попять физическое явление, то автор задачи должен понимать и контролировать процесс обработки данных ... Опыт показывает,— разъясняет он эту точку зрения,— что обычно и легче и лучше научить специалиста в конкретной области и математике и программированию, чем наоборот3. Но если мы требуем этого от заказчиков, то долг вычислителей приложить все усилия к тому, чтобы уменьшить для них трудности обучения. Произвольные правила, особый жаргон, бессмысленный формализм, изменения в методах и обозначениях, препятствия в получении времени — все это должно быть сведено к минимуму» [20,  с.   397].  Трудно,  видимо, и сегодня дать более четкое обоснование необходимости организации режима персональных вычислений и условий для его реализации.

Отмеченные выше общие закономерности развития инженерных дисциплин дают основания предполагать, что «проблеск надежды превратить программирование в занятие с твердой и солидной математической основой» [9, с. 13], о котором напоминал в середине 70-х годов Э. Дейкстра, будет, видимо, появляться и в будущем, но постепенно все реже и реже.....

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

Первое: задача любого вида сводится к математической задаче.

Второе: математическая задача любого вида сводится к алгебраической задаче.

Третье: любая алгебраическая задача сводится к решению одного-единственного уравнения.

Чем больше объем ваших знаний,— подчеркивает Пойа,— тем больше пробелов вы можете усмотреть в этой программе» [23, с. 45].

Анализируя необычайную стойкость такого типа философских иллюзий, которые столетиями умирали и возрождались в различных областях науки, причем в ряде случаев, подобно, например, этапу алхимии в химии, на этом пути появлялись положительные результаты4 до того, как бесплодность «великой мечты» была научно доказана, Пойа приходит к выводу, что дело заключается, видимо, в осо­бенностях человеческого интеллекта: «Решение задач является специфической особенностью человеческого интеллекта, а интеллект — это особый дар человека; поэтому решение задач может рассматриваться как одно из самых характерных проявлений человеческой деятельности ... Решение задач — практическое искусство, подобное плаванию, катанию на лыжах или игре на фортепиано; научиться ему можно, только подражая хорошим образцам и постоянно практикуясь. Конечно, подражать уже известному решению легко, если новая задача очень похожа на известную вам; однако если сходство задач невелико, то такое подражание может оказаться гораздо более трудным и даже едва ли осуществимым» [23, с. 13].

Именно в этой трудности решения практических задач, методологически проистекающей из многообразия окружающего нас мира, который, постоянно изменяясь, успешно ускользает от всех попыток втиснуть его в рамки какого-либо универсального метода или формальной схемы, заключается, видимо, причина тяготения некоторых ученых (в том числе и многих по-настоящему великих) к неосознанной вере в существование некоего (математического или иного) универсального  метода: «В глубине души,— объясняет Пойа,— человек стремится к большему: ему хотелось бы обладать универсальным методом, позволяющим решить любую задачу. У большинства из нас это желание остается скрытым, но иногда оно проступает наружу в сказках и в произведениях некоторых философов. (Возможно, вы припомните сказку о волшебном слове, открывающем все двери.)  Над универсальным методом, пригодным для решения любых задач, размышлял Декарт; наиболее же четко сформулировал  идею  о  совершенном  методе  Лейбниц. Однако поиски универсального, совершенного метода дали не больший эффект, чем поиски философского камня, превращающего  неблагородные  металлы в  золото:  существуют  великие мечты, которым суждено оставаться мечтами» [23, с. 13].

В 1956 г. К. Шеннон (которого А. Н. Колмогоров считает «одним из первых математиков и одним из первых инженеров последних десятилетий» [24, с. 5]), заметив первые признаки зарождения «цунами» глобальной математизации (волна которой, вызванная в то время взрывом всеобщего интереса к кибернетике и теории информации, затем надолго накрыла целые области естествознания, эко­номики, социальные науки и т. д.), предупреждал: «Ученые различных специальностей, привлеченные поднятым шумом и перспективами новых направлений исследований, используют идеи теории информации при решении своих частных задач. Так, теория информации нашла применение в биологии, психологии, лингвистике, теоретической физике, экономике, теории организации производства и во многих других областях науки и техники. Короче говоря, сейчас теория информации, как модный опьяняющий напиток, кружит голову всем вокруг.

Для всех, кто работает в области теории информации, такая широкая популярность несомненно приятна и стимулирует их работу, по такая популярность в то же время и настораживает. Сознавая, что теория информации является сильным средством решения проблем теории связи (и в этом отношении ее значение будет возрастать), нельзя забывать, что она не является панацеей для инженера-связиста и тем более для представителей всех других специальностей. Очень редко удается открыть одновременно несколько тайн природы одним и тем же ключом. Здание нашего несколько искусственно созданного благополучия слишком  легко может рухнуть, как только в один прекрасный день окажется, что при помощи нескольких магических слов, таких, как информация, энтропия, избыточность ... нельзя решить всех нерешенных проблем» [25, с. 667].

К сожалению, следует признать, что К. Шеннон точно оценил не только ситуацию, но и последствия. Во всяком случае, спустя четверть века, в 1980 г., Р. Хэмминг писал: «Для теории информации, что типично для внезапно возникающих научных направлений, большинство первых приложений оказались неудачными, однако по-другому, видимо, невозможно установить границы применимости новой теории. В результате того, что от теории информации ожидалось больше, чем она могла дать, наступило разочарование ...» [26, с. 7].

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

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

Одно из направлений такого влияния исследуется, есте­ственно, наиболее активно. Это характер влияния инструмента — САПР на работу проектировщика. Влияние задачи (САПР) на инструмент (программирование) привлекает пока значительно меньшее внимание5. Между тем, как заметил Э. Дейкстра, «сфера применения может быть такой же революционизирующей, как и средство» [9, с. 265].

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

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

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

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

Разумеется, сказанное не означает, что область приложений математических методов в инженерных задачах проектирования и конструирования информационных объектов (программировании) не будет расширяться. Будет, и весьма быстрыми темпами. Как и представители других инженерных дисциплин, программисты, по-видимому, скоро научатся считать свои «балки» (например, «прочность» программного модуля), получат формальные способы автоматического синтеза некоторых типов программных конструкций (подобно тому, например, как выполняется формальный синтез частотных фильтров в радиотехнике) и т. д.; т. е. получат (и, возможно, еще в 80-х годах) типовой для инженера-конструктора традиционных отраслей техники набор формальных методов решения рутинных задач конструирования. Однако не следует ждать появления формального «ответа на вопрос о том, как написать любую программу,— ответа на этот вопрос,— подчеркивает Э. 3. Любимский,— вообще не существует» [9, с. 6].

После того как выполнены трудоемкие исследования предметной области и завершился, наконец, сложнейший этап постановки задачи, программист, как и любой инженер-разработчик, «снова и снова остается один па один со своей собственной задачей: ему нужно составить программу! Выбрать, как именно следует расположить и связать данные в памяти, понять, какая именно последовательность операторов — способных сделать все что угодно и оттого одновременно и податливых и опасных — выполнит поставленную задачу. И как организовать эти операторы в цикл, который будет с каждым шагом приближать машину к намеченной цели»,— продолжает Э. 3. Любимский и заканчивает лаконичной, точной и универсальной для всех без исключения инженерных дисциплин формулой инженерного творчества: «Выбрать, понять, изобрести, проверить, усомниться и повторить все сначала» [9, с. 5].

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

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

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

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

Одной из наиболее плодотворных, но влиянию на технологию программирования областей приложений ЭВМ является САПР — основной в 80-х годах канал для проникновения в программирование принципов, методов и средств инженерного искусства.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1.По-видимому, имеются в виду диалоговые системы полуавтоматической трассировки и другие решаемые и диалоге с ЭВМ задачи топологии ИС, внедрение которых в широкую практику началось в середине 70-х годов.

2.Чтобы понять геометрию,— советовал столетием ранее Бернхард Риман,—изучайте природу, а не Евклида [21, с. 344].

3.Спустя 20 лот многим еще предстояло (как обычно) переоткрывать эти истины на собственном многотрудном опыте. Выше мы уже отмечали в этой связи заявление одного из руководителей компании, выпускающей микропроцессоры, о проблемах их внедрения в автомобильную промышленность: «Для нас труднее понять, как работает автомобильная фирма, чем для них — как работают наши микропроцессоры» [22].

4.Однако не менее существенным является и тот факт, что наукой: химия стала только после того, как ошибочность «великой мечты» алхимии оказалась доказанной. Иными словами, воспринимая все конструктивные результаты, накопленные в период господства новейшей алхимии — большой науки программирования, программирование постепенно приобретает черты прикладной науки, отказываясь от «великой мечты» о философском камне глобальной математизации как универсального средства решения проблем технологии программирования.

5.«Ирония сложившейся ситуации заключается, видимо, в том, что системы автоматизации проектирования и производства на базе ЭВМ все еще внедряются в технологию создания аппаратуры более интенсивно, чем в технологию программирования»,— отмечал в начале 1983 г. один из английских экспертов в области коммерческого производства программ» [27, с. 22].

6.Как отмечал В. Ф. Одоевский, «математика приводит нас к дверям истины, но самих дверей не отворяет» [28, с. 46]. Сто лет спустя Р. Хэмминг следующим образом конкретизировал это общее положение: «Теория информации устанавливает границы того, что можно сделать, однако мало помогает при проектировании конкретных систем» [26, с. 7].


Онлайн-версия CD-ROM приложения к книге Г.Р.Громова
"
От гиперкниги к гипермозгу: информационные технологии
эпохи Интернета. Эссе, диалоги, очерки
."