Category: it

Category was added automatically. Read all entries about "it".

RB42. Национальная программная платформа

Предыдущая заметка:

5 марта депутат Государственной Думы РФ, член Комитета по информационной политике, информационным технологиям и связи, председатель подкомитета по технологическому развитию Илья Пономарёв, по поручению участников круглого стола «Национальная безопасность информационных технологий», направил Обращение Президенту РФ Д.А.Медведеву.

Полный текст Обращения:


Блоги:

Форумы:

Видео:

Публикации:



Ответы на вопросы агентства "Комментарии.ру"
Руслан Богатырёв
независимый эксперт,
участник Круглого стола "Национальная безопасность информационных технологий"


— Как Вы в целом оцениваете подготовленное Обращение? Какие предложения представителей отрасти ИКТ Вы считаете наиболее интересными?

— Этот документ — вполне разумный компромисс. Которого десяткам представителей ведущих организаций и компаний в сфере образования, науки, бизнеса, государственного управления удалось достичь в достаточно короткий срок — примерно за месяц бурных обсуждений и непростых согласований. Главное — есть общее понимание в отношении того, что значительный проект национального масштаба, каковым является Национальная программная платформа (НПП), способен переломить катастрофическую ситуацию с засильем импортного программного обеспечения и остановить разрушение фундамента нашей ИКТ-индустрии — отечественной программной отрасли.

У нас, как только дело доходит до ИКТ, очень много говорят о важности информации и технических средств её передачи и обработки, говорят об информационных ресурсах и коммуникациях. Но о самом фундаменте, о программной отрасли — практически ничего. А это ведь и есть конденсатор интеллектуального потенциала, способный существенно влиять на экономику нашей страны и на значительное расширение её экспортных возможностей.

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

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


— Какой, на Ваш взгляд, может быть реакция властей на Обращение представителей отрасли ИКТ? Считаете ли Вы, что именно высокие технологии при условии активной позиции государства могут стать катализатором экономического развития? Возможно ли достичь полной технологической независимости России?

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

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

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


— Какие конкретные предложения, на Ваш взгляд, стоит внести в документ о создании Национальной программной платформы? К каким последствиям может привести принятие на государственном уровне национальных и отраслевых открытых стандартов? Как это отразится на разработчиках свободного и проприетарного ПО, на всей ИТ-отрасли?

— Требуется уже сейчас приступать к подготовке концепции Национальной программной платформы (НПП). Тут есть опасность свести её к размытому набору программного обеспечения, привязанного к конкретной экосистеме (что GNU/Linux, что Windows). Есть и другая опасность — превратить в аморфную операционную среду, составленную из различных ОС.

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

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

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

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

Нам нужно думать о том, как обеспечить плавную миграцию ключевых приложений из доминирующей Windows в новую операционную среду, под которую и должна быть выстроена НПП. Она должна решать триединую задачу — обеспечить работу приложений, ориентированных на (1) Windows, (2) UNIX (включая GNU/Linux) и (3) новую перспективную отечественную ОС. Решать разными путями. В том числе и путём абстрагирования от ОС.

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


— Как Вы оцениваете производящееся в России ПО? Насколько оно конкурентоспособно на внутреннем и на внешнем рынках? Возможно ли создание национальной программной платформы без помощи государства?

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

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

RB39. Национальная ОС — цель или средство?

Предыдущая заметка:

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

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

А потому всеобщий скепсис подталкивает к простому, дешёвому, лобовому решению – перелицевать GNU/Linux — одну из самых распространённых в мире свободных ОС. И навесить на неё красочный ярлык "национальная операционная система". Причём государство, судя по развитию событий последних лет, даже не готово взять на себя ответственность за её развитие и внедрение.

Что это кардинально может изменить в нынешней безрадостной ситуации? Чуть-чуть потеснить американского монополиста – корпорацию Microsoft, снизив её долю на нашем рынке операционных систем с 95% на пару-тройку процентных пунктов? Возможно. Облегчить своими преференциями выбор гражданам и организациям одного конкретного дистрибутива GNU/Linux из общей массы в 500 с лишним систем? Наверняка. Создаст ли это новый рынок, способный привлечь значимые силы науки и бизнеса? Увы, маловероятно. Быть может, мы сможем, наконец, облегчённо вздохнуть и избавимся от рисков технологической зависимости от США в тех кровеносных артериях страны, которые и определяет всепроникающая универсальная операционная система? Очень бы хотелось надеяться. Но… развитие ядра Linux определяет не Россия и даже не единичные российские разработчики — в людском и финансовом плане это находится под контролем трёх крупнейших американских компаний — IBM, Novell, RedHat. Не для того они вкладывали в это миллиарды долларов, чтобы за здорово живёшь отдать кому-то контроль над тем, что приносит немалую прибыль. Даст ли это мощный импульс подрастающему поколению в России испытать гордость за свою страну и выбрать себе славную профессию программиста? Точно, нет. Не надо быть специалистом, чтобы понять сомнительную ценность подобной "национализации" в глазах пытливой молодёжи. Так неужели оставлять всё как есть и полагаться на то, что ситуация вдруг сама собой изменится. Тоже сценарий. Вот только мы по нему живём уже почти четверть века, и света в конце тоннеля как-то всё не видать.

Есть ли другие пути? Есть. Причем не косметические и не революционные. А "постепеновские", эволюционные, позволяющие обеспечить баланс интересов противоборствующих сторон. Причём в интересах России.

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

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

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

Применительно к названным проблемам наиболее рельефно прорисовываются следующие три взаимосвязанные цели:

  1. Национальная безопасность ИКТ.
  2. Технологическая независимость страны.
  3. Возрождение национальной программной индустрии.

На первых двух нет смысла детально останавливаться. Их всесторонне обсуждали. А вот третью стоит рассмотреть подробнее.

Национальная программная индустрия (software industry)… Невольно возникает вопрос: а есть ли у нас в стране эта отрасль экономики? Воспринимают ли её (прежде всего, органы государственной власти) как важнейшую самостоятельную отрасль, способную обеспечить качественный, инновационный прорыв России? Или всё растворяется и размывается в понятии информационно-коммуникационных технологий (ИКТ), в собственно информационных ресурсах и аппаратных средствах для передачи, обработки и воспроизведения информации? Интеграция страны в мировое глобальное информационное пространство, информационное общество — это замечательно. Но важно знать, на чём оно будет построено и что потом делать с прогнившим фундаментом.

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

Лучшие программистские кадры либо уезжают из страны, либо переключаются на экспортную разработку – как продуктовую, так и заказную. В результате в ключевых, определяющих областях ПО — операционных систем и инструментальных средств – наличие собственных перспективных разработок и участие отечественных программистов (что в стране, что в мире) исчезающе мало. Уровень импортной зависимости здесь просто запредельный. Наш кадровый потенциал ориентирован не на архитектурные, инженерные, "строительно-монтажные" работы, а преимущественно на "отделочно-ремонтные", "малярно-слесарные" — перелицовку импортного ПО и налаживание информационных систем с минимальной наукоёмкостью. Такой перекос в условиях беспризорности национальной программной отрасли и засилья импортного ПО навязывает вузам извращённые требования к подготовке кадров, ускоренными темпами вымывая из сферы высшего образования те традиции научно-инженерного образования, которыми ещё совсем недавно наша страна могла по праву гордиться.

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

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

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

Давайте разберёмся в том, что же мы хотим сделать. Абсолютно новую ОС, архитектурно и технологически отличающуюся от нынешних популярных систем? Безусловно, этим надо заниматься и рассматривать как стратегическую перспективу, запуская в этом направлении новые пилотные проекты. Тем более, что обнадёживающие заделы в этой области у нас есть. Но готовы ли мы сегодня к штурму этой вершины? Трудно сказать. Что же делать? Ни системы семейства Windows, ни Mac OS (по понятным причинам принадлежности американским компаниям) в качестве национальной ОС выступать не могут. Значит, если результат нужен сегодня, поневоле приходится рассчитывать только на мир свободного ПО, где доминирует UNIX-культура. А там воронка популярности автоматически приводит к GNU/Linux.

И вот тут очень важно не наломать дров. Операционная система во многом определяет ту операционную среду, которая создаётся в той или иной сфере профессиональной деятельности. Она определяется набором устоявшихся программных продуктов и систем, накопленными лучшими практиками, спецификой обработки информации, интерфейсом и функционалом, к которому привыкли миллионы и миллионы специалистов. По сути это специализированная ОС, работающая поверх универсальной ОС. В нашей стране при запредельном доминировании Microsoft ломать через колено в одночасье такую схему при жутком дефиците аналогов в GNU/Linux означает одно — дискредитировать своё решение и убедить пользователей в том, что полноценной альтернативы Windows нет.

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

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

Попробую пояснить идею на простом примере. Предположим, что у нас есть большой парк оборудования, который подключается к сети через вилки с двумя штырьками большого диаметра (аналог приложений для Windows). И приличный парк оборудования, рассчитанный на вилки с двумя штырьками малого диаметра (аналог приложений для GNU/Linux). Чтобы решить проблему нестыковки розеток, можно создать новый вариант  розетки и вилки — три штырька среднего диаметра — и обеспечить переходники под новые розетки. Зато если это делается в масштабах страны и под контролем государства, то нет проблем выпускать своё оборудование, рассчитанное на эту новую унифицированную розетку. А затраты на переходники можно возложить на производителей оборудования, которым интересен рынок и которые вполне готовы пойти на столь незначительные издержки.

Иными словами, можно создавать национальную ОС со своими требованиями к разъёмам, к механизмам сопряжения, но при этом осознавая, что её можно в кратчайший срок конкретизировать, скоммутировать с реальными ОС. Оставляя возможности для дальнейшего развития собственных ОС. Для этого и надо создавать своё "законодательство", свои разъёмы, иначе мы просто станем заложниками одной конкретной системы и пойдём по тупиковому пути клонирования семейства IBM/360-370 по линии ЕС ЭВМ с гарантией нарастания технологического отставания.

К чему сведётся фиксация разъёмов: к выработке базовых спецификаций ОС (системные вызовы, протоколы, форматы данных), которые и определяют в совокупности операционную платформу. Другими словами, достаточно спроектировать и стандартизировать на государственном уровне программные спецификации, под которые можно обеспечить поддержку как со стороны GNU/Linux и Windows, так и совершенно новых, перспективных ОС. Как же вырабатывать подобные спецификации? Один путь — пытаться унифицировать универсальные ОС на нижнем уровне. Примеры: унификация свыше 500 дистрибутивов GNU/Linux ныне ведётся в рамках LSB (Linux Standard Base). Унификация вообще UNIX-систем осуществляется через спецификации POSIX.

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

Моё глубокое убеждение: нам требуется всерьёз заняться законотворческой деятельностью. Но не в юридическом, а в технологическом плане. "Правовая база" нормативов, технических норм и правил для национальной программной индустрии находится в жутком состоянии. Технологическая независимость в сфере программирования в первую очередь обеспечивается гарантией соблюдения стандартов, в особенности стандартов представления информации и сопряжения программных компонентов. Нам никто не мешает выявить те международные стандарты, на которые стоит основательно опереться, привести в соответствии им свои национальные стандарты и придать им более обязательный характер, особенно в отношении органов государственной власти. По таким стандартам мы на уровне государства должны занять активную позицию в международных комитетах по стандартизации, в особенности в ISO и ECMA. Наряду с этим мы можем создавать собственные стандарты, нормы и правила, в своих интересах. Некий аналог государственных СНиПов (строительные нормы и правила). И не должны ограничивать себя туманной перспективой возможного в будущем экспорта своей национальной ОС. Она должна решать в первую очередь задачи внутри страны и в этом быть на голову сильнее нынешних полуфабрикатов в виде популярных универсальных ОС. Если к такой технологической законодательной базе удастся обеспечить лёгкий доступ (желательно, бесплатный) со стороны нашего профессионального сообщества и если её соблюдение будет стимулироваться преференциями государства хотя бы в отношении тендеров на гос.заказы — процесс унификации начнёт развиваться стремительно.

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

Из этого следует, что имеет смысл во главу угла поставить стандартизацию, связанную с национальной ОС и её приложениями. С тем, чтобы на уровне государства контролировать и развивать интерфейсы сопряжения и форматы представления. С минимальной привязкой к конкретной ОС. Это большая задача, но риски минимизируются за счёт того, что под такое "законодательство" всегда можно будет подводить конкретную реализацию из существующих. Включая как Windows, так и разные дистрибутивы GNU/Linux, BSD, QNX и т.п. Стандартизация "разъёмов", "каркасов" и "пластов" даст мощный импульс развитию. К тому же она позволит и тем, кто планирует разработку своих ОС, инструментов и прикладных систем, выстраивать подъездные пути к развиваемой операционной инфраструктуре. Значит, можно сосредоточиться на создании спецификаций для национальных операционных и прикладных платформ. Конкретизация которых под требования национальной ОС может быть проведена в достаточно короткий срок.

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

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

Фактически то, что мы называем национальной или государственной ОС в контексте всего вышеизложенного, является более крупным образованием — национальной операционной инфраструктурой. И если проводить некие параллели со знаменитой амбициозной американской программой середины 1990-х годов бывшего вице-президента США Альберта Гора — Национальной информационной инфраструктурой (NII, National Information Infrastructure) — то нетрудно заметить, что здесь нет той размытости решений, которая в конечном итоге в США привела к тихому сползанию громкой инициативы в декларирование высоких целей и банальный делёж федерального бюджета.

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

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

Приведу для конкретики всего два примера по линии Российской академии наук (РАН). Из двух областей, в которых ещё сохранены традиции нашего мирового лидерства: (1) вычислительная математика и (2) инструментальные системы; где особенно высока наукоёмкость.

Так, Институт вычислительной математики и математической геофизики Сибирского отделения РАН, на базе которого был создан Сибирский суперкомпьютерный центр, прорабатывает проект создания комплекса математических библиотек нового поколения с высокой точностью вычислений, который опирается на уникальные разработке российских математиков. В конце прошлого года этот институт инициировал работы по созданию Фонда алгоритмов и программ СО РАН.

Другой пример. Институт систем информатики им. А.П.Ершова СО РАН обладает уникальным опытом создания компиляторов, инструментальных систем и ОС специального назначения, прежде всего, для бортового программного обеспечения российских спутников и уже выступал с предложением провести научно-исследовательский проект, нацеленный на практическую разработку операционной системы следующего поколения и создание в России соответствующего центра компетенции на базе научно-образовательной инфраструктуры новосибирского Академгородка. В качестве отправной точки этот коллектив намерен использовать результаты работ, проводившихся в 1980-х годах в рамках ВНТК «Старт». Тогда, по заказу ГКНТ СССР была создана оригинальная и независимая операционная система Excelsior с UNIX-подобным интерфейсом вместе с полнофункциональной средой разработки ПО для оригинальной 32-разрядной отечественной процессорной архитектуры. Работа была высоко оценена рядом отечественных и зарубежных специалистов, в частности, знаменитым швейцарским профессором Никлаусом Виртом (ETH Zurich).

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

Америка в компьютерной сфере давно уже подмяла науку под бизнес. Причём хоронила её методично. Ныне Европа в области программирования хоть и робко, но всё же начинает пересматривать свою почти рабскую зависимость от Штатов. И моё глубокое убеждение, которое вынес из многолетнего личного общения с лучшими европейскими учёными, — без потенциала России и стран бывшего Советского Союза самостоятельно из нынешней ямы Европе не выбраться.

Уверен, у нашей страны есть редкий шанс совершить серьёзный инновационный рывок, способный вывести Россию на качественно иной уровень развития. Очень бы хотелось, чтобы он действительно состоялся, а не оказался пустым выхлопом.

RB38. Отечественная или государственная ОС?

Предыдущая заметка:


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

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

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

В настоящее время на мировом рынке персональных компьютеров наиболее ярко выделяются три семейства операционных систем:
1. Windows (Microsoft, США)
2. Mac OS (Apple Inc., США)
3. GNU/Linux

Первые два – коммерческие, неклонируемые. "Порт приписки" их авторов и владельцев сомнений не вызывает – США. С последним семейством не всё так очевидно. Есть ядро (Linux), есть обвязка (преимущественно, на базе GNU). Обвязка является предметом клонирования, творческих изысканий огромного количества компаний. Одних только дистрибутивов GNU/Linux в мире ныне насчитывается свыше 5 сотен. С ядром ситуация более определённая: в его развитии львиная доля вложений финансовых и людских идет со стороны тройки компаний: IBM, Novell, RedHat. Все они имеют тот же "порт приписки" – США. Это объективно. И игнорировать подобный факт неразумно.

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

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

Какой же вывод напрашивается? Однополярность мира крайне опасна. И в сфере ОС также. Нужны разные полюса со своими механизмами сдержек и противовесов, позволяющие соблюсти баланс интересов и снизить риски. Самый очевидный путь минимизации рисков здесь, при формировании государственных ОС, – перелицовка и "национализация" наиболее распространённых ОС. Windows и Mac OS для подобного мало подходят, поскольку привязаны к конкретным компаниям (конкретной стране) и просто в силу этого риски снизить никак не могут. Остаются разве что ОС из сферы свободного ПО, прежде всего, GNU/Linux. По этому пути наименьшего сопротивления движение в разных странах (разумеется, отличных от США) и ведётся. Это позволяет частично решить задачу, но лишь частично. Если двигатель (ядро) контролируется и развивается не владельцем ОС, то угроза зависимости по-прежнему сохраняется.

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

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

Как же быть, чтобы минимизировать риски? Двигаться по пути многополярного мира ОС, опираясь на технологии их сосуществования (в т.ч. механизм гипервизоров). "Национализировать", адаптировать проверенные временем свободные ОС, прежде всего, GNU/Linux. Но при этом не плыть по течению, а осознанно следовать принципам модуляризации – вычленению значимых блоков-модулей, которые при согласованном интерфейсе сопряжений могут допускать альтернативные реализации разных разработчиков. Создать основу для подпитки решений со стороны новых, экспериментальных ОС.

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

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

В своих "Заветных мыслях" (1905) Д.И.Менделеев писал: "Хотя истина, конечно, одна, но пути к ней не намечаются ныне ни звёздами, ни столбами, двигаться же по пути достижения истины необходимо, чтобы не быть насильно увлечённым неизбежно надвигающимися историческими переменами и сознанием ускорить предстоящую эволюцию. Двигаться же можно или в одиночку, или сплотясь группами, ища в разных направлениях, так как идти всей массой сразу, гуртом, как стадо, лишь в одну сторону, можно только под влиянием бессознательного убеждения, причём мало вероятности попасть на верную дорогу, и многое в истории показывает, что такое стадное движение нередко ведёт к гибели".

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

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

RB35. Об Учителе. Памяти И.В.Поттосина






Предыдущие заметки:
  • RB34 (03.12.2007) “Роса”: перенацеливаемая отечественная ОС нового поколения
  • RB33 (27.11.2007) Лебединая песнь Digital
  • RB32 (22.11.2007) Ортогональная система языков в проекте "Роса"
  • RB31 (22.11.2007) Публичный старт проекта "Роса"
  • Оглавление


    Памяти Игоря Васильевича Поттосина
    К 75-летию со дня рождения

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

    Игорь Васильевич всегда старался оставаться в тени. Был блестящим организатором науки, правой рукой Андрея Петровича Ершова, при этом мудро и обстоятельно делал своё дело, не гонясь за званиями, наградами, научным и общественным признанием. После смерти Ершова (1988) Игорь Васильевич взвалил на себя нелёгкую ношу продолжения духа и традиций сибирской школы программирования. Стал директором Института систем информатики им. Ершова (ИСИ СО РАН) — преемника знаменитого Отдела программирования ВЦ СО АН СССР, который они с Ершовым и формировали в конце 1950-х годов.

    Впервые мне довелось познакомиться с Игорем Васильевичем в студенческие годы, когда учился на 4-м курсе Московского авиационного института (МАИ). В мае 1986 г. на базе ВЦ СО АН СССР проводился семинар «Язык программирования Модула-2 и инструментальные средства на его основе» (PDF). Поттосин, во многом разделявший взгляды Никлауса Вирта на продуманность и лаконичность выражения идей, давно положил глаз на новое творение маэстро языков программирования. В дальнейшем именно этот язык стал одним из любимых у Поттосина. Два ученика Игоря Васильевича — Дмитрий Кузнецов и Алексей Недоря — стали программистским ядром проекта Кронос: 32-разрядного отечественного персонального компьютера, ориентированного на Модулу-2. Он зародился в 1984 г. в одной из комнат общежития Новосибирского университета (НГУ). Тот проект дал жизнь и новой отечественной операционной системе Excelsior (внешне напоминает UNIX System V, реализована на Модуле-2), и настоящей фабрике по производству высококачественных компиляторов, которая теперь находится в ведении новосибирской компании Excelsior, где собралось немало кроносоведов и кроносолюбов, продолжающих славные традиции романтических 1980-х.

    Именно Модула-2 стала для меня той путеводной звездой, которая и привела к Поттосину. В 1983 г. в Московском Доме книги, что на Новом Арбате, мне посчастливилось приобрести серебристую книгу на английском языке. То был бестселлер проф. Вирта Programming in Modula-2. И программирование, и технический английский я начинал осваивать именно по этой книге. Затем в поисках доступных трансляторов и библиотек постепенно вышел на отечественную Рабочую группу по Модуле-2 (детище Дмитрия Михайловича Сагателяна из Института общей физики АН СССР). А через неё и попал в Новосибирск.

    Следующая встреча с Игорем Васильевичем произошла также в новосибирском Академгородке два года спустя (1988). Я представлял на Всесоюзной научной конференции «Методы трансляции и конструирования программ» тему направления, которое стало моей дипломной работой — «Методология разработки сложных программных систем», где обобщался опыт работы с Адой и Модулой-2 применительно к использованию мультипроцессных систем, опирающихся на верификацию формальных моделей (сети Петри). Честно говоря, было удивительно наблюдать отеческое внимание такого мэтра по отношению к рядовому дипломнику из Москвы. Он знакомил с Академгородком, ВЦ СО АН СССР, библиотекой Ершова.

    На фоне бесконечной московской суеты здесь был совсем иной мир. Это трудно передать словами. Просто другая планета. Библиотека произвела сильное впечатление, хотя в те дни уже не было того информационного голода, который во многом с 1960-х годов пытался компенсировать А. П. Ершов, привозя из каждой зарубежной поездки журналы, книги, препринты, оттиски статей, документацию — всё, что можно было собрать и увезти. Библиотека Ершова, для работы в которой, как я потом узнал, специалисты приезжали с разных концов страны, была уникальным многотысячным собранием, во многом определявшим высокий уровень развития отечественных школ программирования. И хотя с начала 1980-х на протяжении многих лет я буквально дневал и ночевал в ГПНТБ (Государственная научно-техническая библиотека СССР в Москве), библиотека Ершова заметно выделялась своим фондом, качеством комплектации.

    В 1989 г. Игорь Васильевич занялся подготовкой сборника «Язык Модула-2. Его реализация и использование» (PDF, 18 Мбайт), в который отобрал две работы, написанные мной и моими коллегами по научно-исследовательской работе в МАИ. С его подачи я заинтересовался Модулой-3, после чего вышел на прямые контакты с Биллом Калсовым (Bill Kalsow) и его коллегами в DEC Systems Research Center, поскольку тогда мы начали в МАИ работать над переносом компилятора Модула-3 в MS-DOS с реализацией его на Модуле-2. Затем наступил чёрный период безвременья (1991–1994 гг.), когда научные контакты было трудно поддерживать. Ниточки рвались одна за другой. Нужно было попросту выживать.

    В 1994 г. на базе Международного инженерного университета, пообещавшего финансирование по линии UNESCO и UNIDO, я затеял издание научно-популярного альманаха «Технология программирования» (см. сокращённую PDF-версию; с.1-7, 171-200; 30 Мбайт). Его концепция — стать своеобразным аналогом Scientific American в сфере программирования. Ежеквартальное 200-полосное издание с компакт-диском, где основное внимание уделялось фундаментальным, мировоззренческим вопросам с выделением конкретики в специальные приложения — журналы в журнале. Первый номер увидел свет в мае 1995 г. (за несколько дней до официального анонса Java). Подобного издания не было не только у нас в стране, но и в мире. Предварительные консультации показали, что и наши, и зарубежные учёные очень хорошо восприняли идею и согласились её поддержать. Было очевидно, что противостоять конъюнктуре и развивать это направление в печатном органе можно только при определённой финансовой его независимости. В противном случае всё опять сведётся к бесконечному размусоливанию нюансов API-вызовов, а также рассмотрению костылей популярных языков и систем программирования.

    Игорь Васильевич одним из первых крайне заинтересовался как самой идеей, так и её воплощением. Между нами активизировалась переписка (благо тогда уже электронная почта была вполне доступна). Он прислал мне для публикации обзорный материал «Российские исследования по языкам программирования и трансляции» (PDF). Но в те дни нашим планам не суждено было сбыться. Даже несмотря на то, что финансирование прекратилось не начавшись, мы в последующие годы обсуждали разные моменты, касающиеся идеи журнала и той позитивной атмосферы, которую он может вокруг себя создать. Игорь Васильевич был убеждён — подобное издание в печатном виде у нас будет тяжело пробить, нужны другие ходы. И хотя мы оба тяготели к бумажной форме издания, перспективы виделись именно в Интернете. Но ни аудитория, ни сама Web-среда не были к этому готовы. Пришлось идею отложить до лучших времён.

    С 1996 г. я стал обозревателем, а потом и научным редактором ComputerWeek-Moscow. То был ведущий компьютерный еженедельник страны. Довелось вновь приехать в Новосибирск и встретиться с Игорем Васильевичем — во время визита в Новосибирск Никлауса Вирта (1996) и на Международной конференции памяти А. П. Ершова (PSI). Он приехал встречать в аэропорт Толмачево, а потом мы долго бродили по Акадегородку, где он сдержанно улыбался моим восторгам в отношении IDL и с горечью говорил о непростой ситуации в Академгородке — страну покидали талантливые люди и в воздухе витала атмосфера безысходного запустения. Во время нашей последней встречи в Академгородке он подарил мне редкое издание «А. П. Ершов. Избранные труды», в создании которого и сыграл ведущую роль. Игорь Васильевич был духовно очень сильным человеком, потрясающим оптимистом, но я убеждён, что его внезапный уход из жизни во многом связан именно с той гнетущей атмосферой тотального разрушения культуры, науки и образования, которая окутала всю страну.

    В середине 1997 г. Микаэль Франц, ученик Вирта, позвал к себе в Калифорнию (University of California, Irvine), защищаться и ковать славу мобильного кода. Но ехать в Штаты желания не было. Научная карьера не интересовала, а заниматься любимым делом можно было и дома.

    Осенью 1997 г. Игорь Васильевич переслал мне очень интересное письмо Никлауса Вирта, которое во многом повлияло на мое мировосприятие. Но сначала поясню ситуацию. В июньском номере журнала IEEE Computer (1997) вышла необычная статья под названием «The Feel of Java». Это, кстати, ведущее издание профессиональной ассоциации IEEE Computer Society. Приведу цитату.

    Java — это настоящий язык-трудяга. Это не результат чьей-то диссертации, это язык для работы. Java покажется очень знакомым самым разным программистам, поскольку мы предпочитаем делать проверенные вещи. <...> Итак, что же такое Java? Java ощущаешь как игривый и гибкий язык. Вы можете создавать с его помощью такие вещи, которые сами являются гибкими. Java ощущаешь как детерминированный язык. Если вам хочется, чтобы он что-то сделал, просто попросите его об этом. В нём не видится ничего опасного: вы можете спокойно попробовать что-то сделать, и если окажетесь неправы, то быстро получите сообщение об ошибке. Java ощущаешь как очень богатый язык. Мы постарались снабдить его большой библиотекой классов. Поэтому не откладывайте дело в долгий ящик, а садитесь за компьютер и пишите свой код.

    Не складывается ли впечатление, что перед нами выдержка из рекламного объявления? А ведь эти слова принадлежат Джеймсу Гослингу, не только автору Java, но и человеку, который защитил диссертацию в известном университете Карнеги-Меллон, связанную с проектом Andrew Windows System, и который в те годы стал вице-президентом компании Sun Microsystems.

    «Представьте себе, — не в силах сдержать возмущение, комментирует приведённую цитату Вирт, — что эти слова были написаны в 1960-е годы, и замените слово «Java» на слово «Алгол». Автора сочли бы человеком психически ненормальным, слова его большей частью чужды науке и не имеют с ней ничего общего. Сегодня никто даже не возмущается, нет никакой реакции от «научного» сообщества. Как же низко могла пасть «информатика»? И это делается с молчаливого одобрения такой уважаемой организации, как IEEE Computer Society?» В итоге на свет появилась статья «Java: гадание на кофейной гуще» (PDF, 1998).

    Сам по себе чей-то научный авторитет (каковым обладал Вирт) не был для Поттосина безусловным критерием истины. Помнится, он довольно горячо выражал своё несогласие с позицией знаменитого Петера Наура по роли интуции в программировании. «Интуиция в разработке программного обеспечения» (PDF, 1985). (Эту статью я готовил для второго номера «Технологии программирования».) По его аргументации и убеждённости было видно, что он глубоко прорабатывал данный вопрос.

    Запомнились встречи с Поттосиным в Москве в конце 1990-х. Игорь Васильевич по обыкновению приглашал в гостиницы, где останавливался проездом или по московским делам. Обсуждали различные темы, даже не имеющие отношения к программированию, но в разговорах рано или поздно речь заходила о научно-популярном издании для программистов. Он был удивительно целеустремлённый человек, который с невероятной мягкостью и деликатностью настойчиво продвигал важные вещи. «Мне нравится эта идея», — не раз говорил он. И было ясно, что он имел в виду — «не вздумайте её хоронить»!

    Большое турне Вирта осенью 2005 г., в организации которого мне довелось участвовать с подачи проф. Юрга Гуткнехта (ETH Zurich) и Д. М. Сагателяна, вдохнуло новую жизнь в старый замысел. Но очень остро высветило и тот гигантский разрыв между спросом и предложением — «промывкой мозгов» молодого поколения и действительно фундаментальными вещами, лежащими вне сиюминутной конъюнктуры.

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

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

    Искренне рад, что дело, когда-то поддержанное Игорем Васильевичем, которого я счёл бы за честь называть своим Учителем, не только возрождается, но и благодаря неоценимой помощи друзей и единомышленников начинает понемногу обретать реальные контуры. А что может быть лучшей памятью Учителю?

    Руслан Богатырёв
    Москва
    21.02.2008

    RB34. “Роса”: перенацеливаемая отечественная ОС нового поколения

    Заметки по началу проекта:
  • RB22. О проекте создания отечественной перспективной ОС
  • RB23. О языках реализации в проекте новой ОС
  • RB25. Новая европейская ОС
  • RB26. Дуальность и другие контуры "Росы"
  • RB27. Пути восхождения к новой ОС
  • RB28. Закон Гордона Мура и закон Дэвида Мэя
  • RB31. Публичный старт проекта "Роса"
  • RB32. Ортогональная система языков в проекте "Роса"
  • Оглавление


    30 ноября в Московском авиационном институте (МАИ) в рамках Открытого семинара по ИТ состоялось публичное представление проекта новой отечественной ОС "Роса".


    Выдержки из доклада:

    Сегодня нередко можно слышать голоса: зачем нам своя операционная система (ОС), когда есть другие? Боимся козней тлетворного Запада?

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

    <...>

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

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

    Но бизнес - это не промышленность. Цель бизнеса - извлечение максимальной прибыли, контроль и расширение рыночной доли. Цель промышленности (отечественной) - развитие собственной страны! Это разные, во многом противоречивые вещи.

    В угоду бизнесу гробятся перспективные направления (если они не приносят осязаемую выгоду сегодня и сейчас). Бизнес в компьютерной сфере пожирает сам себя: вспомним NeXT, вспомним блестящий проект DEC Alpha AXP и корпорацию Digital, вспомним IBM OS/2 и VisualAge Smalltalk. Почему происходит самопожирание бизнеса? Давайте зададимся вопросом: что во главу угла ставят крупные компании? Правильно: сохранение и усиление своего влияния на рынке. Что и даёт необходимую прибыль. А для этого технологическое совершенство не только не полезно, а даже вредно, ибо может подорвать завоёванные позиции.

    <...>

    Отечественная электронная промышленность лежит в руинах. Программная промышленность еще только зарождается… Ее попросту нет. При этом именно программное обеспечение в будущем будет определять темпы роста электронной промышленности. А не наоборот.

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

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

    <...>

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

    <...>

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

    Ларри Пейдж, один из основателей Google, сформулировал принцип "здорового презрения к невозможному" — нужно ставить перед собой цели, которые на первый взгляд могут показаться неосуществимыми. Как говорят на мудром Востоке, "желание – тысяча возможностей", "нежелание – тысяча причин".

    <...>

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

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

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

    RB32-2. Ортогональная система языков в проекте "Роса"

    Начало заметки см. RB32-1.

    Базовый язык-микроядро

    Проф. Вирт, на мой взгляд, очень верно нащупал важное направление развития инструментария. В то время как все помчались насыщать языки всё новыми могучими средствами и переносить центр тяжести на графические среды, он понял, что идти надо в противоположном направлении. Вычленяя квинтэссенцию и вынося за рамки компетенции данного языка паразитную нагрузку. Это напоминает выделение в наборе команд процессора базового минимума, из которого строится остальное (RISC), напоминает идею микроядра ОС (в противовес моноядру), напоминает Форт-системы… Микроядро - это один из важных принципов создания программных и технических систем. Чтобы подчеркнуть эту аналогию, я решил использовать название "микроядро" в отношении как языка, так и ортогональной системы языков.

    Оберон - это удачный вариант микроядерного языка традиционного императивного программирования, ориентированного на самую распространённую процессорную модель Эккерта-Неймана. Другим языком-микроядром можно назвать классический Си. Отличительной особенностью Оберона является сбалансированность языка, опирающаяся на принцип концептуальной экономии и внутреннюю ортогональность: механизм расширения типов (type extension), обобщение процедур (процедурные типы), концепция модуля.

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

    Графические средства, ориентированные в большей степени на человека, очень полезны (особенно для общения людей между собой), но как только мы вспомним о том, что человеческий фактор является ахиллесовой пятой контроля сложности, то поймём, что чувство меры здесь должно превалировать над желанием облегчить труд. Мы нередко тем самым облегчаем труд создания новых сложностей. Автоматике нужны языки и совсем не графические. Графика (в широком смысле) - это просто удобная форма, позволяющая человеку на том или ином участке работы. Мы внимательно изучаем это направление прежде всего с точки зрения поддержки языков спецификаций и моделирования. Для каждого формального "графического" языка у нас будет соответствующий текстовый эквивалент. Мы изучаем самые разные варианты на сей счёт. Отечественные ДРАКОН(ы) для разработки программного обеспечения отечественного "Бурана" и других масштабных космических проектов - лишь один из изучаемых вариантов. Впрочем, история их создания весьма интересна и с ней стоит поближе познакомиться.

    Но вернёмся к языку-микроядру, к языку-чемоданчику под названием Оберон. Каким бы замечательным и компактным ни был язык-чемоданчик, он не в силах адекватно решать все проблемы. И здесь не стоит впадать в крайность - обожествлять язык. Давайте смотреть правде в глаза: Вирт со своей командой из ETH Zurich во многом абстрагировались от проблемы коллективной работы многих десятков специалистов над одним проектом. Система Oberon (да и BlackBox, хоть и в меньшей степени) - это системы индивидуального программирования. "Эгоцентрические". Не удивительно, что Вирт и его коллеги не заморачивались проблемами масштабирования разработки (а тем более, промышленной разработки). Сам язык Оберон (включая и его последующие диалекты), ушедший от приоритета интерфейса и полноценного разделения модуля на интерфейс и реализацию (как было в Modula-2), сделал шаг в направлении эгоцентризма. В результате процесс перевернулся с ног на голову: интерфейс стал результатом того, что разметили в реализации. Тогда как в распределённых коллективах (да ещё в тех задачах, которые делаются не под кальку) нужно жёсткое фиксирование интерфейсов (в первую очередь) и вариативность реализаций под тот же интерфейс (во вторую). Впрочем, внести соответствующие коррективы в тот же BlackBox не столь трудно.

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

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

    Оберону нет смысла лезть туда, куда их просто никто не пустит - в "жирную" инфраструктуру, созданную Microsoft, Sun, IBM и др. Но это и не надо. Во-первых, он может её "нагло" пользовать. Во-вторых, он может применяться в качестве универсального чемоданчика с инструментами для программиста-индивидуала. В-третьих, он показывает себя во всём блеске там, где инфраструктуры нет (наш проект).

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

    Эти слова следует распространять и на инструментарий (языки), и на саму ОС. Нужен наращиваемый базис. При этом сам базис должен быть тщательно продуман и сбалансирован. Это лежит в русле идеи настраиваемых (конфигурируемых, адаптируемых) сущностей и систем.

    Но Оберон - не панацея (для программирования в целом). Потому после многих лет исследований разных языков (включая реализацию в 1980-х годах языковой системы "Модула-Пролог" с примкнувшим к ним Лиспом) я пришёл к идее ортогонального базиса языков (сбалансированный набор взаимодополняющих, минимально пересекающихся в понятийном пространстве - языки-ядра разных парадигм). Нельзя сказать, что ортогональность как внутри языка (по концепциям и средствам), так и между языками - откровение в программировании. В той или иной мере этот принцип использовали ранее. Но в том виде и контексте, как это задумано для нашего проекта, - подход весьма нешаблонный. Просто идея ортогональности, воплощённая Виртом в одном языке (внутренняя ортогональность и сбалансированность классического Оберона), развивается в сторону языков-ядер (внешняя ортогональность и сбалансированность системы языков). Развивается в понимании того, что синтаксис - не просто внешняя форма, во многом он связан с семантикой, и только в такой органичности может давать существенный выигрыш в процессе программирования. Иными словами, не надо парадигмы и разнообразные конструкции языков затаскивать в один синтаксис. Это прокрустово ложе. Оно отсечёт немало ценного и полезного. При этом желательно иметь чувство меры. Если создаются новые диалекты известных языков, которые планируется объединять в устойчивые языковые системы, то по возможности нужно нивелировать синтаксические расхождения. Хотя это тонкая, непростая работа.


    Понятие ортогональности

    В контексте вопросов, поднятых в этой заметке, хотел бы обратить внимание читателя на одну статью 10-летней давности известного в мире специалиста - Луки Карделли (Luca Cardelli).

    Несколько слов о нём. Итальянец. Получил европейское образование в университете Эдинбурга (Шотландия), затем попал в знаменитую AT&T Bell Labs (1982-1985), откуда перешёл в крупнейший исследовательский центр некогда могущественной корпорации DEC (DEC Systems Research Center), где проработал с 1985 по 1997 гг. После развала исследовательской базы DEC был приглашён 1997 г. в новоявленный исследовательский центр Microsoft Research (европейское отделение в Кембридже). Там он ныне является ведущим научным сотрудником и возглавляет группу по инструментам и принципам программирования (Programming Principles and Tools), а также группу по информационной безопасности (Security), совмещая эту деятельность с преподавательской (приглашённый профессор в ряде университетов). Начинал с реализации компилятора для функционального языка ML. В свете нашего проекта важно учитывать его большую роль в проектировании языка Modula-3 (1986-1995), который стал развитием идей виртовской Модулы-2 (прообраза Оберона) и неафишируемым внутренним языком разработок в Xerox, DEC и Olivetti.

    Обратимся к его статье. Она называется "Неудачные инженерные качества ОО-языков" ("Bad Engineering Properties of Object-Oriented Languages" // ACM Computing Surveys, December 1996). Статья написана через 15 лет после шумной рекламной кампании Smalltalk, в эпоху доминирования C++ в этой сфере и на фоне едва народившейся Java, создавшей основу для разработки C#. На фоне примерно 5-летней практики не известных широкой общественности, родственных языков Eiffel (1986), Оберон (1988) и Modula-3 (1988).

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

    Лука Карделли выделил в этой статье пятёрку неформальных метрик для оценки качества языка программирования:
    1. Экономия выполнения, Economy of execution (как быстро работает программа).
    2. Экономия компиляции, Economy of compilation (сколько времени занимает переход от исходных текстов к исполняемому коду).
    3. Экономия индивидуальной разработки, Economy of small-scale development (насколько тяжело работать с языком программисту-индивидуалу).
    4. Экономия коллективной разработки, Economy of large-scale development (сколь трудно работать с языком команде программистов).
    5. Экономия выразительных средств языка, Economy of language features (сколь трудно изучить и использовать язык).

    Карделли отмечает: "Языки, ориентированные на прототипы (Prototype-based languages), уже пытаются уменьшить сложность языков, ориентированных на классы (Class-based languages), путём предоставления более простых, более композиционно удобных средств. Даже в рамках ориентированных на классы языков мы теперь имеем лучшее понимание того, как достичь простоты и ортогональности, но многое ещё остается сделать".

    Карделли в своей статье высказал важную мысль: "Ортогональность средств языка уменьшает сложность языков программирования". Мысль, которую давно осознал проф. Вирт, продемонстрировавший миру практическое её воплощение.

    Небольшой терминологический комментарий. Важно делать различия между обобщающим понятием объектоцентрического языка (object-based language, где объекты просто поддерживаются на уровне сущностей языка) и уточняющими понятиями классоцентрического языка (class-based language, где каждый объект должен быть отнесен к определенному классу) и объектно-ориентированного языка (object-oriented language, где к иерархии классов добавляется наследование). Группа языков, ориентированных на механизм делегирования (Delegation-based languages), включает в себя и языки, ориентированные на прототипы (Prototype-based languages). Прототип рассматривается как объект, который одновременно является экземпляром и шаблоном. Детально это изложено в статье 20-летней давности "Dimensions of Object-Based Language Design" // OOPSLA'87, написанной Питером Вегнером (Peter Wegner), профессором университета Брауна (Brown University, США).

    Наряду с этим Вегнер дает определения понятиям "согласованность" (consistency) и "ортогональность" (orthogonality) в отношении языка программирования (я это называю внутренней согласованностью и внутренней ортогональностью).

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

    Ортогональность. Набор языковых средств является ортогональным (независимым), если для каждого подмножества средств существует язык, который обладает этим подмножеством и не имеет средств в дополняющем подмножестве.
    Вегнер пишет: "Объекты, классы и наследование далеки от ортогональности. Классы определяются через объекты, а наследование, в свою очередь, через классы..." Очевидно, что подобные понятия согласованности и ортогональности можно распространить на интегрированные наборы/системы языков и говорить, в частности, о внешней ортогональности (в системе интегрированных языков).



    Архитектура ортогональной системы языков

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

    Надо отметить, что предпосылки к подобной ортогональной схеме были заложены как минимум 30 лет назад. Речь идет о знаменитом исследовательском центре Xerox PARC, колыбели многих важнейших достижений в области аппаратного и программного обеспечения. В рамках проекта Cedar осуществлялась интеграция базового языка системного программирования (Mesa/Cedar) со средствами взаимно дополняющих языков - Лиспа (Interlisp-D) и Smalltalk. Только это был единый язык (Cedar), который сращивался со средой (Cedar). Дополнительную информацию можно найти в материалах, опубликованных на сайте Европейского центра программирования - http://www.europrog.ru/ilog.html#210207

    После годовой командировки Вирта и Гуткнехта в Xerox PARC (в начале 1980-х годов) проект Cedar и стал отправной точкой проекта Oberon.

    Разумеется, в отборе кандидатов основных языков в нашей ортогональной системе не последнюю роль играют не только их технологические качества и уровень сбалансированности при интеграции, но и перспективы языков (с прицелом на 5-7 лет), нынешняя популярность этих языков, наличие понятных спецификаций и открытых реализаций). Компромисс реализуется через принцип "базис-надстройка".

    На одном из интернет-форумов я уже в шутку говорил, что "Роса" - это будущий кровопивец с милым и ласковым названием. Он присосётся к армии Си и UNIX-разработчиков (к Linux), к Java-сообществу, к Haskell-сообществу, к Python-сообществу. Подтянет их к себе (новое - это всегда интересно и приковывает внимание). При этом даст им в руки действительно новый инструмент. Весьма и весьма полезный. Технологичный, открытый, бесплатный, без ограничений на коммерческое использование... Для каждого из этих миров появится масштабируемая перенацеливаемая ОС, которая фактически предложит солидную, продуманную подпорку их ран-таймов. Через них пойдут на общих основаниях и остальные языки.

    Попутно будет заметно улучшен инструментарий BlackBox (поскольку станет основой для макетирования нашей ОС и трамплином для запуска базиса). Т.е. его модернизация (или даже кардинальная переработка) будет практически востребована масштабным проектом.

    Открытая разработка в течение длительного времени позволит создать хорошие подъездные пути к новой ОС и подготовить будущих разработчиков приложений для "Росы" к такому переходу. Для языков ортогонального базиса будет создан инструментарий нового поколения, более сильный, нежели существующие в индустрии сегодня. С возможностями использования приложениями "бортовых" микро-ОС (как в случае BlackBox). Мы будем некоторое время сохранять альтернативу Лисп-Рефал, хотя всё идет к тому, что в нашем ортогональном базисе из этих двух кандидатов будет в итоге выбран именно Рефал.

    UNIX-программисты заполучат уникальные средства мультипрограммирования и компонентного программирования, которые они до этого не имели. Как известно, всё познается в сравнении. И новое - особенно. Выделенные в мэйнстриме технологические зоны прорыва (UNIX, Си, Haskell, Python) помогут встать новой ОС и её инструментарию на ноги. А потом - путем мягкой миграции (совмещения старого и нового) - заполучить много новой крови для своего развития.

    Поясню планируемую структуру ортогональной системы языков в "Росе".

    Ортогональный базис (Rosa-M, Rosa-R, Rosa-S, Rosa-T):

  • M - язык низкоуровневого программирования (близкий к классической Модуле-2, псевдомодуль SYSTEM сливается с языком, нет классов/объектов и сборки мусора);
  • R -  язык программирования с расширяемыми типами (близкий к классическому Оберону, есть сборка мусора, псевдомодуль SYSTEM исключается из Оберона, его роль переходит к M);
  • S - язык ООП (близкий к классическому Smalltalk Алана Кея);
  • T - язык метавычислений (близкий к Рефалу В.Ф.Турчина).

    В качестве настройки фундамента (M) на разные процессорные архитектуры (включая виртуальные процессоры) всесторонне изучается вариант использования диалекта классического Форта (Forth); это пятый язык базиса: Rosa-F.

    Основными языками системного программирования будут M и R (последний отражает в названии первую букву ОС - Rosa). Язык M близок по уровню работы к Си. Возможности препроцессорной обработки (и не только) возлагаются на язык T (+ специальные сервисные средства в поддержку удобства трансформации исходных текстов). Язык S в максимальной степени заточен под работу с ООП (в классике - динамическое связывание через интерпретацию сообщений).

    M и R - не ортогональные языки: это двухэтажный вариант одного языка, герметизация низкоуровневых средств. Это как нож (M) и вилка (R). Они под рукой. Кому-то удобно пользоваться одной вилкой. Но нож - всегда на столе. Один и тот же программист реализует нужный ему низкоуровневый функционал на M и просто импортирует в R. Сам. Может попросить коллегу. Если сущности (в разных гранях) можно разнести по отдельным языкам (напр., нижнего, среднего и верхнего уровня), то "протаивание" сущностей с новыми отношениями (операциями) над ними в другом понятийном пространстве позволит добиться герметичности (по надёжности и контролю сложности), которая сродни герметичности отсеков подводной лодки. Здесь нужно иметь чувство меры. Один язык, в который впихивается всё - это крайность (опять же учитывая разделение труда в промышленном производстве ПО). Разбиение на множество языков - это введение соответствующего числа понятийных уровней. В нашем случае пока видится оптимальным вариант из трёх уровней - "железячный" (M), алгоритмический (R) и архитектурный (Metasys), со скрытым уровнем настройки на "железо" (F). Язык Metasys во многом служит основой интеграции и прокладывает мостик к композиции с сущностями других языков.

    При импорте сущностей источник импорта из другого языка будет префиксироваться именем соответствующего языка реализации. Обработка исключений (с учетом её косвенной формы через настраиваемое поведение ASSERT-инвариантов) будет фундаментом всех языков ортогонального базиса.

    На системном уровне будет задействована пара "Оберон-Рефал" (наши диалекты этих языков). При этом Рефал будет нести на первых порах минимальную нагрузку - он понадобится для различных сценарных вещей и высокоуровневых (мета)манипуляций. Несмотря на всю свою простоту его реализация таит массу подводных камней (по эффективности и тюнингу движка). Рефал рассматривается нами как альтернатива Лиспу (и Прологу). Кроме того, хорошо зарекомендовавшая себя технологически схема "Ада-Лисп", используемая в NASA и в Минобороне США, очевидно имеет у нас иное, микропредставление - "Оберон-Рефал". По Рефалу надо понимать, что многие задачи можно на нём решать, имея в виду возможность почти мгновенного расширения языка за счёт встроенных функций, реализованных на Обероне (M+R).

    Синтаксис языков. Вводится модель вариативного синтаксиса. Для M и R, в частности, поддерживаются как равноправные Паскаль-подобный синтаксис (Модула-2, Оберон) и Си-подобный синтаксис. Автоматически (нажав конпку) можно переключиться из одного представления синтаксиса в другое. В отношении зарезервированных слов/идентификаторов поддерживаются два варианта: верхний регистр (MODULE) или нижний регистр (module). Допускается смешение в одном модуле разных режимов выделения зарезервированных слов (будут выделяться за счет настройки среды программирования). Альтернативные формы синтаксиса смешиваться в одном модуле не могут.

    Синтаксис языка T (назван в честь Турчина, автора Рефала) будет переработкой синтаксиса Рефала. Семантика в основе своей будет сохранена. Язык S по семантике будет близок Smalltalk, но синтаксис планируется вариативный.

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

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

    При проработке описания параллелизма/асинхронности учитывается опыт языков БАРС и ПОЛЯР из проекта МАРС (Модульные асинхронные развиваемые системы, 1985-1988, ВЦ СО АН СССР, ВЦ АН СССР, Институт кибернетики Эстонской ССР, НПО "Импульс") и используемый там механизм управляющих сетей (модификация сетей Петри).

    Таким образом, распределение языков по уровням ОС видится примерно таким:

  • Микроядро: M
  • Ядро: M, R, Metasys
  • Сервисный уровень: M, R, S, T, Metasys
  • Прикладной уровень: R, S, T, Java, Haskell, Python, Metasys.

    Новый язык R (преемник классического Оберона) намеренно идёт по пути ужесточения ограничений, по пути повышенной надёжности, герметизации.

    Важная особенность - все языки-ядра ортогонального базиса (M, R, T, S) имеют технологическую независимость от внешних лиц и организаций. Они будут находиться полностью под нашим контролем. Это наши языки (диалекты) и наши реализации. При этом переход на них с языков-оригиналов достаточно прост (близки и по синтаксису, и по семантике), возможна и реализация соответствующих миграционных конверторов. Мы минимизируем риски. Критериями модификаций исходных языков будет устранение "заусенцев", избыточных при интеграции в ортогональном базисе, а также выделение интерфейсных (общих базовых) сущностей (в контексте экспорта-импорта).

    Развитие языков прикладного ортогонального уровня (Haskell, Java, Python - где степень ортогональности много слабее базовой четвёрки) находится вне нашей компетенции. А потому мы будем брать под контроль мониторинг их эталонных открытых реализаций, синхронизацию публичных релизов с нашей реализацией. Будем вырабатывать механизм быстрого погружения нового релиза в нашу ортогональную систему.

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

    Если программисту нужны свои любимые языки (как-то C++, C#, Ada и др.) - вполне вероятно, что со временем они появятся в "Росе". Просто наша группа ими заниматься не планирует по целому ряду причин. У нас два уровня языков - свой (M, R, S, T, F, Metasys) и для массового разработчика (Java, Haskell, Python, Си).

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

    На этапе макетирования новой ОС мы планируем параллельно прорабатывать и реализовывать новые языки (2-3 года) и писать на Компонентном Паскале в среде BlackBox (диалект Оберона, адаптация в направлении Java) с учётом продвижения по линии новых языков. Подробная информация об инструментальной системе BlackBox представлена в центре компетенции BlackBox в России (компания "Метасистемы", г.Орёл) - http://www.oberoncore.ru/ С имитацией языка M на стадии макета успешно справится XDS Modula-2 новосибирской компании Excelsior, созданной участниками проекта МАРС. Эта система программирования оттачивалась для заказных работ с крупнейшими телекоммуникационными компаниями мира и в ходе реализации отечественного проекта СОКРАТ, результаты которого многие годы успешно применяются в НПО Прикладной Механики им.М.Ф.Решетнева, для разработки бортового программного обеспечения российских спутников связи (система Глонасс).

    RB32-1. Ортогональная система языков в проекте "Роса"

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

    Почему языки реализации так важны?

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

    Это острый момент, по которому у нас разгорелись бурные дебаты. Вопрос сводился к тому, важен для ОС язык реализации или же всё равно какой. Как выяснилось, сторонники UNIX склоняются больше ко второму варианту. И утверждают: в итоге мы придём по архитектуре к UNIX, реализованной на Си. Моё возражение было простым - замените Си, например, на классическую Модулу-2 и вы увидите наглядно существенную разницу в качестве и надёжности системы не в пользу нынешних реализаций. Но зачем нам вообще переписывать готовую архитектуру на другом языке? Мы собрались не для того, чтобы побыстрее абы как закрыть пробоину. Мы делаем систему нового поколения, с перспективой на многие годы вперёд, отталкиваясь от осознания серьёзных промахов современного программирования, которое в угоду коммерциализации проигнорировало весьма важные идеи прошедших десятилетий. При этом, понимая, что в группе собрались сторонники диаметрально противоположных воззрений на ОС (UNIX и Oberon) с самого начала постулировалась аксиома - новая операционная система не должна быть ни реинкарнацией ОС UNIX-семейства, ни реинкарнацией ОС Оберон-семейства, хотя отдельные решения оттуда могут и должны быть использованы. На первом направлении давно уже настоящее столпотворение. Там справятся и без нас. Особенно с учётом ставки на тотальную линуксоизацию населения. На втором направлении - ярко выраженный технологический изоляционизм: монопольный маргинальный язык со спартанской операционной средой (сращивание исполняющей системы языка и ядра ОС). В Оберон-системах есть немало интересных решений и находок, но в общем и целом это, скорее, исследовательский полигон, имеющий врождённые проблемы.

    Нужно особо отметить, что мы декларировали приверженность системному подходу, рассматривая ОС, прежде всего, как сложную программную систему и продумывая новые горизонты, которые открывает метасистемное программирование (в нашем понимании). Здесь весьма показательна такая точка зрения: для системного подхода всё едино, на всём можно строить с одинаковым успехом. На мой взгляд, это типичное мнение архитектора. И не только программных систем. Инженеры прекрасно понимают, что надёжность придуманной конструкции обеспечивается не в последнюю очередь строительным материалом, а также знанием сопромата. В сфере ОСестроения понемногу приходит понимание, что язык (строительный материал) - не последнее дело. И что учитывая его, можно избавиться от многих проблем, от которых архитектура не спасает (пресловутая уязвимость переполнения буфера, принцип языковых процессов в едином адресном пространстве -Xerox Cedar, Oberon System, ETH Bluebottle, Microsoft Singularity и др.).

    Итак, выбор базового языка важен. В любой ОС есть "три слона", на которых она покоится: (1) исполнение программного кода, (2) управление активностями (процессами) и (3) распределение ресурсов. Память является ключевым элементом, той самой гигантской черепахой, на которой в моделях мироздания древних и располагались три слона. От того, сколь грамотно будет продумана организация памяти, содействующая эффективному и надёжному исполнению основных языков ОС, зависит многое. Сколь сильно она должна от них абстрагироваться? Окажется ли полезным для возведения ОС знание специфики работы с памятью в том или ином языке из очерченного нами набора? Другим ключевым элементом является процессорная архитектура. Сколь оптимально может быть адаптирована к ней ОС с учётом взрывного роста разработок в этой сфере и приоритетом развития многоядерных процессоров? Какими средствами виртуализации можно снизить зависимость программного обеспечения от железа?


    Контроль сложности - основная проблема программирования

    Мы идём не лобовым путем: вместо ставки на популярные языки занимаемся разработкой и реализацией своих, что также вызывает немалые вопросы и сомнения. Зачем делать какой-то инструментарий, когда можно пользовать готовое? Вполне типичная точка зрения. Давайте попробуем разобраться.

    Приведу небольшую выдержку из книги известного советского математика, одного из зачинателей отечественного программирования Александра Семёновича Кронрода "Беседы о программировании" (1963). Она поясняет, почему столь большое внимание при создании новой ОС мы уделяем языкам и инструментарию: "Пусть нам нужно выкопать большой канал. С чего стоит начать? Первое, что приходит в голову,- взять лопаты и копать. И, если не думать, что можно построить экскаватор, то чем скорее возьмешь лопату и чем энергичнее станешь ею действовать, - тем быстрее и глубже будет твоя канава. Ну, а если поверить, что экскаватор построить все-таки можно? Тогда, пожалуй, стоит повременить с лопатой. И как можно энергичнее заняться экскаватором. Особенно, если копать лопатой и строить экскаватор должны одни и те же люди. И, конечно, если канава не нужна немедленно и непосредственно, во имя спасения жизни".

    Сложность и попытка взять её под контроль - вот основной лейтмотив нашего проекта. Это и неудивительно, поскольку именно в этом и состоит, по мнению многих классиков, основная проблема программирования. Незадолго до своей кончины Эдгар Дейкстра в работе "Конец информатике?" (2000, EWD1304) сказал очень мудрые слова: "В то время, как мы знаем, что причиной всех бед является неуправляемая сложность, мы не знаем, ни какой степени простоты можно достичь, ни до какой степени внутренняя сложность разработки в целом должна отражаться на видимых интерфейсах. Мы попросту до сих пор не знаем, насколько сможем выпутаться из этого. Мы до сих пор не знаем, можно ли отличить сложность, присущую самой задаче, от случайной сложности. Мы до сих пор не знаем, будут ли возможны компромиссы. Мы до сих пор не знаем, сумеем ли разработать для сложности осмысленную концепцию, на базе которой сможем построить полезную теорию".

    Пытаться подойти к решению такой грандиозной задачи исключительно простыми средствами - романтический идеализм. Но другой крайностью являются и попытки штурмовать сложность едва ли не еще большей сложностью. В 2005 г. мне довелось пообщаться с Леоном Кацнельсоном (директором IBM по конкурентным технологиям при департаменте информационного управления). Вот краткая выжимка беседы с ним. Я тогда упомянул о работе Пола Хорна (главный вице-президент IBM Research) по автономному компьютингу. В ней высказывается следующая мысль: сложность современных ИТ-систем - это серьёзный вызов. Как это ни парадоксально, чтобы избежать сложности, утверждает Хорн, надо делать ещё более сложные системы. Т. е. сложность преодолевается через сложность. Хорн подчёркивает, что следуя принципам автономного компьютинга, надо системы ещё более усложнять, но внедрять при этом элементы адаптивности. Кацнельсон отреагировал на мысль Хорна весьма дипломатично, сохранив парадоксальность: "Чем сложнее система, тем больше необходимость её упрощать. При этом сам процесс упрощения ещё больше усложняет эти системы".

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

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


    C++ и Оберон - два подхода к борьбе со сложностью

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

    Вирт в Обероне шёл простым и понятным путем. Сначала выбирается область применения инструмента (цели): системное программирование применительно к разработке операционной системы Oberon (однопользовательская ОС класса Developer's OS), в которой главными требованиями являются динамическая расширяемость систем (extensible programming) при изолированности (герметичности) системы типов. Затем используется принцип концептуальной экономии (по Чарльзу Хоару): Вирт брал сбалансированный набор базовых сущностей и их отношений (связей, правил - моделью была классическая Модула-2) и удалял из языка (синтаксиса и семантики) те вещи, которые не разрушали исходные цели (целеполагание). Другими словами, искал ту грань, за которой система (в данном случае язык Оберон) будет оптимизирована по критерию концептуальной экономии и не рассыплется. На мой взгляд, этой цели он добился. Для реализации системы Oberon (Oberon System) язык Оберон выглядит близким к идеалу.

    Теперь посмотрим на C++. Цели, которые ставил перед собой Бьёрн Страуструп, существенно отличались от целей, поставленных Виртом перед языком Оберон. Страуструп хотел, с одной стороны, воплотить идеи своего любимого языка (Симулы-67), оставаясь на базе синтаксиса (и семантики!) Си. Т.е. обеспечить преемственность. И в этом плане с Виртом они не сильно расходятся (преемственность по синтаксису и семантике у Оберона с Модулой-2 даже куда выше, чем у Си и C++). А вот с другой - он хотел создать объёмный универсальный самодостаточный язык, который может практически всё. Поиск пресловутого философского камня.

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

    Тем, кто интересуется этой проблематикой, очень рекомендую внимательно перечитать (под призмой того, что здесь пояснил) книгу Б.Страуструпа "Дизайн и эволюция C++" (1994; пер. на русский язык - 2006). Я вообще рассматриваю эту книгу как замечательное пособие нам, участникам проекта "Роса" (где будут создаваться новые языки и диалекты). Прежде всего в отношении того, как не надо наступать на чужие грабли.

    Вот цитата из этой книги (с. 113-114), характеризующая процесс принятия решения в C++, когда вместо приоритета качества, технологического совершенства во главу угла ставится удобство для нынешних программистов (потакание стереотипам): "Пришлось принять правило Cи о том, что глобальные имена по умолчанию видимы в других единицах трансляции. Просто не было поддержки для правила, более жестко ограничивающего область видимости имён. Это означало, что в C++, как и в Cи, не будет механизма для выражения модульности на уровне выше класса или файла. Это послужило причиной многих жалоб, пока комитет ANSI/ISO не принял пространства имен в качестве механизма, позволяющего избежать непреднамеренного совмещения имен. Однако Дуг Макилрой и другие возражали, что Cи-программисты не оценят язык, где каждый объект и функцию, которые должны быть доступны из другой единицы трансляции, придется явно объявлять таковыми. Возможно, в то время они были правы и уберегли меня от серьезной ошибки."

    А вот ключевой момент, отличающий подходы Вирта и Страуструпа. Он заключен в следующей цитате (см. с.276). Привожу слова Страуструпа: "Множественное наследование виделось как первое существенное расширение C++. Некоторые опытные пользователи C++ считали, что это ненужное усложнение, которое повлечет за собой поток новых средств. Например, на самой первой конференции по C++ в Санта-Фе Том Каргилл сорвал аплодисменты, высказав забавное, но не очень реалистичное предложение: каждый, кто предлагает включить в C++ новое средство, должен сказать, какое из старых средств, равных по сложности новому, следует исключить. Мне такой подход нравится, но я всё же не могу утверждать, что C++ стал бы лучше, не будь в нём множественного наследования, или что C++ образца 1985 г. лучше C++ 1993 г. Веселье продолжил Джим Уолдо. Он продолжил мысль Тома, высказав следующую идею: обязать предлагающих новые средства пожертвовать... свою почку. Это, по мнению Джима, заставит каждого не один раз подумать, прежде чем вносить предложение, причём даже лишённые инстинкта самосохранения не смогут внести более двух предложений".

    Вот в чём проблема: если кто-то пытается применять систему (язык Оберон) вне той задачи, для которой она предназначалась и оптимизировалась, то следует задуматься: виноват инструмент, его автор или же тот, кто (не понимая инструмента) пытается его применять где можно и где нельзя. Оберон - это язык-ядро, язык-чемоданчик. Это не язык-оболочка, не язык-сундук. Для использования в области промышленного производства ПО, промышленной разработки сложных программных систем, характеризующейся разделением труда при наличии большого числа программистов, язык Оберон требует соответствующей инфраструктуры, не отвергающей, а впитывающей в себя дополняющие языки (в их синтаксических одеждах). Только в этом случае он, на мой взгляд, будет адекватен решаемым задачам в этой сфере. В качестве иллюстрации к сказанному хотел бы напомнить слова великого немецкого философа Имманула Канта, которые нам стоит помнить: "Кто отказался от излишеств, тот избавился от лишений".


    Сундуки и чемоданчики

    Языки-сундуки и языки-чемоданчики. Интересная ассоциация проф. В.Ш.Кауфмана. Думаю, имеет смысл сделать большое отступление и ввести читателя в контекст обсуждения. Я очень рекомендую тем, кто серьёзно интересуется этими вопросами (языков и их концепций), перечитать от корки до корки блестящий курс д.ф.-м.н. Виталия Шахновича Кауфмана "Языки программирования. Концепции и принципы". - М.: Радио и связь, 1993. Вышел мизерным тиражом в 2 тыс.экз. Этот фундаментальный курс читался на факультете ВМиК в МГУ, подготовлен с активным участием С.И.Рыбина. Ныне проф. Кауфман - гражданин Финляндии.
    Работает в компании Fatman (Хельсинки). Ранний черновик книги Кауфмана (1986), отличающийся от печатной версии, см. http://www.europrog.ru/book/plvk1986r.pdf

    Вот что пишет проф. Кауфман. Далее идут выдержки из его книги.

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

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

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

    Два выделенных источника сложности - семантический разрыв и незнание мира - полезно трактовать как два различных аспекта единого источника: рассогласования моделей проблемной области - области услуг, задач, операций у пользователей и исполнителей. При таком взгляде создаваемая программа выступает как средство согласования этих моделей. Чем ближе исходные модели, тем проще программа... Безнадёжно строить языки программирования с моделями, заготовленным "на все случаи жизни". Однако можно попытаться построить язык программирования, на базе которого будет удобно (относительно несложно, с приемлемыми затратами) строить модели весьма разнообразных проблемных областей. Такой язык называют базовым языком программирования... Главное назначение базового языка - строить модели проблемных областей с тем, чтобы уменьшить сложность программирования в них. В качестве основных средств понижения сложности мы выделим абстракцию-конкретизацию и прогнозирование-контроль. Первое средство будем кратко называть аппаратом развития (так как по существу оно служит для построения над исходным языком новой знаковой системы...)... Второе средство будем называть аппаратом защиты (так как оно используется, в частности, для защиты построенных абстракций от разрушения)...

    <===

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

    ===>
    На примере Ады мы видели, как выявляемые технологические потребности приводили к новым конструктам. Может показаться, что на этом пути будут получаться все более качественные языки программирования. К сожалению, большинство современных индустриальных языков программирования носят на себе родимые пятна такого примитивного критерия качества... Основной принцип конструирования, которым руководствовались авторы этих языков программирования, в упрощенной форме можно сформулировать так: для каждой значимой в проблемной области технологической потребности в языке должно быть готовое выразительное средство. Короче: каждой значимой потребности - новый конструкт. Этот принцип заготовленности конструктов и назовём принципом сундука (именно в сундуках хранят много всякого на всякий случай). Как показывает опыт, безудержное применение приципа сундука ведёт к громоздким, сложным, дорогим в реализации, обучении и использовании языкам-монстрам с тяжеловесным базисом и несбалансированными средствами развития. Сундук и есть сундук!

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

    Итак, ориентация на принцип сундука повышает собственную сложность языка программирования, что по закону распространения сложности приводит к росту сложности его освоения (которая, в свою очередь, может оказаться катастрофической для его судьбы - достаточно сопоставить судьбу Паскаля и Алгола-68). Вспомним, однако, что основной принятый нами критерий качества базового языка программирования - его способность снижать сложность, помогать в борьбе с основной проблемой программирования. Налицо тупик, в который ведёт принцип сундука. Вирту принадлежит принцип, указывающий выход из этого тупика.

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

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

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

    Идея монопольного языка программирования, с одной стороны, очевидным образом перекликается с идеей единого универсального языка программирования, которая, как известно, многократно терпела фиаско и вновь воскресала на очередном этапе развития программирования. Ясно, что идея монопольного языка программирования жизнеспособнее за счёт отказа от претензий на пригодность для любых классов задач, классов пользователей, любых компьютеров и программных сред. Более того, она фактически реализована в таких языках программирования, как Си для UNIX-совместимых сред, Эль-76 для отечественной серии "Эльбрус", Том в одноименной интегрированной системе В.Л.Темова и др.

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

    <===

    Проф. В.Ш.Кауфман сформулировал четыре заповеди программиста:
    1. Выбирай не столько базовый язык программирования, сколько базовую операционную среду (с учетом потребностей всего жизненного цикла создаваемого изделия).
    2. На основе выбранного базового языка программирования создавай свой проблемно-ориентированный язык для каждой значимой задачи с учетом выбранной технологии.
    3. Язык программирования тем лучше, чем дешевле с его помощью оказывать программные услуги.
    4. Минимальное ядро языка программирования плюс проблемно-ориентированные языковые модули - разумный компромисс сундука с чемоданчиком.

    RB31. Публичный старт проекта "Роса"

    Предпосылки проекта "Роса" сформулированы в моей статье "Нужна ли России своя операционная система?" (июнь 2007 г.) С авторским вариантом в формате Adobe PDF можно познакомиться здесь - http://www.europrog.ru/rb/ros.pdf. Публикация прошла в журнале "Мир ПК": №7/2007 и №8/2007.

    Заметки по началу проекта:
  • RB22. О проекте создания отечественной перспективной ОС
  • RB23. О языках реализации в проекте новой ОС
  • RB25. Новая европейская ОС
  • RB26. Дуальность и другие контуры "Росы"
  • RB27. Пути восхождения к новой ОС
  • RB28. Закон Гордона Мура и закон Дэвида Мэя

    Другие заметки, задающие контекст проекта: http://rbogatyrev.livejournal.com/2007/05/28/

    ------


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

    Та небольшая начальная команда (инициативная группа), которая сейчас сформирована (примерно 20 человек из России, Украины, Беларуси, Узбекистана), занималась эти несколько месяцев (с июля по ноябрь) прокладыванием лыжни по целине. В начале декабря, когда завершится важная часть предпроектных исследований, мы приступаем к набору двух групп - исследовательской и проектной. Это научно-исследовательское и проектно-конструкторское подразделения. Макетированием ОС (включая пробное проектирование отдельных элементов ОС) будет заниматься проектная группа. Правила будут опубликованы на официальном сайте проекта, который ориентировочно откроется в декабре 2007 г. Решение о включении в проект (в том или ином статусе) будут принимать руководители групп совместно с техсоветом.

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

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

    Должен отметить, что с самого начала, как и ожидалось, мы столкнулись с активным неприятием нашего проекта. Такова жизнь. Есть люди, которые хотят заниматься созданием нового, понимают, сколь огромная работа предстоит и открыто её делают. Есть и те, кому это не нравится. Это не нравится некоторым апологетам UNIX и Linux, это не нравится некоторым апологетам Оберонов. Нормальная и понятная ситуация. С другой стороны, проект никоим образом не направлен на дискредитацию других проектов. Пусть каждый занимается своим делом. Видятся два варианта:
    1) создаётся новое;
    2) развивается старое.

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

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

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

    == Стратегические цели проекта

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

    == Тактические цели проекта

    1. Создание, развитие и предоставление в свободный и неограниченный общественный доступ современной перенацеливаемой ОС нового поколения (семейство ОС "Роса").

    2. Разработка открытой развиваемой инструментальной метасистемы, близкой к концепции лексикона программирования (развитие идей академика А.П.Ершова).

    3. Практическое воплощение новой модели организации распределённого сообщества специалистов (открытое исследовательское программирование, Open Research Programming).


    Подходы к реализации проекта

    Итак, имеем три составных части проекта:
    1. Целостный системный подход (операционная система как сложная программная система, метасистемное программирование).
    2. Адекватный инструментарий (лексикон программирования: методология, языки спецификации и реализации).
    3. Процесс открытой исследовательской разработки (Open Research Programming).

    Некоторые пояснения. При создании сложной программной системы требуется выделить значимые аспекты сложности, соответствующие критерии/метрики, принятую политику контроля сложности. Операционная система нового поколения должна быть многоцелевой (разные ниши). Это подразумевает наличие средств статического и динамического перенацеливания/адаптации ОС (под спектр задач, аппаратные платформы). Должна быть обеспечена технологическая независимость (от сторонних производителей) процессов разработки и последующего развития ОС. Это предусматривает наличие собственных систем программирования (независимость от изменений языка, независимость от сторонней реализации языка). Новая методология ориентируется на поддержку метасистемного и асинхронного программирования. Предусматривается целостная интеграция спецификаций (деклараций) и конкретизаций (программ) с контролем их рассинхронизации. Основу работы составляют три взаимодополняющих формы программирования (синтезирующее, сборочное, конкретизирующее - по А.П.Ершову), охватываемые лексиконом программирования - см. "Предварительные соображения о лексиконе программирования" (1983).

    Основные (привилегированные) языки формируют ортогональную систему (взаимодополняющий минимум языков, покрывающих ведущие парадигмы/подходы программирования). Ортогональные языки образуют два уровня - базис (собственное микроядро инструментария) и надстройку (минимум наиболее популярных языков).

    Что касается многоядерности и многопроцессорности, хотел бы подтвердить то, что они фигурируют как важные в манифесте проекта. Здесь стоит сослаться на ранее озвученные моменты (которые в том или ином виде входят в манифест): "Мы имеем чёткое представление о том, что новые процессорные архитектуры не могут эффективно использоваться существующими ОС (не только Windows и Linux). Это глубинные проблемы научно-технологического характера".

    Некоторые комментарии.

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

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

    3. К распараллеливанию можно подходить с двух сторон: со стороны синхронного параллелизма (в последовательном потоке управления выделяются параллельные ветви) и асинхронного параллелизма (нет последовательного потока, есть причинно-следственная связь, которая служит основой для распараллеливания). Оба подхода могут взаимно моделировать друг друга. Первый - является магистральным в этой проблематике. Второй - более перспективный. Достаточно познакомиться поглубже с работами В.Е.Котова и советским проектом МАРС (модульные асинхронные развиваемые системы). Наш проект я рассматриваю как естественное продолжение тех работ, но на ином уровне понимания, на новом ветке эволюции.

    4. Технологическая проблема современных ОС (Windows, Linux, Mac OS X и др.) в отношении эффективного использования мультиядерных архитектур проистекает из-за отсутствия достаточно адекватной хинтовки со стороны программиста.


    Контурный портрет новой ОС

    Если говорить о контурном портрете, то можно выделить три главных момента:
    1. Технологическое совершенство (метасистемное программирование, асинхронность, надёжность/безопасность, математический фундамент).
    2. Контроль сложности (ортогональная система языков, микроядерность языкового базиса, инварианты, трансформации спецификаций).
    3. Врождённое эволюционирование (перенацеливаемость, адаптивность, безболезненная расширяемость, вариативность).

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

    Фактически Оберон-системы определяют новый перспективный класс ОС: Custom OS (настраиваемая ОС, сращиваемая с базовым приложением). Она занимается всё теми же задачами любой ОС: распределение ресурсов и управление процессами, при этом может работать поверх другой ОС (виртуализация приложений). Оберон-системы определяют ещё один класс ОС: Developer's OS. Это особый мир для разработчика, который позволяет ему получить максимально удобную инструментальную среду (не просто IDE или среду программирования), которая является и операционной средой для всех приложений этого мира.

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

    В сфере ОС мы идём от двух полюсов - UNIX и Оберонов. UNIX - это хорошо известный готовый фундамент годами отшлифованных решений, который можно применять в тактическом плане. Что касается много менее известных Оберонов, давайте посмотрим, на что ориентировались Oberon System и Bluebottle.


    Oberon System создавалась как система для программистов. Свой собственный мир. Самодостаточный. Удобство технологического процесса применительно к языку Оберон. Т.е. это ОС класса Developer's OS с ограничением на количество базовых языков - система принципиально моноязыковая. Побочным следствием (ответвлением) Oberon System стала возможность использования её в качестве "браузер-машины". Т.е. в ней были зачатки Web OS. В середине 1990-х (когда решения Oberon System в этом направлении соответствовали рыночной ситуации развития) можно было говорить о конкурентноспособности. В нынешней ситуации отставание заметное (не идейное, а конкретных реализаций).

    Центральной в системе Оберон является концепция активных документов (вместо низкоуровневой ориентации на файлы). Ввод-вывод программ можно унифицировать через единое представление - через документ. В активный документ можно встраивать всё что угодно (аплеты и сам этот термин впервые появились в системе Oberon в начале 1990-х годов). В системе Oberon документ становится единой, ключевой сущностью для пользовательского интерфейса. Более того, приложение воспринимается как документ. Любые элементы документа (включая даже заголовки окон) могут интерпретироваться на лету (их нужно просто выделить и нажать "кнопку", если только не предусмотреть принудительное блокирование таких операций). Ведь их универсальный интепретатор (система Oberon) всегда под рукой.

    В свете нынешнего противостояния Microsoft-Google актуальным становится новый взгляд на пользовательский интерфейс, новые механизмы его поддержки (что мы, разумеется, учитываем в рамках создания "Росы"). Он должен быть всепроникающим. Потому-то и неизбежен интерес к позабытым решениям, которые были построены два десятка лет назад (когда люди основательнее думали и обстоятельнее работали). Впрочем, в Microsoft Research сейчас несколько групп вплотную заняты подобной проблематикой. В одной из них (в Кембриджской лаборатории, в Англии) работает один из участников проекта Oberon Ральф Соммерер - ученик Никлауса Вирта. Он также входит в состав Microsoft Live Labs. Напомню, что система Oberon создавалась под влиянием идей той самой системы Cedar (Xerox Palo Alto Research Center, 1978-1986), которую теперь представляют как прообраз нынешней Microsoft Singularity. Причем разработка основы Oberon System заняла... 5 человеколет (два профессора ETH Zurich - Никлаус Вирт и Юрг Гуткнехт, 1985-1988).

    Теперь взглянем на Bluebottle (детище команды проф. Гуткнехта). В этой системе уже сделана попытка уйти от моноязыковости (за счёт поддержки Java). Но сама система в меньшей степени Developer's OS (хотя внутри хранит старый облик системы Oberon) и больше заточена на пользователя, которому нужны эффективные средства обработки мультимедиа-информации. Потому и сделан акцент на производительность для подобных задач (с учётом мультипроцессорности). Потому и налажены контакты с коммерческими структурами (Япония, Китай), за счёт которых и осуществляется развитие и продвижение проекта.

    Некоторые характеристики. Ядро Bluebottle (Aos) занимает 7 тыс. 210 строк исходных текстов на Active Oberon (около 50 Кбайт объектного кода). Файловая система, сетевые средства, сервисы и пользовательский интерфейс добавляют еще 15 тыс. 560 строк (140 Кбайт). Для сравнения: ядро BSD 4.4 занимает 58 тыс. 289 строк на Си (за вычетом файловой системы, сетевых протоколов, драйверов устройств и др., которые добавляют еще 143 тыс. 962 строки исходного текста). Ядро Linux 2.4 занимает около 420 тыс. строк (исключая файловую систему, драйверы и др, которые добавляют еще около 2,4 миллиона строк). В Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux. Это связано с сокращением накладных расходов в том числе за счет уменьшения дескрипторов.

    По классификации я бы отнёс Bluebottle к классу Custom OS, когда можно к готовому ядру и базовому системному каркасу достыковать необходимый технологический сервис и получать в итоге заточенную под задачи специализированную ОС (BlackBox - ещё один пример подобного применения, только здесь ОС спрятана, а инструментарий поставлен во главу угла). Нетрудно заметить, что вариант Custom OS есть ни что иное как перенацеливаемость полуфабриката.

    BlackBox реализует схему виртуализации приложений, когда распределение локальных ресурсов и управление локальными процессами (действующими в рамках единого адресного пространства) находится в ведении самой прикладной системы (её ран-тайма). Из подобных подходов можно отметить средства компании GreenBorder, недавно тихо поглощенной Google. Её средства обеспечивают поддержку безопасных контейнеров, внутри которых можно запускать браузеры, видео- и аудио-плееры.


    Рекомендуемые источники по ETH Bluebottle:

  • Официальная страница проекта Bluebottle.
  • Ярослав Романщенко. Установка и настройка Bluebottle.
  • Реализация Bluebottle поверх Windows: ETH WinAos System (Bluebottle for Windows).
  • H.Eberle, J.Gutknecht. Architectural Support for Online Multimedia Services (1999).
  • P.Muller. The Active Object System Design and Multiprocessor Implementation (2002).
  • P.Reali. Using Oberon's Active Objects for Language Interoperability and Compilation (2003).
  • T.Frey. Bluebottle: A Thread-safe Multimedia and GUI Framework for Active Oberon (2005).
  • "Бутылка без джинна (Oberon и нелетние мысли)" (Компьютерное обозрение, 23.07.2002).

    Несколько слов о Microsoft Singularity, которую мы рассматриваем как нашего технологического конкурента. По многим причинам. Одна из них - идеологическая близость (надёжность ОС зависит от языка). Во главу угла в Singularity ставят (по крайней мере, декларируют) надёжность и безопасность (reliability, safety, security).

    Что вкратце предлагает Singularity? Основной их тезис: можно с нуля построить новую ОС, которая во главу угла ставит надёжность/безопасность, а не производительность. При этом её производительность оказывается даже выше, чем у известных ОС. Главная идея - герметизация всего по возможности.

    В основе Singularity лежит триада: SIP-CBC-MBP. Объектное пространство (SIP, software-isolated processes), регламентированные каналы (CBC, contract-based channels), декларированные программы ("таможенная декларация", MBP, manifest-based programs). Быстродействие системы достигается за счёт исполнения большой части кода в режиме ядра (SIP является аналогом пропускной системы, предъявил пропуск - на территории можешь действовать как свой). В этом плане явные параллели с Oberon System и Bluebottle (аналогично, с их американскими прототипами - Xerox Mesa и Xerox Cedar).

    Понятие адресного пространства вытесняется (но не заменяется!) понятием объектного пространства. При этом для организации объектного пространства не требуется аппаратной защиты памяти. Внутри объектного пространства можно порождать активности (потоки/нити, threads). При этом герметичность обеспечивается жёстким требованием: нельзя разным объектным пространствам иметь ссылки на чужое внутреннее содержимое, т.е. можно обмениваться ссылками только на объекты, хранящиеся в общей памяти (Exchange Heap).

    Всё взаимодействие строится через каналы. Они и определяют унифицированный механизм обмена. Что важно: каждое объектное пространство может иметь свой менеджер памяти (сборщик мусора) и свою исполняющую систему (ран-тайм). Это важное отличие от Оберонов.

    При оценке Singularity уже явно сформировался неверный стереотип. SIP не отрицает комбинированные варианты использования адресного пространства. Помимо SIP есть и HIP (hardware-isolated processes, процессы в понимании UNIX, с аппаратной защитой памяти). Это задаёт гибридные схемы.

    Что ценно в Singularity - система явно заточена под сетевую среду: унификация общения между объектными пространствами позволяет осуществлять это как вблизи (в рамках одного мультиядерного процессора), так и вдали - между аппаратными кластерами и удалёнными компьютерами. Ахиллесовой пятой является расширяемость - здесь у Singularity больше вопросов, чем ответов. Неудобство описания каналов вполне разрешимо - достаточно (как и в реальной жизни) иметь типовые контракты, которые просто конкретизировать (т.е. не делать всегда с нуля).

    Отталкиваясь от Модула/Оберон-направления и анализируя Singularity (а также две интересные в этом плане европейские ОС - английскую RMoX (Raw-Metal occam Experiment, на основе Occam-pi) и немецкую JX (на основе Java), мы ориентируемся на одно из главных их достижений - локализация сущностей (модули-отсеки) и безопасность работы с памятью, обеспечиваемая средствами языка. Это позволяет прийти к понятию особых safe-активностей, которые могут взаимодействовать в рамках единого адресного пространства без лишних накладных расходов. Очевидно, что появляются надёжные (safe) и ненадёжные (unsafe) зоны. Те и другие могут быть проверены (вручную, верификацией, тестами и т.п.), после чего могут переходить в разряд проверенных (trusted).

    Эти механизмы напрямую связаны с вопросами информационной безопасности. Хорошо известно, что полноценное её обеспечение (для trusted OS) требует проработки на самом нижнем уровне (вплоть до микроядра). Попытки поверх ненадёжной схемы навесить потом прибамбасы защищённости - это в корне неверный подход. Дыры закрыть не удастся.

    Несмотря на исследовательский характер работ Microsoft Singularity её ориентируют (заявляют о нишах) в отношении серверного направления (Server OS).

    Рекомендуемые источники по Microsoft Singularity:

  • Официальная страница проекта Singularity (Microsoft Research).
  • "Проект Singularity: обзор" (RSDN, 02.03.2006).
  • "Возвращение микроядерных операционных систем" (Открытые системы, 5/2006).
  • "Надёжные и защищённые операционные системы?" (Открытые системы, 6/2006).
  • "ОС Singularity, или Когда надежность становится требованием" (Компьютерное обозрение, 26.01.2007).
  • Олег Михайлик. Singularity.

    Что получается: исходя из наших ближних ориентиров (Oberon System, Bluebottle, Singularity) вырисовываются три ниши -- Developer's OS, Web OS и Server OS.

    Важно обратить внимание на следующее обстоятельство. Подход к ОС у нас не лобовой, а "окольный" (высокотехнологичный):

    1. Методология. ОС - сложная программная система, для распределённой коллективной разработки которой надо применять соответствующую методологию (методологию надо сначала разработать, а потом реализовать её инструментальный фундамент).

    2. Языки. Языковой базис (структура и конкретные языки) играет ключевую роль в разработке и контроле сложности.

    3. Формальные модели. Компактность, надёжность и адаптируемость ОС может быть достигнута за счёт применения формальных моделей (конечные автоматы, сети Петри, нейронные сети).

    Эта триада "методология-языки-формализмы" критична для реализации новой ОС. Её надо будет делать (можно и в параллель с макетированием). Но раз она будет, имеет смысл учитывать её наличие как автоматически получаемое дополнительное потребительское качество новой ОС.

    Если удастся реализовать намеченную программу, то мы автоматически получаем основу для Developer's OS и Custom OS. Тем не менее, здесь не стоит наступать на грабли Oberon System, когда система для разработчика потом эволюционирует (анархично) в сторону конечного пользователя - это приводит к очень конечному числу таких конечных пользователей. Но стоит понимать, что Developer's OS - скорее системная ниша.

    В качестве потребительского (прикладного) ориентира интерес для нас представляет Web OS. Мы её рассматриваем не в узком смысле (как это делает Google). Т.е. не только удалённых сервисов и минимального слоя поддержки на стороне клиента (тонкий клиент). Google исходит из доминирования Microsoft на клиенте. Мы же можем набраться наглости и исходить из нашего клиента (полностью), как это делает и сама Microsoft. Соответственно будет и наш сервер (в понимании задач Web OS, т.е. связка с Server OS). Клиентский вариант Web OS может быть как максимально усушенным (до уровня ОС в мобильном телефоне), так и полноценно развит - на массовых ПК (и далее). Серверный вариант для Web OS может быть конкретизацией серверной ОС.

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

    "Роса" (в ряде своих конкретизаций) по всей видимости не будет сильно отступать от общемировой тенденции использования гипервизоров (hypervisors), мониторов виртуальных машин - единого центра управления виртуальными машинами для разных ОС. Это означает потенциальную возможность одновременной работы "Росы" с несколькими внешними/гостевыми ОС (семейств Windows, Linux, Mac OS X). А также будет обеспечивать подъездные пути для того, чтобы сама "Роса" могла запускаться в известных гипервизорах (напр., под английским Xen).


    Первые впечатления

    Теперь о некоторых наблюдениях по итогам предпроектных работ.

    Довольно неожиданным для меня эффектом нашей работы стало сразу рельефно проявившее себя отличие используемой нами модели открытого исследовательского программирования (Open Research Programming) от традиционной модели программирования c открытыми исходными текстами (Open Source). В первом надо сначала много думать, сохранять по возможности максимальную вариативность с выделением магистральных решений и лишь потом делать (при уточнении всех требований и ограничений разработки). Во втором предпочитают сразу "прыгать". Это влияет не только на микроклимат в команде (далеко не все готовы окунуться в принципиально иную среду работы), но и на подход к выбору проектных решений. Т.е. то, ради чего модель Open Research Programming и задумывалась (взвешенный, обоснованный выбор проектных решений), стремятся подменить традиционной спешкой с передачей функции принятия решений сразу конкретным исполнителям. К чему это ведёт? В исследованиях важно осознавать недостатки уже существующих и применяемых подходов, проводить тщательный анализ, на основе которого и вырабатывать новые. Эти новые требуют терпеливого ухода и заботы (иначе они просто никогда не вырастут). Это особая форма кредитования доверия к идеям. Важно найти необычные, неординарные подходы и постепенно, шаг за шагом пытаться довести их до "товарного уровня", до уровня конкуренции с существующими (даже просто продумыванием и отчуждаемым изложением всех деталей). Только тогда можно приниматься за полноценную активную критику. Если с порога отметаются идеи, а взамен, не изучив и не проработав толком новые, предлагается опираться на известные (метод "реклея" - резать и клеить) - это не исследования; это разработка. И, к большому сожалению, вроде бы столь элементарная вещь с большим трудом доходит до осознания теми, кто интересуется проектом или в нём участвует. Значит, надо больше и детальнее разъяснять. Это потребует много больших затрат времени и сил, но иначе стену непонимания вряд ли удастся ликвидировать.

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


    Ближайшие планы

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

    О планах работ на ближайшее время:

    1. Первое публичное представление проекта: 30 ноября 2007 г. (семинар по системному программированию в Московском авиационном институте, МАИ).
    2. Образование новой компании (центр управления проектом): начало декабря 2007 г.
    3. Открытие трёх сайтов (сайта новой ОС, сайта новой компании, нового сайта Европейского центра программирования): декабрь 2007 - январь 2008.
    4. Начало формирования исследовательской и проектной групп: декабрь 2007- февраль 2008.
    5. Подбор научных консультантов и технических экспертов: декабрь 2007 - март 2008.

    Среди консультантов и экспертов, уже давших предварительное согласие на участие в проекте, - ведущие специалисты из научно-исследовательских институтов (по линии РАН), представители профессорско-преподавательского состава вузов России, специалисты ряда отечественных ИТ-компаний.

    В качестве образца-ориентира для ведения проекта подобного масштаба и направленности, а также формирования технологических решений выбран советский проект МАРС (Модульные асинхронные развиваемые системы, 1985-1988; ВЦ АН СССР, ВЦ СО АН СССР, Институт кибернетики Эстонии), проводившийся ВНТК "СТАРТ".

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

    RB30-3. В.Ф.Турчин, теория метасистемных переходов и метасистемное программирование

    Начало заметки см. RB30-1.
    Продолжение заметки см. RB30-2.

    После изучения ряда позабытых работ у меня возникла идея выделить особое направление в программировании, которое затрагивало бы (объединяло в определённом аспекте) теоретическое, системное и прикладное программирование в контексте синтеза и анализа программных систем. Термин "метасистемное программирование" подсказала книга Валентина Фёдоровича Турчина "Феномен науки. Кибернетический подход" (1970). Продолжим изучать субъективный срез по этой книге применительно к термину "метасистемное программирование".

    ------


    Метасистемный переход

    Постепенно мы подошли к ключевому моменту в теории Турчина.

    Вот как он разъясняет суть трансформации систем в ходе их эволюции: “Описание следующих этапов развития нервной системы мы будем проводить в плане более феноменологическом. Для этого нам надо подытожить результаты исследования механизма эволюции на ранних этапах в терминах общих кибернетических понятий. Начав думать в этом направлении, мы легко обнаружим одну общую черту в переходах от низшего этапа к высшему. А именно: все эти переходы совершаются следующим образом. На каждом этапе биологическая система имеет подсистему, которая может быть названа высшим управляющим устройством и которая имеет наиболее позднее происхождение и наиболее высокую организацию. Переход на следующий этап происходит путём размножения этих подсистем (путем многократной редупликации) и интеграции их, т.е. объединения в одно целое с образованием (по методу проб и ошибок) системы управления, во главе которой стоит новая подсистема, которая теперь является высшим управляющим устройством нового этапа эволюции. Систему, состоящую из управляющей подсистемы Х и управляемых ею многих однородных подсистем A1, A2, A3,… мы назовём метасистемой по отношению к системам A1, A2, A3,… Переход с этапа на этап мы назовём, следовательно, метасистемным переходом (рис. 3.1).


    Это понятие будет играть решающую роль в последующем изложении. Метасистемный переход создает высший уровень организации — метауровень по отношению к уровню организации интегрируемых подсистем. С точки зрения функциональной метасистемный переход состоит в том, что деятельность, являющаяся управляющей на низшем этапе, становится управляемой на высшем этапе и появляется качественно новый (высший) вид деятельности, заключающийся в управлении деятельностью. Редупликация и отбор приводят к созданию необходимых структур. Первый метасистемный переход, который мы усматриваем в истории животных, это возникновение движения. Интегрируемыми подсистемами являются части клетки, обеспечивающие обмен веществ и размножение. Положение этих частей в пространстве до поры до времени случайно, неуправляемо. Но вот появляются органы, соединяющие остальные части клетки и приводящие их в движение: клеточная мембрана, реснички, жгутики. Происходит метасистемный переход, который можно определить формулой (1) "Управление положением = Движение".

    На этом этапе движение неуправляемо, никак не коррелировано с движением внешней среды. Сделать его управляемым — следующая задача природы. Управлять движением — значит сделать его определённой функцией состояния среды. Так возникает раздражимость — изменение состояния каких-то участков клетки под действием внешних факторов и распространение этого изменения на другие участки, в частности обеспечивающие движение. Итак, формула метасистемного перехода от второго к третьему этапу такова: (2) "Управление движением = Раздражимость".

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

    Здесь необходимо указать на одну важную черту метасистемного перехода. Когда интегрируемые подсистемы объединяются в метасистему, то вследствие разделения функций между ними происходит их специализация, т.е. приспособление к определённой частной деятельности и утрата способности к другим видам деятельности. Специализация особенно отчётливо проявляется при интеграции целых организмов. Каждая интегрируемая подсистема содержит в этом случае много «лишнего» того, что было необходимо ей для самостоятельной жизни, но не нужно в сообществе, ибо соответствующие функции выполняются другими подсистемами. Так, в многоклеточном организме появляются специализированные мышечные и нервные клетки. Вообще надо отметить, что интеграция подсистем отнюдь не является концом их эволюционирования. Нельзя представить дело таким образом, что системы A1, A2, A3, … размножаются в больших количествах, после чего «над ними» вдруг возникает управляющее устройство X. Напротив, зачатки системы управления образуются, когда число подсистем Ai невелико — всего несколько штук. Только при таком условии, как мы видели выше, может работать метод проб и ошибок. Уже после того, как наметилась управляющая подсистема X, происходит массовая редупликация подсистем Ai, в процессе которой совершенствуются как Ai, так и X. Возникновение структуры управления подсистемами Ai, не завершает, а вызывает бурный рост числа подсистем Ai, и предшествует ему, ибо при этом размножение Ai, становится нужным для организма. Носитель определённого уровня организации разрастается лишь после того, как начинает образовываться новый, более высокий уровень. Эту черту можно назвать законом разрастания предпоследнего уровня. Поэтому и при феноменологическом функциональном описании метасистемный переход проявляется не тотчас же вслед за закладкой нового уровня, а несколько позже, когда предпоследний уровень «войдёт в силу». Метасистемный переход всегда затрагивает два уровня организации.

    Продолжим наш обзор этапов эволюции. Применим принцип метасистемного перехода к уровню раздражимости. На этом уровне возбуждение каких-то участков одноклеточного организма или специализированной нервной клетки в многоклеточном организме происходит непосредственно внешней средой и это возбуждение непосредственно (один к одному) вызывает возбуждение мышечной активности. Что может означать управление раздражимостью? Очевидно, создание нервной сети, элементы которой, в частности эффекторы, возбуждаются не прямо внешней средой, а через посредство сложной управляющей системы. Это тот этап эволюции, который мы связали с понятием сложного рефлекса. Особенно отчётливо виден факт управления раздражимостью на этом этапе в том, что при наличии цели возбуждение эффекторов зависит не только от состояния внешней среды, но и от этой цели, т. е. от состояния каких-то внутренних нейронов сети. Итак, формула этого метасистемного перехода (от третьего к четвертому этапу): (3) "Управление раздражимостью = Сложный рефлекс".
    <…>
    Управление рефлексами надо понимать как создание под действием индивидуального опыта любых переменных связей между этими объектами. Такие связи называют ассоциациями представлений или просто ассоциациями. Термин «представление» понимается здесь в широком смысле — как состояние любых подсистем мозга, в частности классификаторов и эффекторов. Образование ассоциаций мы будем называть ассоциированием (терминология тяжеловатая, зато точная). Итак, пятый этап эволюции — этап ассоциаций. Формула метасистемного перехода на этом этапе: (4) "Управление рефлексами = Ассоциирование".
    <…>


    Понятия рефлекса и ассоциации — не структурные, а функциональные понятия. Связь между стимулом S и реакцией R в рефлексе (рис. 3.2) — не передача информации от одной подсистемы к другой, а переход из одного обобщенного состояния в другое. Это разграничение необходимо, чтобы не смешивать рефлекс как определённую функциональную схему, описывающую поведение, с воплощением этой схемы, т.е. с кибернетическим устройством, обнаруживающим эту схему поведения.

    Путаница легко может возникнуть, ибо простейшее воплощение рефлекторного поведения имеет структурную схему, совпадающую по внешности со схемой на рис. 3.2, только под S и R надо в ней понимать материальные подсистемы, фиксирующие стимул и реакцию. Такое совпадение не совсем случайно. Как мы уже говорили при определении функциональной схемы, разбиение множества всех состояний системы на подмножества, приписываемые вершинам графа, тесно связано с разбиением системы на подсистемы. В частности, с каждой подсистемой, которая может находиться в двух состояниях («да» и «нет»), можно связать множество всех состояний системы в целом, при которых эта система находится в определённом состоянии, скажем «да». Проще говоря, при определении обобщённого состояния мы учитываем только состояние данной подсистемы, а что делается с остальными подсистемами, нам безразлично".


    Ассоциации представлений

    Что есть ассоциация, ассоциирование? Как возникают ассоциации представлений?

    Турчин пишет: “Поскольку с каждым классификатором можно связать одно или несколько обобщённых состояний, иерархии классификаторов соответствует иерархия обобщённых состояний. Вводя понятие классификатора, мы указываем, что каждому состоянию классификатора (теперь мы можем сказать: каждому обобщённому состоянию системы в целом) соответствует наличие определённого понятия на входе системы, т.е. принадлежность входной ситуации к определённому множеству. Понятия «понятие» (аристотелевское) и «обобщённое состояние» близки между собой: и то и другое — множества состояний. Но «обобщённое состояние» — более общее понятие, оно может учитывать состояние не только рецепторов, но и любых других подсистем, в частности классификаторов. Последнее необходимо, чтобы следить за динамикой состояния системы в процессе обработки информации.
    <…>
    Возвратимся от врождённых ассоциаций к вырабатываемым, т.е. собственно к ассоциированию представлений. В различии между суффиксами этих однокоренных слов — вся суть метасистемного перехода от четвёртого к пятому этапу эволюции. Ассоциация — это просто один из аспектов сложного рефлекса, ассоциирование — это управление ассоциациями: образование новых ассоциаций и исчезновение старых. Наиболее полно способность к ассоциированию представлений проявляется как способность к образованию (и, следовательно, распознаванию) новых понятий.
    <…>
    Процесс обучения, если он не сводится к выработке нескольких условных рефлексов (т.е. затрагивает только распознавательную иерархию), включает в себя ещё элемент научения — выработки умения, навыка. Процесс научения также укладывается в схему ассоциирования представлений при том общем смысле, который мы придаём этому понятию. Ведь научение — это выработка и закрепление детального плана для достижения цели, нового плана, которого раньше не было. План можно представить как организованную совокупность ассоциаций".


    Управление ассоциированием

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

    В.Ф.Турчин так это поясняет: “Логика нашего повествования побуждает нас связать возникновение мышления с очередным метасистемным переходом. В настоящее время мы ещё так мало знаем о процессе мышления и о структуре мыслящего мозга, что всякую теорию, претендующую на объяснение этого явления в целом, надо рассматривать как гипотетическую. Следовательно, и к нашей концепции мышления надо относиться как к гипотезе. Однако эта концепция указывает место мышления в ряду естественных явлений и, как мы увидим, приводит в систему обширное множество фактов. В её пользу говорит также полное отсутствие произвольных допущений частного характера, которое обычно приходится делать, когда теория включает структурное описание мало изученного объекта. Ядром нашей концепции является не какая-либо гипотеза о конкретной структуре и механизме работы мозга, а выбор таких функциональных понятий, через которые становится возможным последовательное и достаточно убедительное объяснение фактов, относящихся к мышлению. Итак, мы утверждаем, что появление мыслящих существ, знаменующее начало нового этапа эволюции и даже новой эры — Эры Разума, есть не что иное, как очередной метасистемный переход, происходящий по формуле (5) "Управление ассоциированием = Мышление".

    Чтобы доказать это утверждение, мы будем анализировать следствия, вытекающие из управления ассоциированием, и отождествлять эти следствия с теми формами поведения, которые мы наблюдаем у мыслящих существ. Прежде всего, что такое управление ассоциированием? Представления Х и Y ассоциируются у животного только в том случае, когда они совместно появляются в его опыте. Если не будет их совместного (как правило, многократного) появления, то не возникает и ассоциации. Животное не вольно управлять своими ассоциациями. Оно имеет только те ассоциации, которые ей навязывает среда. Управление ассоциированием означает наличие в мозгу механизма, позволяющего ассоциировать любые два или несколько представлений, которые вовсе не имеют тенденции встречаться в опыте совместно. Иначе говоря, это произвольное, не навязанное внешней средой ассоциирование. Казалось бы, эта акция совершенно бессмысленна. В огороде бузина, а в Киеве дядька — к чему связывать эти два факта, которые на самом деле никак не связаны между собой? Тем не менее, произвольное ассоциирование имеет глубокий смысл. Оно действительно было бы бессмысленным, если деятельность мозга сводилась бы к пассивному восприятию впечатлений, их сортировке, компоновке и т.п. Но у него есть и другая задача, кстати основная, — управлять организмом, осуществлять активное поведение, которое меняет окружающую среду, создаёт новый опыт.

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

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

    Возникновение человеческого общества — крупномасштабный метасистемный переход, при котором интегрируемые подсистемы — это целые организмы. В этом плане его можно сравнить с возникновением многоклеточных организмов из одноклеточных. Однако его значение, его революционность неизмеримо больше… Можно рассматривать общество как единое сверхсущество. Его «тело» — это тела всех людей плюс предметы, созданные и создаваемые людьми: одежда, жилища, машины, книги и т.д. Его «физиология» — это физиология всех людей плюс культура общества, т.е. определённый способ управлять предметным компонентом общественного тела и образом мышления людей. Возникновение и развитие человеческого общества знаменуют начало нового (седьмого по нашему счету) этапа эволюции жизни. Функциональная формула метасистемного перехода от шестого к седьмому этапу такова: (6) "Управление мышлением = Культура".

    Химическая эра
    1. Химические основы жизни
    2. Движение
    3. Раздражимость (простой рефлекс)

    Кибернетическая эра
    4. Нервная сеть (сложный рефлекс)
    5. Ассоциирование (условный рефлекс)

    Эра разума
    6. Мышление
    7. Социальная интеграция, культура

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

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


    Формализация и метасистемный переход

    Появление языка ведёт к постепенной формализации, к появлению формальных языков и метаязыков, новых теорий и метатеорий.

    Турчин пишет: “Превращение языка в независимую от создавшего его человеческого мозга реальность, происходящее благодаря формализации, имеет далеко идущие последствия. Только что созданная языковая машина (теория) становится, как часть окружающего человека мира, объектом изучения и описания с помощью нового языка. Происходит, таким образом, метасистемный переход. Новый язык называют по отношению к описываемому языку метаязыком, а теории, сформулированные на этом языке и касающиеся теорий на языке-объекте, — метатеориями. Если метаязык формализованный, то он в свою очередь может стать объектом изучения с помощью языка следующего уровня и этот метасистемный переход может повторяться неограниченно… Подобно тому, как овладение общим принципом производства орудий для воздействия на предметы приводит к многократному повторению метасистемного перехода и созданию иерархической системы промышленного производства, так и овладение общим принципом описания (моделирования) действительности с помощью формализованного языка приводит к созданию иерархической системы формализованных языков, на которой основаны современные точные науки. Обе иерархии имеют значительную высоту. Невозможно построить реактивный самолет голыми руками. То же относится и к инструментам, необходимым для постройки самолета. Надо начинать с простейших орудий и пройти всю иерархию сложности инструментов, чтобы добраться до самолёта. Точно так же, чтобы обучить дикаря квантовой механике, придется начать с арифметики.

    Углублённое изучение математической теории порождает новые математические теории, которые рассматривают исходную теорию в её различных аспектах. Следовательно, каждая из этих теорий в некотором смысле проще (фундаментальнее), чем исходная теория, подобно тому, как исходная теория проще, чем действительность, которую она рассматривает всегда лишь в каком-то одном аспекте. Происходит расщепление моделей, выделение из сложной модели набора более простых моделей. Формально новые теории столь же универсальны, как исходная теория: их можно применять к любым объектам, которые удовлетворяют аксиомам независимо от их природы. При аксиоматическом подходе различные математические теории образуют, строго говоря, не иерархию по управлению, а иерархию по сложности. Однако, рассматривая те модели, которые на самом деле выражают законы природы (т.е. используются в приложениях математики), мы видим, что математические теории вполне отчётливо делятся на уровни сообразно характеру объекта, к которому они в действительности применяются. Арифметика и элементарная геометрия непосредственно контактируют с неязыковой действительностью, а какая-нибудь теория групп используется для создания новых физических теорий, из которых извлекаются следствия, выраженные на языке алгебры и анализа, которые затем «доводятся до числа» и только после этого сравниваются с экспериментом. И это распределение теорий по уровням соответствует в целом тому порядку, в котором они возникали исторически, ибо возникали они путём последовательных метасистемных переходов. Ситуация здесь в сущности такая же, как и в иерархии орудий производства. Ведь и отвёрткой можно при желании ковырять землю. Однако изобретена она была не для того и нужна в действительности лишь тому, у кого есть винты, болты или шурупы. Теорию групп можно иллюстрировать простыми примерами из обыденной жизни или элементарной математики, но по-настоящему её используют лишь математики и физики-теоретики. Продавцу в магазине или инженеру-практику теория групп нужна не больше, чем отвёртка первобытному человеку".


    Комментарии

    Попробуем немного подытожить сказанное.

    Аркадий Климов (SuperCompilers) сформулировал следующие тезисы, вытекающие из теории В.Ф.Турчина. Их он разбил на два направления: (1) роль в анализе творений природы (и, возможно, других людей), а также (2) роль при совершении собственного творческого акта (конструирования чего-либо).

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

    • 1. Большое число подобных друг другу подсистем (т.н. закон разрастания предпоследнего уровня).


    • 2. Расслоение, специализация изначально однородных подсистем (примеры: многоклеточные организмы, муравейник, общество).


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


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


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


    Второе направление (конструирование):
    • 1. Создание сложной системы с новыми формами сложного поведения не обязательно должно включать непосредственную реализацию схемы этого поведения, но можно, и это эволюционно предпочтительнее, создавать механизмы координации базисных подсистем, ни одна из которых сама по себе не обладает нужными свойствами, так, что нужные свойсва появляются как результат этой координации. (Этот тезис сформулирован в статье Бена Гертцеля "Internet Supermind and beyond".).


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

    Тезисы Аркадия Климова вносят определённую ясность в прагматическую ценность теории Турчина. Но нас интересует её преломление в отношении программирования и создания программных систем.

    Мышление – это создание ментальных моделей процессов окружающего нас мира, восприятие процессов как переходов между базовыми обобщёнными состояниями. Эволюция биологических систем (и не только) подразумевает (по Турчину) постепенно готовящиеся революционные скачки (т.н. метасистемные переходы). Они происходят не сами по себе. Нужен внешний инициатор, катализатор этого процесса. Турчин в своей теории предложил наряду с традиционной схемой "система-подсистема" (традиционной для общей теории систем, теории управления и кибернетики) использовать схему "метасистема-система". В чём разница? В самоорганизации, в формировании (интеграции) из совокупности реплицированных подобных систем более высокой организации — метасистемы — с последующей специализацией подчинённых систем внутри нового "сообщества".

    Метасистема оперирует понятиями (абстракциями, конструктами) находящихся в её ведении систем, которые на новом уровне (метауровне) становятся объектами изучения и воздействия. При этом можно говорить как о восходящем процессе (ре)организации систем, так и о нисходящем.

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

    Интересно отметить то, как соотносится (исторически и идейно) суперкомпиляция Турчина с теорией частичных (смешанных) вычислений, одним из важных результатов которой является автоматическое построение компилятора на основе имеющегося интерпретатора того или иного языка. В.Ф.Турчин в своей статье "A Supercompiler System Based on the Language REFAL" пишет: "В 1976 г. А.П.Ершов сделал в Институте прикладной математики (Москва) доклад о своей работе в области частичных вычислений для трансляции и оптимизации программ. Ершов пришёл к своим идеям независимо от меня и безотносительно контекста какого-либо конкретного языка. После выступления Ершова я с ним встретился и проинформировал о работе по теории компиляции в контексте языка Рефал. В частности, я сделал акцент на важности понятия метасистемного перехода и того, как это может быть использовано для автоматического создания компиляторов. Последнее было упомянуто Ершовым в его работе "О сущности трансляции" (1977)… "

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

    В контексте метасистемного программирования (в нашем понимании) открывается немало интересного и полезного. Отмечу, в частности, идею достижения контроля сложности за счёт упрощения языков программирования с одновременным созданием "многоэтажных" языков (работающих по схеме "метасистема-система"). Такие языки, как Лисп, Рефал, Пролог, Форт, Си, Оккам, Оберон можно рассматривать как языки-ядра. Современные тенденции постоянного наращивания мощи за счёт экстенсивного развития встроенных языковых средств привели к существенному усложнению универсальных языков: C++, Ada, Java, C# и др. пытаются вобрать в себя множество парадигм с максимальным сервисом на уровне языка. Плата за это – потеря контроля над сложностью. Попытки использовать регламентируемые в рамках внутрикорпоративных соглашений подмножества этих языков наталкиваются на очевидные проблемы: надёжность такой регламентации должна обеспечиваться соответствующим компилятором (а не директивными указаниями, костылями и подпорками), т.е. по сути это новый язык с новой реализацией. Подмножества же, формируемые в голове тем или иным разработчиком, наталкиваются на естественные проблемы при коллективной разработке.

    Проф. Вирт при создании трёх своих последних языков (Паскаль, Модула-2, Оберон) шёл в направлении, обратном тенденциям ИТ-индустрии: в каждом новом языке отсекал лишнее (второстепенное) предыдущего языка с добавлением минимума новых ключевых сущностей (модули, расширяемые записи). Эволюция привела его к компактному Оберону, который можно считать эдаким языком-микроядром (по аналогии с микроядерной архитектурой ОС). Для обеспечения эффективного использования этого языка в условиях уже не индивидуального, а промышленного программирования соответствующие средства (прежде всего, архитектурно-инфраструктурного плана) можно вынести на уровень языка, оперирующего сущностями Оберона. Т.е. на архитектурный метаязык (по отношению к Оберону и ряду других языков). Подобная идея прорабатывается в рамках проекта создания новой ОС "Роса". Более того, можно говорить о том, что ранее эскизно обозначенный ортогональный базис языков может быть устроен по многоэтажному принципу: "микроядерные" языки системного программирования (модификации Оберона и Рефала), поверх которых располагаются популярные прикладные языки (в частности, Haskell, Java, Python) с архитектурным метаязыком Metasys.

    Не могу не обратить внимание читателя на очень важную мысль, имеющую самое непосредственное отношение ко всему изложенному. В своей работе "Два взгляда на программирование" (1975, EWD540) Эдгар Дейкстра отмечал: "Похоже, что иерархические системы обладают тем свойством, что нечто, рассматриваемое как неделимое целое на одном уровне, рассматривается как составной объект на следующем, более низком уровне с большей детализацией; в результате дискретность пространства или времени, применимая на каждом уровне, уменьшается на порядок величины при переходе от одного уровня к другому, следующему за ним более низкому. Мы воспринимаем стену через понятие кирпичей, кирпичи – через понятие кристаллов, кристаллы – через понятие молекул и так далее. В результате количество уровней, которые могут быть осмысленно выделены в иерархической системе, в некотором роде пропорционально логарифму отношения между наибольшим и наименьшим дискретами, и поэтому, если только это соотношение не чрезмерно велико, мы можем ожидать появления не слишком большого числа уровней. В области компьютерного программирования наш базовый строительный блок имеет дискретность времени менее микросекунды, но наша программа может потребовать несколько часов вычислений. Я не знаю никакой другой технологии, перекрывающей отношение 1010 и более: компьютер, благодаря его фантастической скорости, кажется, впервые предоставил нам среду, в которой артефакты с высокой степенью иерархичности одновременно и возможны, и необходимы. Этот вызов, а именно противостояние задаче программирования, столь уникален, что новый опыт может рассказать нам очень много нового о нас самих. Он может углубить наше понимание процессов разработки и созидания, он может дать нам лучший контроль над организацией нашего мышления. Если бы он не сделал этого, на мой взгляд, мы вообще не заслуживаем компьютеров! Он уже преподал нам несколько уроков, и один из них, который я выбрал, чтобы акцентировать внимание в этом докладе, заключается в следующем. Мы будем программировать гораздо лучше, если только подойдём к задаче, полностью оценивая её потрясающую сложность, если только мы будем придерживаться скромных и элегантных языков программирования, если только мы примем во внимание свойственные человеческому разуму ограничения и подойдём к задаче как Очень Смиренные Программисты".

    RB30-1. В.Ф.Турчин, теория метасистемных переходов и метасистемное программирование

    Продолжение заметки см. RB30-2.
    Окончание заметки см. RB30-3.

    В предыдущей заметке я постарался вкратце изложить свой субъективный срез книги Джорджа Пойа применительно к идее Эдгара Дейкстры об аналогии между схемами решения задач в математике и программировании. Ассоциация, предложенная Дейкстрой, видится весьма полезной: процесс мышления в обоих случаях имеет больше сходства, чем различий и даёт важный ключ к пониманию разных аспектов сложности процесса программирования. Подобные аналогии отмечал в своей статье "Программирование — вторая грамотность" (1981) и А.П.Ершов: "Законы программирования смыкаются с математическим образованием, образуя единый, но ещё не построенный фундамент воспитания операционного и комбинаторного мышления, способности к абстракции, рассуждению и действию".

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

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

    В своей работе "Научная фантастика и научная реальность в информатике" (EWD952, 1986) Эдгар Дейкстра писал: “Она (информатика – прим. Р.Б.) обладает всей остротой чистой математики, будучи более формальной, чем многие другие отрасли математики. Она не может избежать такой формальности, поскольку любой язык программирования, будучи интерпретируемым механически, представляет своего рода формальную систему. В то же время она обладает всей прелестью прикладной математики, поскольку огромная мощность современных компьютеров даёт такие возможности для создания хаоса, что её методы необходимы, если мы не намерены угодить в ловушку сложности, которую сами же и создали. Научиться не попадать в собственноручно созданную ловушку сложности, сохранять вещи достаточно простыми и научиться эффективно мыслить о своих разработках — вот центральная задача информатики”.

    Продолжим теперь знакомство с другими важными материалами, имеющими отношение к анализу основ такой интеллектуальной сферы, как программирование.

    Как известно, академик А.П.Ершов выделял три ветви программирования: теоретическое, системное и прикладное. Где же между ними проходят границы? Если оставить в стороне теоретическое программирование (как фундаментальную науку) и обратиться к двум остальным, можно заметить, что к сфере системного программирования принято причислять то, что связано с инфраструктурным программным обеспечением. Оно в большей степени абстрагируется от прикладных задач и концентрируется на их отображении (трансляции) на ту или иную компьютерную платформу. Другими словами, выступает в роли посредника между компьютером и прикладной программой. Операционные системы (ОС), системы программирования (языки), системы управления базами данных (СУБД) — вот три кита системного программирования.

    В последнее время реже стали говорить "прикладная программа" и всё чаще – "приложение". Почему? Так удобно. Ведь есть программы, а есть системы. Интуитивно мы вроде бы понимаем, что это разные вещи. Но чем они принципиально отличаются? Сложностью? Весьма расплывчатое понятие. Сложность в программировании чаще носит субъективный характер. Размерами? Вряд ли. Бывают программы в несколько сотен тысяч строк. И системами их назвать язык не поворачивается. Почему? Таков уровень архитектурных решений. В случае программы архитектура вырождена. В случае же системы она присутствует в более-менее развитом виде. Одно и то же приложение можно выполнить в виде программы и в виде системы. Отличаться они будут своей организацией.

    Система является более высокоразвитой формой программного обеспечения, нежели программа. В сфере прикладного программирования с формированием постепенной зрелости процесса разработки ПО и богатого спектра приложений потребность в системах становится всё выше. При этом нет чётко выраженного направления в программировании, которое бы занималось вопросом создания программных систем. Вне зависимости от того, к какой сфере они относятся — системного программирования или прикладного. Опять же на интуитивном уровне понятно, что как только мы переходим от программы к системе, есть много общего (единого) в программировании систем: как тех, что ближе к железу, так и тех, что ближе к прикладным задачам. Как и в области строительства, одной архитектурой здесь дело не ограничивается. Важны и другие, инженерные элементы. (Хотя бы то, из какого "материала" такая архитектура выполнена.) UNIX — это прежде всего архитектура. Язык, казалось бы, играет здесь вторичную роль. Но попробуйте заменить Си на Модулу-2 и вы увидите существенную разницу. При той же архитектуре. Попробуйте заменить фрагменты на Си на реализацию тех или иных формализмов (конечных автоматов, сетей Петри и т.п.). Архитектура та же. А "материал" и инженерные коммуникации несколько иные. Значит, "сопромат" и в программировании — не последнее дело…

    С системами обычно связывают понятие управления. Не будем сейчас вдаваться в дискуссию относительно систем, в которых нет управления. К этому мы ещё вернемся. А пока обратим свой взгляд на уже проработанные направления, имеющие отношение к вопросам синтеза и анализа систем вообще. Тектология А.А.Богданова, праксеология Е.Е.Слуцкого и Т.Котарбиньского, общая теория систем Л.Берталанфи, кибернетика Н.Винера и У.Р.Эшби, системология Г.Н.Поварова… Всё это заслуживает отдельного обсуждения.

    Особняком в этом ряду стоит кибернетика. Она сначала стремительно ворвалась в нашу жизнь, а потом столь же стремительно была предана забвению. Очень уж мы склонны к крайностям. Впрочем, и в годы её расцвета скепсис был немалый, причем даже со стороны тех, кто её развитием реально и занимался. В своей книге "Беседы о программировании" (1963) советский математик и один из первых отечественных программистов Александр Семёнович Кронрод не без чувства юмора (хотя и весьма серьёзно) писал о кибернетике так: "Как должна развиваться наука-кибернетика? Плодотворно. Для этого надо: (1) Чтобы программированием занимались программисты, (2) Механизмами в живом организме занимались физиологи, биофизики, биохимики и т.д., (3) Специалисты по социальным дисциплинам изучали законы, управляющие обществом, (4) Лингвисты и филологи занимались своим делом, (5) Врачи лечили и с этой конечной целью изучали болезни и больных, а также и здоровых, (6) Шофёры водили автомобили (автобусы, самосвалы и т.д.) и (7) Никто без нужды не болтал попусту. А когда врачам нужны теория вероятностей, математическая статистика, дифференциальные уравнения или работа на электронных машинах – им необходимо всемерно помогать в этом деле. И иногда – учить и даже подталкивать, потому что человек часто просто не знает о возможностях чужой науки. И делать это надо профессионально. А наука-кибернетика здесь ни при чём. И автор даже подозревает, что она и ни в каком деле ни при чём. Потому что он лично не слышал ни о каком достижении этой науки-кибернетики. И полагает, что, кроме названия, у науки-кибернетики больше ничего и нет".

    Другой известный советский математик, академик А.Н.Колмогоров высказывал несколько иной взгляд. В 1959 г. в предисловии к книге английского кибернетика У.Р.Эшби он писал: “Сейчас уже поздно спорить о степени удачи Винера, когда он в своей известной книге в 1948 г. выбрал для новой науки название “кибернетика”. Это название достаточно установилось и воспринимается как новый термин, мало связанный со своей греческой этимологией. Кибернетика занимается изучением систем любой природы, способных воспринимать, хранить и перерабатывать информацию и использовать её для управления и регулирования. При этом кибернетика широко пользуется математическим методом и стремится к получению конкретных специальных результатов, позволяющих как анализировать такого рода системы (восстанавливать их устройство на основании опыта обращения с ними), так и синтезировать их (рассчитывать схемы систем, способных осуществлять заданные действия). Благодаря этому своему конкретному характеру кибернетика ни в какой мере не сводится к философскому обсуждению природы “целесообразности” в машинах и философскому анализу изучаемого ею круга явлений”.

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

    После изучения ряда позабытых работ у меня возникла идея выделить особое направление в программировании, которое затрагивало бы (объединяло в определённом аспекте) теоретическое, системное и прикладное программирование в контексте синтеза и анализа программных систем. Термин "метасистемное программирование" подсказала книга Валентина Фёдоровича Турчина "Феномен науки. Кибернетический подход" (1970). О том, как метасистемное программирование соотносится с кибернетикой, мы ещё успеем поговорить. Сейчас же давайте сосредоточимся на сути подхода В.Ф.Турчина.

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

    В.Ф.Турчин. "Феномен науки: Кибернетический подход к эволюции". — http://www.europrog.ru/book/psvt1993r.pdf (1,6 Мбайт). В HTML оригинал здесь: http://www.refal.net/turchin/phenomenon/

    Биографическая справка. Валентин Фёдорович Турчин родился в 1931 г. в г.Подольске Московской области в семье профессора агрохимии. Физик, математик, программист, философ. (Ровно такая же последовательность, такая же широта интересов была в биографии Эдгара Дейкстры.) Окончил в 1952 г. физический факультет МГУ. С 1953 по 1964 гг. работал в подмосковном Обнинске в Физико-энергетическом институте, где изучал рассеяние медленных нейтронов в жидкостях и твёрдых телах и где защитил кандидатскую диссертацию (1957). В 1964 г. оставляет физику, переходит в Институт прикладной математики им. М.В.Келдыша АН СССР и посвящает свою деятельность информатике. В 1966 г. была опубликована его первая работа по метаязыку Рефал, построенному Турчиным на основе рекурсивных функций: “Метаязык для формального описания алгоритмических языков — Цифровая вычислительная техника и программирование” (Москва, 1966). Турчин заложил основы метавычислений, предложив качественно новый метод преобразования и оптимизации программ — суперкомпиляцию.
    В  1967 г. Турчин подписал первое письмо в защиту А.Гинзбурга. В 1968 г. в Самиздате появляется брошюра «Инерция страха». В 1970 г. им подготовлена к печати книга «Феномен науки» (опубликована на английском языке в 1977 г.). В 1973 г. он выступил с открытым письмом в защиту А.Сахарова. После этого перед Турчиным закрываются все возможности научной работы. В 1977 г. он вынужден покинуть СССР и эмигрировать в США. Работал в Институте математических наук им. Куранта в Нью-Йоркском университете (Courant Institute for Mathematical Sciences). С 1979 по 1999 гг. был профессором компьютерных наук в The City College of New York. В 1991 г. совместно с Cliff Joslyn (Los Alamos National Laboratory) и Francis Heylighen (Free University of Brussels) основал проект Principia Cybernetica Project — энциклопедия идей по кибернетической эволюции человечества, концепция Всемирного мозга на основе самоорганизации модулей знаний в Интернете. В 1998 г. стал сооснователем компании SuperCompilers.


    Важное уточнение. В.Ф.Турчин был принят в Институт прикладной математики им. М.В.Келдыша АН СССР с большими проблемами, которые были вызваны ведением им диссидентской деятельности. Как отметил мне в личной переписке Михаил Михайлович Горбунов-Посадов, за неё его и уволили с предыдущей работы. Никто брать его не хотел (да и не мог). Но Михаил Романович Шура-Бура, опираясь на поддержку М.В.Келдыша, взял Турчина в Институт, правда, под честное слово, что диссидентством здесь он заниматься не будет. И Турчин достаточно долго держался. Возможно, именно этим мы обязаны появлению Рефала. Но в конце концов Турчин не выдержал, пришёл к Михаилу Романовичу и заявил, что молчать больше не в силах и, согласно их уговору, увольняется. -- [Благодарю М.М.Горбунова-Посадова за это уточнение].

    Избранные публикации:


    В.Ф.Турчин в своей книге “Феномен науки” сквозь призму кибернетики рассматривает эволюцию различных систем и вводит термин "метасистемный переход". Вот как он его определяет: "Когда некоторое число систем интегрируются в единое целое с возникновением нового уровня управления, мы говорим, что имеет место метасистемный переход. Новая система есть метасистема по отношению к старым. Метасистемный переход является по определению творческим актом. Он не может совершиться под воздействием одних лишь внутренних факторов интегрируемой системы, но всегда требует вмешательства извне, “сверху”.

    Это очень лаконичное разъяснение. Чтобы в нём разобраться поглубже, имеет смысл немного погрузиться в контекст восприятия. Для этого воспользуюсь приёмом избирательного цитирования.

    Во введении к своей книге В.Ф.Турчин разъясняет истоки её замысла: "Принципы, столь общие, что они применимы как к развитию науки, так и к биологической эволюции, требуют для своего выражения столь же общих понятий. Такие понятия даёт кибернетика — наука о связях, управлении и организации в объектах любой природы. В кибернетических понятиях с равным успехом описываются явления физико-химические, биологические, социальные. Именно развитие кибернетики и особенно её успехи в описании и моделировании целенаправленного поведения и распознавания понятий сделали возможным написание этой книги. Поэтому более точно её предмет можно определить так: кибернетический подход к науке как к изучаемому явлению. Идейным стержнем книги является понятие о метасистемном переходе, т.е. переходе от кибернетической системы к метасистеме, включающей в себя множество систем типа исходной, организованных и управляемых определённым образом. Сначала это понятие было положено автором в основу анализа развития знаковых систем, используемых наукой. Затем, однако, оказалось, что исследование под этим углом зрения всей эволюции жизни на Земле позволяет воссоздать связную и подчинённую единым закономерностям картину или, лучше сказать, киноленту, которая начинается с первых живых клеток и кончается современными научными теориями и системой промышленного производства. Эта кинолента указывает, в частности, место феномена науки в ряду других явлений мира и раскрывает его значение на фоне общей картины эволюции Вселенной. Так возник замысел настоящей книги".

    Книга Турчина написана с философским уклоном. При этом читается очень легко. Но после ознакомительного прочтения в ней стоит выделить разные аспекты и перечитать сквозь их призму. Сейчас мы остановимся на "метасистемном программировании", точнее, на его базовых понятиях — метасистемах и метасистемных переходах.

    Слово В.Ф.Турчину: "Важное место в книге отводится проблемам теории познания и логики; они трактуются, конечно, с кибернетических позиций. Кибернетика сейчас ведет наступление на традиционную философскую гносеологию, давая новую, естественно-научную интерпретацию одним её понятиям и отвергая другие как несостоятельные. Некоторые философы противятся этому наступлению, считая его посягательством на свою территорию. Они обвиняют кибернетиков в “огрублении” и “упрощении” истины, в игнорировании “принципиального различия” между формами движения материи (и это несмотря на тезис о единстве мира!). Но философ, которому чуждо землевладельческое отношение к различным областям знания, должен приветствовать атаки кибернетиков. В своё время развитие физики и астрономии уничтожило натурфилософию, избавив философов от необходимости говорить приблизительно о том, о чём ученые могут говорить точно. Очевидно, развитие кибернетики сделает то же с философской гносеологией или — скажем более осторожно — со значительной её частью. Этому надо только радоваться. У философов всегда будет достаточно своих забот: наука избавляет их от одних, но доставляет другие".


    Системы, подсистемы, состояния

    Чтобы у читателя сложилась более-менее целостная картина восприятия, стоит начать с азов. Даже если он их знает. Никогда не будет лишним сопоставить своё представление с представлением автора.

    Турчин пишет: "Сам термин «кибернетика« ввел, как известно, Норберт Винер, определив его описательно как учение о связях и управлении в живом организме и машине. Чтобы более точно дать определение кибернетики, как и всякой научной дисциплины, мы должны ввести её основные понятия. Собственно говоря, ввести основные понятия — это и значит уже определить данную науку, ибо остаётся только добавить: описание мира с помощью этой вот системы понятий и есть данная конкретная наука. В основе кибернетики лежит прежде всего понятие системы как некоторого материального объекта, состоящего из других объектов, называемых подсистемами данной системы. Подсистема некоторой системы, в свою очередь, может рассматриваться как система, состоящая из подсистем. Поэтому, если быть точным, смысл введённого нами понятия заключается не в термине «система» самом по себе, т.е. не в приписывании некоторому объекту свойства «быть системой», что довольно бессодержательно, ибо каждый объект может считаться системой, а в связи между терминами «система» и «подсистема», отражающей определённое отношение объектов. Второе важнейшее понятие кибернетики — понятие состояния системы (подсистемы). Подобно тому как понятие системы непосредственно опирается на нашу пространственную интуицию, понятие состояния непосредственно опирается на нашу интуицию времени, и его невозможно определить иначе, как сославшись на опыт. Когда мы видим, что объект в чём-то изменился, мы говорим, что он перешёл в другое состояние. Как и понятие системы, понятие состояния является скрытым отношением — отношением между двумя моментами времени. Если бы мир был неподвижным, понятие состояния не могло бы возникнуть, и в тех дисциплинах, где мир рассматривается статически, например, в геометрии, понятие состояния отсутствует. Кибернетика изучает организацию систем в пространстве и времени, т.е. то, каким образом связаны подсистемы в систему и как влияет изменение состояния одних подсистем на состояние других подсистем. Основной упор делается, конечно, на организацию во времени, которая в случае, когда она целенаправленна, называется управлением. Причины связи между состояниями системы и вытекающие отсюда особенности её поведения во времени часто называют заимствованным из физики термином динамика системы. Этот термин в применении к кибернетике неудачен, так как, говоря о динамике системы, мы склонны рассматривать её как нечто целое, в то время как в кибернетике главным является исследование воздействия друг на друга подсистем, образующих данную систему. Поэтому мы предпочитаем говорить об организации во времени, употребляя термин "динамическое описание" только тогда, когда его нужно противопоставить статическому описанию, учитывающему лишь пространственные отношения между подсистемами. Кибернетическое описание может иметь различный уровень детализации. Одну и ту же систему можно описывать либо в общих чертах, разбив её на несколько крупных подсистем, «блоков», либо более детально, описав строение и внутренние связи каждого блока. Но так или иначе кибернетическое описание всегда имеет какой-то конечный уровень, глубже которого оно не распространяется. Подсистемы этого уровня рассматриваются как элементарные, не разложимые на составные части. Реальная физическая природа элементарных подсистем кибернетика не интересует, ему важно только, как они связаны между собой. Два физических объекта могут радикально отличаться друг от друга по своей природе, но если на каком-то уровне кибернетического описания они организованы из подсистем одинаково (с учетом динамического аспекта!), то с точки зрения кибернетики их можно считать — на данном уровне описания — тождественными. Поэтому одни и те же кибернетические соображения могут быть применимы к таким разным объектам, как радиотехническая схема, программа для вычислительной машины или нервная система животного".


    Нервная сеть

    К изложению своей идеи метасистемного перехода В.Ф.Турчин подводит через анализ биологических систем. Стоит посмотреть, как было сделано "не нами", чтобы выявить важные закономерности.

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


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


    Что такое понятие

    Пойдём дальше. От рецепторов и эффекторов — к единичным и абстрактным понятиям.

    Турчин пишет: "Множество ситуаций в кибернетике называют понятием. Чтобы лучше уяснить, как кибернетическое понимание слова «понятие» связано с его обычным пониманием, допустим, что рецепторы рассматриваемой нами нервной сети — это светочувствительные нервные окончания сетчатки глаза или же вообще какие-то светочувствительные точки на экране, подающем информацию в нервную сеть. Рецепторы возбуждаются тогда, когда соответствующий участок экрана освещён (точнее, когда его освещённость больше некоторой пороговой величины), и остаются в состоянии покоя — в противном случае. Если на месте каждого возбужденного рецептора представить себе светлую точку, а на месте каждого невозбужденного — тёмную, то получится картина, которая отличается от изображения, падающего на экран, лишь своей дискретностью (т.е. тем, что она распадается на отдельные точки) и отсутствием полутонов. Будем считать, что точек (рецепторов) на экране достаточно много, а изображения, которые могут оказаться на экране, — их мы будем называть «картинками» — предельно контрастны, т.е. состоят лишь из белого и чёрного цвета. Тогда каждая ситуация соответствует определенной картинке.



    Согласно традиционной (аристотелевской) логике, когда мы думаем или говорим о какой-то определённой картинке (например, о той, которая находится в левом верхнем углу на рис. 2.1), то мы имеем дело с единичным понятием. Кроме единичных понятий, есть ещё общие, или абстрактные, понятия. Например, мы можем думать о пятне вообще — не о каком-либо конкретном пятне (допустим, из числа изображённых в верхнем ряду на рис.2.1), а о пятне как таковом. Точно так же мы можем обладать абстрактным понятием прямой линии, контура, четырёхугольника, квадрата и т. д. Однако что значит «обладать абстрактным понятием»? Как можно проверить, обладает ли кто-то данным абстрактным понятием, например понятием «пятно»? Очевидно, только одним способом: предложить испытуемому серию картинок и попросить, чтобы он о каждой из них сказал, пятно это или нет. Если окажется, что он называет пятном только те и все те картинки, на которых «изображено пятно» (это уже с точки зрения испытующего), то, значит, понятием пятна он обладает. Иначе говоря, мы должны проверить его способность распознавать принадлежность любой предъявленной картинки к множеству картинок, которые мы описываем словом «пятно». Итак, абстрактное понятие в обычном смысле слова — во всяком случае когда речь идёт о чувственно воспринимаемых образах — совпадает с введённым нами кибернетическим понятием понятия как множества ситуаций".


    Классификаторы

    Как распознаются ситуации? Это важный момент.

    Слово В.Ф.Турчину: "Нервную сеть, решающую задачу распознавания, мы назовём распознавателем, а состояние эффектора на его выходе будем называть просто состоянием распознавателя. Отправляясь от понятия распознавателя, мы введём несколько более общее понятие классификатора. Распознаватель делит множество всех мыслимых ситуаций на два непересекающихся подмножества: A и не A. Можно представить себе деление полного множества ситуаций на произвольное число n пересекающихся подмножеств. Такие подмножества называют обычно классами. Теперь вообразим некую подсистему C, имеющую n возможных состояний и связанную нервной сетью с рецепторами таким образом, что, когда ситуация принадлежит к i-му классу (i-му понятию), подсистема C приходит в i-е состояние. Такую подсистему вместе с нервной сетью мы будем называть классификатором по множеству n понятий (классов), а, говоря о состоянии классификатора, подразумевать состояние подсистемы C (выходной подсистемы). Распознаватель — это, очевидно, классификатор с числом состояний n = 2. В системе, организованной по двоичному принципу подобно нервной системе, подсистема C с n состояниями будет, конечно, состоять из какого-то числа элементарных подсистем с двумя состояниями, которые можно рассматривать как выходные подсистемы (эффекторы) распознавателей. Состояние классификатора, следовательно, будет описываться указанием состояний ряда распознавателей. Однако эти распознаватели могут быть тесно связаны между собой как по структуре сети, так и по выполняемой функции в нервной системе, и в этом случае их следует рассматривать в совокупности как один классификатор. Если не накладывать никаких ограничений на число состояний, то понятие «классификатор» фактически теряет смысл. Действительно, всякая нервная сеть сопоставляет каждому входному состоянию одно определённое выходное состояние; следовательно, каждому выходному состоянию соответствует множество входных состояний, и эти множества не пересекаются. Таким образом, всякое кибернетическое устройство с входом и выходом можно формально рассматривать как классификатор. Придавая этому понятию более узкий смысл, мы будем считать, что число выходных состояний классификатора гораздо меньше, чем число входных состояний, так что классификатор действительно «классифицирует» входные состояния (ситуации) по относительно небольшому числу больших классов".