ЗАМЕТКИ О ПРОГРАММИРОВАНИИ

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

2009-03-10T03:43:23Z

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

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

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

В формате Adobe PDF (со страницами оригинала)
В формате HTML

Блоги:

Форумы:

Центр свободных технологий (ЦеСТ). Национальная программная платформа

Видео:

РБК-ТВ. Поддержка отрасли ИКТ. Часть 1
26.02.2009, Участники: Илья Пономарёв (Государственная Дума РФ, председатель подкомитета по технологическому развитию), Михаил Краснов (Verysell, председатель координационного совета), Тимур Рахими ("Оптима", директор по стратегическому развитию)
РБК-ТВ. Поддержка отрасли ИКТ. Часть 2

Публикации:

"Представители отрасли ИКТ направили Дмитрию Медведеву предложения о поддержке российских ИТ-технологий"
Комментарии.ру, 05.03.2009
Владислав Мещеряков "Письмо о «Русской Windows» ушло к президенту"
CNews, 05.03.2009
"НАИРИТ готовит письмо премьер-министру"
IToday, 05.03.2009
"Представители ИТ-отрасли направили президенту РФ Д.Медведеву обращение о создании национальной программной платформы"
ПРАЙМ-ТАСС, 05.03.2009
"Представители ИТ-отрасли предложили создать Национальную программную платформу в России"
Полит.ру, 05.03.2009
"Открытое письмо представителей отрасли Дмитрию Медведеву"
"Инфра-Ресурс", 06.03.2009
Елена Шашенкова "Снова о национальной ОС"
CIO, 06.03.2009
"Президенту РФ направлено обращение о развитии национальной программной платформы"
OpenNET, 06.03.2009
"Представители ИТ-отрасли отправили президенту письмо о «Российской ОС»
Security Lab, 06.03.2009
"Президента РФ просят инициировать разработку отечественного ПО"
Наука и технологии России, 06.03.2009
"Национальная программная платформа России"
IQlib, Электронная библиотека образовательных и просветительских изданий, 06.03.2009
"Открытое письмо представителей отечественной ИТ-индустрии Дмитрию Медведеву"
ГНУ/Линуксцентр, 07.03.2009
"Обращение представителей ИТ-области к Президенту РФ о создании национальной программной платформы"
Военно-исторический форум, vif2.ru, 08.03.2009
"Научный руководитель АНО «Информэкспертиза» Владимир Рубанов: «Технологический обмен — норма глобализирующегося мира, а национальные интересы и особенности выражаются в необходимости жить своим умом»."
mskIT, 10.03.2009
"Информационщики России обратились к президенту"
Сегодня.ру, 10.03.2009
А.Анненков "Microsoft в роли "Юкоса"
РИА "Новости", Аналитика и комментарии, 11.03.2009
Сергей Голубев "Дмитрий Комиссаров: "АйТи" считает рынок СПО очень перспективным"
CITKIT, 12.03.2009
Денис Викторов "Распил" казенных денег — это не ко мне". Интервью с И.Пономарёвым
iBusiness, 16.03.2009
Денис Воейков "Обращение к президенту. Консолидация или раскол?"
PC Week/RE live, 19.03.2009
"Создается Российская ассоциация свободного программного обеспечения — РАСПО"
iToday, 20.03.2009
"Российские разработчики свободного программного обеспечения решили создать ассоциацию"
Финмаркет, 22.03.2009
Андрей Свириденко "Национальная программная платформа и ВКС"
Harvard Business Review Russia, 31.03.2009
Сергей Голубев "От ГосОС к НПП"
PC Week/RE, 02.04.2009

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

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

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

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

Речь ведь не просто о национальной безопасности и технологической независимости. Речь по сути идёт о возможности заложить фундамент для того, чтобы Россия смогла заполучить сильный катализатор, локомотив своего экономического развития — мощную программную отрасль, которая в состоянии в стратегической перспективе снять колоссальную зависимость страны от экспорта своих природных ресурсов. И поднять на новый уровень в контексте построения информационного общества 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. Вне зависимости от того, делаются они в проприетарной модели или в модели СПО.

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

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

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

RB41. Диалоги. Как создать в России национальную операционную систему?

2009-02-18T00:05:16Z

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

Заметки по теме:

Предыстория вопроса:

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

— Что такое операционная система?
— Странный вопрос. Трудно найти человека, который бы не понимал, что это.

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

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

— Но это для пользователей. А как для программистов?
— Для них аналогично — требуется знать чисто внешние признаки ОС помимо пользовательского интерфейса: системные вызовы, протоколы взаимодействия, форматы данных. То, что называется операционной платформой. Зафиксируем платформу, подменив содержимое конкретной ОС — и никаких отличий для программиста фактически не будет.

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

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

— Хорошо. Но как же быть с новой ОС. Разве нет выхода?
— Есть. Делать, например, всё своё. И интерфейс, и платформу.

— Легко сказать. А сколько на это нужно времени, финансов, людей?
— Всё зависит от постановки задачи, состава требований и реальных возможностей её решения. Создать экспериментальную ОС, позволяющую выполнять базовые штатные функции и создавать новые приложения, можно за сравнительно короткий срок и весьма скромным коллективом. Приведу несколько примеров. Экспериментальную ОС масштаба ETH A2/Bluebottle можно создать за 3-4 года силами 3-5 человек: трудозатраты 9-20 человеколет. Трудозатраты на Oberon System (базовую часть) составили 5 человеколет (1985-1987), при этом создавали два профессора (Никлаус Вирт и Юрг Гуткнехт) и развивали несколько аспирантов, совмещая со своей преподавательской и исследовательской деятельностью в ETH Zurich. Другая система — Microsoft Singularity создаётся с 2003 г. силами 50 сотрудников Microsoft Research (разные подразделения), совмещающих эту работу с другими работами. Можно вспомнить и более комплексный 3-летний советский проект МАРС (Модульные асинхронные развиваемые системы, 1985-1988; ВЦ АН СССР, ВЦ СО АН СССР, Институт кибернетики Эстонии), проводившийся ВНТК "Старт". МАРС — это НИОКР с получением макета системы и проектной документацией для передачи в производство. В проекте было задействовано около 100 человек (преимущественно научно-исследовательские организации по линии АН СССР с подключением ряда промышленных предприятий). В проекте поддерживалась централизация по управлению (с Центром управления в Новосибирске, ВЦ СО АН СССР). Кадры не изымали из существующей организационной структуры: перераспределяли нагрузку и гибко переподчиняли по проектному участию. Не было необходимости в географической централизации. В МАРС фундамент составляли: 32-разрядный процессор Кронос (прототип — 16-разрядный швейцарский Lilith), транспьютерная архитектура (прототип — транспьютеры английской компании Inmos), операционная система Excelsior (прототип — UNIX, язык реализации — Modula-2), параллелизм — языки БАРС и ПОЛЯР (примитивы языка Occam фирмы Inmos) и формализм управляющих сетей (прототип — сети Петри).

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

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

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

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

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

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

— И кто же может быть таким влиятельным хозяином? Интересно…
— Например, государство. Уж на своей-то территории оно вправе устанавливать собственные правила и законы. Значит, у него на руках все козыри.

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

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

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

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

— А если мне государственная ОС не понравится? Почему я должен на ней работать?
— Если не нравится — не работайте. Покупайте или доставайте другие, как делаете сегодня. В чём проблема? Правда, если вы работаете в государственной организации, то, боюсь, здесь придётся считаться с мнением и волей своего работодателя — государства.

— Подождите. Но сколько может понадобиться времени на пилотные проекты, на запуск в производство, на переход на новую ОС? Это же очень долго.
— На пилотные проекты примерно 3-5 лет. На производство — примерно столько же. В общем, лет на 7-10 закладываться надо. Это нормальный цикл для создания массовых ОС.

— А что делать остальным эти 10 лет. Ждать?
— Почему же? Можно уже сегодня начинать готовиться к переходу на новые ОС и при этом оставаться на платформе существующих.

— Не понял. Поясните…
— Через 3-5 лет после начала работ определится архитектура и вся новая операционная платформа. Наверняка появится под неё базовый инструментарий. Значит, программисты уже потенциально могут иметь к этому доступ.

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

— Но ведь есть не только международные стандарты. Большая часть программного обеспечения базируется на внутрикорпоративных стандартах. А компания может по своему усмотрению их менять. В любое время. Как же можно к ним привязываться? Вон ICQ чуть ли не каждую неделю меняет свой протокол из-за борьбы с конкурентами. Как же быть?
— В этом случае надо использовать возможности государства. Оно вправе предъявлять требования к продукции, продаваемой и распространяемой на его территории. По маркировке, по документации, по поставке драйверов, по иным параметрам… Возможности зафиксировать на длительный период на своей территории те или иные спецификации — вполне посильная задача. К тому же она развяжет руки разработчикам и прикладных систем. Они смогут опираться на "узаконенные" спецификации. Для развития отечественной программной отрасли даже безотносительно новой ОС это огромное подспорье.

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

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

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

— А как же Windows? На него фактически завязана вся экономика страны. Люди не будут поддерживать Linux. Хотя бы потому, что это им не выгодно. Они привыкли к Windows. Деньги за него платятся по большей части не из их кармана. К тому же, раз вложения сделаны, просто так выбрасывать всё на ветер — не по-хозяйски.
— А зачем выбрасывать? Давайте попробуем посмотреть на проблему иначе: наверное для ряда задач имеет смысл обеспечивать дуальность: поддержку и Windows, и Linux. Так? Тогда надо искать пути унификации. В первую очередь — по линии приложений. Формировать демпфирующие программные слои, которые можно будет относительно легко перекоммутировать на целевую ОС. Причём со временем и на новые перспективные ОС. Стимулировать этот процесс может опять-таки государство — соответствующими требованиями к новым системам для государственного сектора.

— А можно какой-нибудь пример подобной унификации?
— Возьмите проект San Francisco корпорации IBM. Создавались крупные строительные блоки для бизнес-приложений в Java 2 Enterprise Edition (свыше 1000 модулей), которые потом вылились в весьма развитую интегрирующую платформу IBM WebSphere. Теперь она ещё и тесно связана с открытой расширяемой инструментальной платформой Eclipse. Другой пример — интегрирующая бизнес-платформа SAP NetWeaver. Малоизвестен тот факт, что в её разработке ведущую роль сыграла формально американская, а по сути белорусско-российская компания EPAM Systems, лидер среди компаний всей Восточной Европы. Наши разработчики с 2002 г. бок о бок работали над SAP NetWeaver с коллегами из команд SAP в Вальдорфе (Германия), Пало-Альто (США) и Бангалоре (Индия). И накопили свыше 1 млн. часов опыта работы с этой платформой, включая разработку и внедрение на её основе корпоративных бизнес-решений.

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

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

— Может ли национальная ОС дать нам конкурентное преимущество при экспорте нашего ПО?
— Непростой вопрос. Сама по себе — вряд ли. Если она в тактическом отношении опирается на существующие ОС, то для западной аудитории не совсем понятно, в чём для них выигрыш. Им нужно минимизировать свои риски. А для них чужая национальная ОС без очевидного выигрыша в производительности — лишние риски. Делать же ПО для Windows и Linux в отдельности — и так делаем. Скажу больше — нашим признанным лидерам экспортной разработки ПО национальная ОС для продвижения на Запад особо и не нужна. Разве что как один из крупных правительственных заказов. В остальных случаях нетрудно предсказать их прохладное к этому отношение, возможно даже стойкое неприятие самой идеи.

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

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

— А как назвать все те стандарты и спецификации, которые помогут снять зависимость и от зарубежных ОС, и вообще от специфики ОС?
— Это не только совокупность операционных платформ. Здесь задействованы и прикладные платформы для отраслевых применений. Да и не только они. Можно назвать и Национальной операционной инфраструктурой, и Национальной программной платформой — кому как нравится. Впрочем, не в названии дело.

— Интересно. И всё-таки: если в кармане у нас есть почти беспроигрышное решение по унификации Windows и Linux, то каковы шансы создавать параллельно своё, оригинальное?
— Я бы говорил не об унификации Windows и Linux, а, скорее, об унификации Windows и UNIX. Причём на "законодательной базе" Национальной программной платформы. В мире UNIX помимо Linux есть не менее интересные, зрелые и продуманные системы (QNX, FreeBSD, Solaris и др.), и не только коммерческие. Но вопрос был про отечественные оригинальные разработки в области ОС... Есть перспективные наработки в Новосибирске (Excelsior), Орле ("Орлея", ранее "Роса"), Москве (Phantom). Это лишь несколько примеров.

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

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

Заметки по теме:

RB40. Никлаус Вирт. Большое турне по России

2009-02-16T09:55:15Z

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

15 февраля 2009 г. знаменитому швейцарскому профессору Никлаусу Вирту исполнилось 75 лет. Его юбилею посвящена эта заметка с воспоминаниями о визите Вирта в Россию в 2005 г.

Никлаус Вирт (Niklaus Wirth), автор языков Паскаль (1970), Modula-2 (1979) и Оберон (1988), знаменитый профессор Высшей Политехнической школы ETH из Цюриха, где учились Альберт Эйнштейн и Джон фон Нейман, в рамках Большого турне по России (11 сентября — 7 октября 2005 г.) собрал бурю оваций. Профессор Вирт выступил с лекциями в крупнейших университетских центрах страны: Москве, С.-Петербурге, Нижнем Новгороде, Екатеринбурге, Новосибирске, Томске.

Главной целью столь продолжительного визита проф. Вирта в Россию, прошедшего в год 35-летия Паскаля и приуроченного к празднованию 250-летия МГУ им. М.В.Ломоносова и 150-летия швейцарского ETH, — представление широкой общественности проблем развития информатики и ИТ-индустрии, популяризация идей систематизации программирования, а также налаживание более тесных контактов ETH с ведущими университетскими центрами России. В известной группе БРИК наиболее перспективных стран для мировой ИТ-индустрии (Бразилия, Россия, Индия и Китай) Никлаус Вирт выделяет Россию. Именно Россия, хранящая традиции и самобытность Паскаль-культуры, имеющая глубокие корни блестящих достижений научных школ — математики, физики и инженерного дела — ныне остаётся едва ли не единственным оазисом неремесленного программирования.

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

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

В знак уважения к высочайшему инженерному искусству России Никлаус Вирт преподнёс в дар Политехническому музею свой уникальный компьютер Lilith ("Лилит"), первый европейский персональный компьютер, созданный в ETH в 1980 г. и почти на 10 лет опередивший разработки ведущих компьютерных компаний мира. Во всём мире сохранились лишь единичные экземпляры. Тем более весом тот факт, что проф. Вирт подарил старейшему российскому инженерному музею свой личный компьютер. Такой чести не удостаивалась ни одна другая страна мира. За разработку Lilith и за создание языка Паскаль, на котором воспитано не одно поколение программистов, Никлаус Вирт в 1984 г. был представлен к высшей профессиональной награде — премии Алана Тьюринга (Turing Award). В компьютерном мире она считается эквивалентом Нобелевской премии. Одновременно с Lilith Институт систем информатики им.А.П.Ершова Сибирского отделения Российской академии наук преподнёс в дар Политехническому музею 32-разрядную рабочую станцию "Кронос", ориентированную на язык Modula-2, созданную в Советском Союзе учениками и последователями академика А.П.Ершова и являющуюся дальнейшим развитием 16-разрядного компьютера Lilith.

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

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

Большое турне Вирта, в подготовке которого важнейшую роль сыграл его ближайший сподвижник профессор Юрг Гуткнехт (Juerg Gutknecht), проходил по городам C.-Петербург — Ярославль — Москва — Суздаль — Нижний Новгород — Екатеринбург — Новосибирск — Томск — Москва, где Ярославль и Суздаль были промежуточной остановкой в рамках знакомства Вирта с культурой великой России. В каждом городе проходило по 2-3 рабочих встречи с лучшими программистами страны и ведущими представителями профессорско-преподавательского корпуса, где обсуждались проблемы обучения компьютерным наукам и технологиям наших школьников и студентов, будущих учёных и инженеров, перспективы сотрудничества между Швейцарией и Россией в рамках международного научно-образовательного проекта "Информатика-21".

Немного сухой статистики. На лекциях Вирта, посвящённых языку Оберон и анализу инноваций в компьютерных науках за последние 40 лет, побывало в общей сложности около 5 тыс. человек. Число тех, кто не смог попасть на выступления мировой знаменитости, но был в курсе деталей этого визита через друзей, знакомых, Интернет приблизительно в 5 раз выше аудитории слушателей его лекций. После выхода статей в ведущих изданиях страны аудитория Большого турне Вирта увеличилась ещё примерно в 100 раз и составила около 2,5 млн. человек. За время своего турне Никлаус Вирт на поездах и автомашинах преодолел 4594 км, не считая поездок в пригороды С.-Петербурга и Москвы, а также тысячекилометровые авиаперелёты. Для освещения Большого турне Вирта был открыт специальный событийный сайт Oberon2005.ru, на котором за время турне было зарегистрировано около 100 тыс. запросов.

А теперь некоторые субъективные наблюдения. Эдакий портрет мэтра без галстука.

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

С Никлаусом Виртом заочно я знаком достаточно давно. Изредка удавалось переписываться. Помимо его первой знаменитой лекции в МГУ в 1990 г. дважды были мимолётные встречи — в 1996 г. в Новосибирске, при вручении ему звания Почетного доктора Новосибирского университета (то заслуга столь рано от нас ушедшего Игоря Васильевича Поттосина), и несколькими днями позже в Москве, на квартире у Д.М.Сагателяна, бывшего в ту пору организатором и вдохновителем Рабочей группы по языку Modula-2 в СССР и России. (Сейчас Дмитрий Михайлович живёт и работает в США. Вирт очень хотел пригласить его на лекцию в Политехнический, но увы...).

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

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

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

Ещё один штрих. Сильное впечатление на Вирта произвёл колокольный перезвон в суздальском Кремле. Был единственный за всю первую половину турне ясный тёплый день (24 сентября). Будто судьба решила сделать такой невероятно щедрый подарок: всё великолепие храмов древнего города по-царски оттеняла тронутая красной позолотой осенняя листва. Если говорить о трапезе, которая тоже даёт интересную характеристику человеку, то в отношении напитков Вирт крайне непривередлив: предпочитает чай, минеральную воду, на крайний случай — кофе-эспрессо. Из алкоголя жалует красное сухое вино; очень ему нравится грузинское красное полусладкое (Хванчкара, Киндзмараули). Любит борщ. Вообще, неравнодушен к хорошим супам. С огромным аппетитом ест шашлык и является тонким ценителем настоящих сибирских пельменей.

Несмотря на свой почтенный возраст Вирт оказался очень выносливым человеком (в плане выпавшей на него гигантской нагрузки, а ведь мы с Ф.В.Ткачёвым из Института ядерных исследований РАН постоянно сменялись — и то падали с ног от усталости). Лишь в один из дней (19 сентября) он выглядел крайне утомлённым. То был день открытия в МГУ 1-й Международной конференции по ИТ-образованию. Помимо своего доклада Вирт потом несколько часов допоздна провёл на круглом столе в МГУ, где не одна сотня студентов из тех, что сидели в аудитории факультета ВМиК и стояли в проходах, добивала его многочисленными вопросами. Его друг, Алексей Недоря, в гости к которому в Ярославль Вирт совершил немыслимый тысячекилометровый вояж по дороге из С.-Петербурга в Москву и где отведал баньки и русских блинов, помог увезти знаменитого профессора в гостиницу, а то его просто бы растерзали на "тысячу маленьких медвежат".

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

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

Больше всего Вирт хотел попасть в музей ВВС России в подмосковном Монино. Те, кто знает его юношеское увлечение авиамоделизмом, проект OLGA и преклонение перед совершенством аэрокосмических разработок, легко поймут, почему в донельзя загруженной программе были выделены почти два полных дня (22 и 23 сентября) для посещения второго по величине в мире авиационного музея под открытым небом и для запуска беспилотных самолетов в Егорьевске. В Монино Вирт не просто слушал интереснейшие рассказы импровизированного гида — действующего лётчика, руководителя местного аэроклуба, — он уточнял, почему не шли в серию те или иные перспективные разработки, опережавшие время, несколько раз переспрашивал о конкретных примерах конкуренции в этой области между Советским Союзом и США. Было видно, что тема противостояния имперским амбициям Америки его весьма и весьма волновала. На обратном пути, уже после мимолётного визита в редакцию журнала "Мир ПК", Вирт обратился ко мне с вопросом: почему многие в России смотрят на Америку снизу вверх? Что я мог ему ответить? Печально, но мы пожинаем горькие плоды безвременья последних двух десятилетий.

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

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

Материалы к Большому турне проф. Вирта (2005)

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

2009-02-14T07:13:59Z

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

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

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

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

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

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

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

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

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

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

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

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

Национальная программная индустрия (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. Отечественная или государственная ОС?

2009-01-28T06:06:29Z

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

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

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

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

В настоящее время на мировом рынке персональных компьютеров наиболее ярко выделяются три семейства операционных систем:
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 как тактическое решение в создании государственной ОС может перерасти и в стратегическое, если обеспечит основу для развития под своим зонтиком других, перспективных форм, более совершенных в технологическом плане. Форм, которые могут со временем прийти на смену нынешним, обеспечив безболезненную миграцию.

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

RB37. Роса и НИП

2008-08-29T06:23:44Z

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

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

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

С сентября мы возвращаемся к публичной деятельности и переходим к новым, более безопасным формам развития проекта. Проектирование новой ОС будет осуществлять конструкторская группа компании "Метасистемы", руководство которой (Борис Рюмшин, Илья Ермаков) с самых первых дней находится в ядре группы и вносит наиболее существенный вклад в его развитие. Руководство проектом возглавит Борис Рюмшин. Информационное сопровождение будут осуществлять сайты OberonCore.ru и EuroProg.ru. Те функции, которые первоначально планировалось возложить на сайт НИПа, во многом отойдут Европейскому центру программирования (EuroProg.ru), на реорганизацию которого я и переключаюсь.

Контакты по проекту новой ОС необходимо вести через этот адрес: girs-orel@oberoncore.ru.

RB36. Singularity и Microsoft TechFest 2008

2008-03-06T07:10:41Z

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

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

Оглавление

4 марта на ежегодном фестивале TechFest 2008, который проводит Microsoft Research на территории кампуса Microsoft в Редмонде, были представлены перспективные разработки исследовательского подразделения корпорации. Среди них можно выделить реконфигурируемую аппаратную платформу BEE3 (Berkeley Emulation Engine) и макет экспериментальной операционной системы Singularity.

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

Лидер проекта BEE Чарльз Теккер (Charles Thacker) был главным конструктором Xerox Alto и одним из основателей DEC Systems Research Center — ведущего исследовательского центра корпорации Digital, куда в начале 1980-х ушли многие исследователи из Xerox PARC. В DEC SRC он возглавлял разработку многопроцессорной рабочей станции Firefly (эскпериментальные языки Modula-2+ и Modula-3) и прототипа процессора DEC Alpha.

Главный конструктор ОС Singularity Гален Хант (Galen C. Hunt) принадлежит другому поколению и имеет совсем иную школу. Начинал с языка Си и принимал участие на ранней стадии разработки ядра Linux (драйвер консоли для Linux 0.11). Участвовал в реализации компилятора Objective-C из набора GCC (GNU Compiler Collection). Во время обучения в университете Рочестера (США) как талантливый студент привлекался к работе в Microsoft Research. Затем работал в производственных подразделениях Microsoft. В 2003 г. вслед за выпуском ETH Zurich первого публичного релиза Bluebottle (преемницы ОС Oberon) возглавил работу коллектива примерно из 50 сотрудников Microsoft Research над экспериментальной ОС Singularity, где предпринята попытка совместить идеи Xerox Cedar (проекта-вдохновителя ОС Oberon) и Microsoft .NET.

Помимо представления своих перспективных разработок Microsoft сделала доступными исходные тексты первого публичного релиза экспериментальной ОС Singularity (Singularity Research Development Kit 1.1, RDK) для некоммерческого использования: http://www.codeplex.com/singularity (60 Мбайт).

В чем цель ведения концепт-проекта Singularity и подобной публичности? С технологической точки зрения — показать, как можно писать компактную конкурентноспособную ОС с нуля, используя возможности обеспечения надёжности за счёт языка реализации высокого уровня (Sing#) и языкового инструментария (Bartok). Но, по всей видимости, основная (политическая) цель — "застолбить" весьма перспективное направление, на которое уже покусились различные европейские группы. Это превентивный удар. И пусть теперь общественность гадает — пойдут ли данные проработки в дело или же станут очередным отвлекающим маневром Microsoft.

Дополнительная информация:

RB09. Оберон и предыстория Bluebottle

RB10. От Oberon к Bluebottle

RB26. Дуальность и другие контуры “Росы"

RB27. Пути восхождения к новой ОС

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

Видеоматериалы по ОС Singularity (Microsoft Channel 9):

A Research OS Written In C#

Singularity Revisited

Singularity III: Revenge of the SIP

Singularity IV: Return of the UI

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

2008-02-24T19:12:26Z

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

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

Запасник

2007-12-17T01:15:27Z

01. Милая моя (Ю.Визбор)
02. Серёжка ольховая (Е.Крылатов -- Е.Евтушенко)
03. Я спросил у ясеня (М.Таривердиев -- В.Киршон)
04. По улице моей (М.Таривердиев -- Б.Ахмадулина)
05. Грузинская песня (Б.Окуджава)
06. Пожелание друзьям (Б.Окуджава)
07. Песенка кавалергарда (И.Шварц -- Б.Окуджава)
08. Моя звезда (А.Суханов -- И.Анненский)
09. Апрель (А.Суханов)
10. Дежурный по апрелю (Б.Окуджава)
11. Наденька (Б.Окуджава)
12. Как здорово (О.Митяев)
13. С добрым утром, любимая (К.Тарасов -- О.Митяев)
14. Царица Непала (О.Митяев)
15. Голуби (С.Трофимов)
16. Воскресение (О.Митяев, посвящ. Ю.Визбору)
17. Как незаметно (А.Суханов)
18. Если я заболею (Ю.Визбор -- Я.Смеляков)
19. Навашино (С.Трофимов)
20. Маменька (А.Морозов -- А.Поперечный)

============

01. Ты говоришь мне о любви (Э.Колмановский -- Л.Дербенёв)
02. Каждый день с тобой (И.Крутой -- С.Осиашвили)
03. Твой мир (В.Боровиков -- Н.Наринская)
04. Уходило лето (Л.Жаке -- русский текст В.Лугового)
05. Та, которая уходит в дождь (А.Державин -- С.Костров)
06. Я больше не прошу (А.Литягин -- Е.Степанова)
07. Золотая лестница (Ю.Антонов -- М.Виккерс)
08. Не говорите мне прощай (Ю.Антонов -- М.Рябинин)
09. Хмельная сирень (Ю.Антонов -- А.Косарев)
10. Почему -- не ведаю (В.Мигуля -- А.Поперечный)
11. Ты рядом со мной (Б.Мокроусов -- Н.Глейзаров)
12. Незабудка (В.Добрынин -- М.Рябинин)

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

2007-12-03T08:38:50Z

Заметки по началу проекта:

RB22. О проекте создания отечественной перспективной ОС

RB23. О языках реализации в проекте новой ОС

RB25. Новая европейская ОС

RB26. Дуальность и другие контуры "Росы"

RB27. Пути восхождения к новой ОС

RB28. Закон Гордона Мура и закон Дэвида Мэя

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

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

Оглавление

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

Текст доклада см. http://www.europrog.ru/rosa.pdf
Слайды доклада см. http://www.europrog.ru/rosa.ppt

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

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

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

<...>

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

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

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

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

<...>

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

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

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

<...>

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

<...>

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

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

<...>

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

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

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

RB33. Лебединая песнь Digital

2007-11-27T04:25:16Z

Лебединая песнь Digital.
Опыт ведения проекта DEC Alpha AXP

15 лет назад в специализированном журнале Digital Technical Journal корпорации DEC вышла статья Питера Конклина, главного конструктора Alpha AXP – одного из крупнейших проектов в ИТ-индустрии. Эта статья попала мне в руки в конце 1994 г. (благодаря сотрудничеству МАИ и DEC по созданию центра компетенции). В 1995 г. решил её издать в альманахе "Технология программирования" (первом отечественном периодическом 200-страничном издании с CD-диском, посвящённом программированию). При подготовке к старту проекта новой ОС в середине 2006 г. я обратил внимание на эту статью и нашёл там немало полезного в плане организации работ в будущем проекте новой отечественной ОС. Наряду с проектом МАРС и IBM AS/400 (рассказы о которых ещё впереди) он был взят на вооружение. Настало время познакомить с этими материалами и широкие круги общественности.

Биографическая справка. Питер Конклин (Peter Conklin). В 1963 г. закончил Гарвардский университет (Harvard University) с дипломом математика. В корпорации Digital (DEC) с 1969 г. Был первым инженером по программному обеспечению в рамках проекта VMS. Входил в состав группы VAX A вместе с Уильямом Стрекером (William Strecker, архитектор VAX), Гордоном Беллом (Gordon Bell, архитектор PDP-11) и Дэйвом Катлером (Dave Cutler, будущий архитектор Windows NT и Windows 2000). Руководил группой, занимавшейся разработкой архитектуры VAX, принимал активное участие в проработке ключевых аспектов архитектуры и набора программных средств для VAX/VMS. В ранге директора возглавлял Центр разработки систем Alpha AXP (Alpha AXP Systems Development).

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

Peter Conklin "Enrollment Management, Managing the Alpha AXP Program" // Digital Technical Journal, 1992, Vol.4, No.4.
Питер Конклин "Стратегия вовлечения: руководство программой Alpha AXP" // Технология программирования, 01/1995. (Перевод Александра Китаева)

Питер Конклин пишет:
==>
Программа по разработке систем Alpha AXP была наиболее масштабной в истории корпорации Digital и одной из крупнейших в компьютерной индустрии в целом. В ходе работы над проектом Центр управления программы Alpha (Alpha AXP Program Office) разработал модель, обеспечивающую необходимый инструментарий для управления программой. Может показаться, что руководители программы начали с разработки инструментов, а уж затем в чистом виде применили их на практике. На самом же деле в основе этих подходов лежит многолетний опыт и созданные экспертами методики управления; мы тоже изучали и применяли эти уроки по мере работы над программой. Разумеется, такие показатели, как своевременное выполнение заданий и высокое качество особенно важны при выполнении масштабных программ. Тем не менее, Digital успешно применяла наши методы управления и в сравнительно небольших проектах... Опыт автора говорит о том, что нашу модель управления можно применять в проектах практически любого масштаба. <…>

Программа Alpha AXP корпорации Digital охватывала проектирование микропроцессорного набора мирового уровня, новой архитектуры, основанной на 64-разрядной системе, множества систем аппаратного обеспечения (от персональных компьютеров до мэйнфреймов), большого числа операционных систем и сотен видов программных продуктов, работающих под управлением этих систем. Разработка продуктов первого поколения длилась несколько лет, и в пик работ в проекте участвовало свыше 2 тыс. инженеров – специалистов в области аппаратного и программного обеспечения, а также системной инженерии. Корпорация Digital осуществляла общее руководство программой через Центр управления (Program Office), где было занято 8 специалистов.

В работах по программе Alpha AXP на предприятиях Digital, разбросанных по всему миру, участвовало свыше 22 групп инженеров по программному обеспечению и 10 групп инженеров по аппаратным средствам. Последние включали группу по разработке полупроводниковых систем и по одной группе на каждую из платформ систем аппаратного обеспечения. В разработках программного обеспечения участвовали 4 группы по операционным системам, а также группы по разработке средств миграции, сетевых систем, компиляторов, баз данных, сред интеграции и приложений. Число инженеров-разработчиков в некоторых группах доходило до 150 – и это не считая персонала поддержки. Многие из них также заключали контракты с поставщиками как внутри Digital, так и вне ее.

Организация столь масштабной и сложной программы связана не только с техническими, но и с управленческими проблемами. Поэтому Центр управления рассмотрел и отверг ряд традиционных организационных подходов. В соответствии с классической организационной моделью создается иерархическая или линейная организация, содержащая всех главных исполнителей. Когда речь идет о большой программе, этот подход имеет тот недостаток, что для создания организации требуется слишком много времени. Формирование рабочих групп и установление операционных процедур занимает больше времени, чем позволяет рыночное окно и имеющаяся технология. Итог – грандиозные планы, и ... выполнение проекта на несколько лет позже, чем запланировано. К тому же по окончании работ по программе "временные" организации надо опять реорганизовывать и приводить "в исходное состояние" <...> Один из альтернативных подходов состоит в том, что создаются небольшие, работающие на свой страх и риск группы специалистов, перед которыми ставится задача любой ценой добиться поставленных целей. Так можно работать в рамках небольших проектов, т.н. skunk works. Кстати говоря, именно по этой схеме проводилась первоначальная работа по проектированию программы Alpha. Но когда такой подход применяется в крупных программах, специалисты часто "перегорают", не укладываясь в поставленные перед ними сжатые сроки. А это вызывает бурную реакцию руководства, которое набирает новых людей и продолжает ту же линию – и с теми же результатами.

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

Модель управления через вовлечение. Эта модель в программе Alpha состоит из четырех стадий:
1) уяснение (vision) - вовлечение (enrollment)
2) обязательства (commitment) – делегирование (delegation)
3) контроль (inspection) – поддержка (support)
4) признание (acknowledgement) – изучение (learning).

Модель в такой форме была разработана автором статьи (главным конструктором Alpha AXP Питером Конклином – прим. Р.Б.). Некоторые элементы ее были предложены на семинарах по управлению или позаимствованы из рекомендаций консультантов. Конкретные формы, применяемые на стадиях уяснения, обязательств и признания возникли в ходе работы по программе Alpha. Стадия "контроль – поддержка" разрабатывалась автором в течение многих лет руководства проектами и ведения надзора. Две концепции являются ключевыми для реализации этой модели в крупных программах. Во-первых, уже упоминавшийся Центр управления. Он обеспечивает необходимую связь, единое понимание концепции программы и структуру контроля, позволяя в то же время специалистам и ресурсам оставаться в их "родных" организациях. Более того, Центр обеспечивает согласованность действий на всем пространстве программы и соблюдение каждой участвующей в работе группой взятых на себя обязательств. Важно подчеркнуть, что небольшой Центр управления программой Alpha, состоящий из менеджеров по различным группам продуктов и по операциям, не имел никакой формальной власти (даже в области распределения средств), поэтому его влияние осуществлялось лишь с помощью методичного вовлечения и делегирования, обозначенных в модели управления. Вторая ключевая концепция – это концепция "переломов" (cusp) в ходе проекта, что означает критическое событие, стимулирующее перемены. <...>

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

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

Контроль – поддержка. Менеджер проекта полагается на принятые обязательства и постоянно контролирует состояние дел в проекте для обеспечения соблюдения графика<...> Как только возникает опасность невыполнения взятых обязательств, менеджер проекта объявляет о том, что в работе по проекту наступил "перелом". Термин "перелом" (cusp), позаимствованный у Гляйка (J.Gleick "CHAOS: Making a New Science", 1987), означает потенциальные поворотные пункты или имеющие решающее значение события в ходе работы над проектом. (Для их обозначения часто используются другие слова: gotchas, неудачи, кризисы, поворотные пункты, срывы проекта и "призывы к действию". При работе над программой наши менеджеры использовали и эти термины. Но для наших целей мы принимаем термин "перелом" как эмоционально нейтральный. Суть в том, чтобы на любой стадии проекта применялся такой термин, который как бы открывает возможности действовать иначе, продвигать проект вперед.) В момент перелома все готовы принять перемены, поскольку это приближает достижение общих целей программы. <...>

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

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

Как указывалось выше, переломы – это решающие события в ходе развития проекта, или кризисы. Цель традиционного управления проектом состоит в том, чтобы избежать таких кризисов с помощью жесткого планирования. Центр управления программой принял противоположный подход: мы стремились вникнуть в суть критических событий и использовать эти переломы для наращивания темпов работы над проектом<...> Каждый раз, когда проект приближался к очередному перелому, Центр управления быстро принимал меры к тому, чтобы проект продолжал двигаться в нужном направлении. Иными словами, план был нужен руководителям не для "галочки". Его главные пункты и другие события использовались как средство управления скоростью проекта, который следовало неустанно направлять в сторону намеченной цели. Часто мы сами создавали ситуацию перелома для ускорения необходимых перемен (например, провоцируя кризис в соблюдении графика). <...> Когда руководители научились конструктивно использовать переломы проекта, Центр управления приступил к активному провоцированию новых переломов. В итоге создавался "эффект бумеранга", скорость выполнения работ и темп выполнения программы повышались. <...> По мере того как руководство признавало все новые и новые достижения, темп реализации программы возрастал от очень низкого до среднего и, наконец, она, образно говоря, переключалась на высокую передачу. <...>

Программа Alpha AXP выросла из компьютерных исследований, точнее – из исследований по технологиям и преимуществам различных RISC-архитектур, а также из передовых разработок в области создания компиляторов, проектирования СБИС и производства полупроводниковых систем. В 1988 г. руководство корпорации Digital поставило перед инженерным департаментом задачу разработать систему, которая бы удовлетворяла потребность клиентов в плане первоклассных эксплуатационных характеристик во всех вычислительных средах корпорации Digital. Инженерный департамент из представителей разных подразделений сформировал рабочую группу, которая разработала необходимую системную архитектуру и проектную документацию. <...> Руководство Digital одобрило программу Alpha AXP в октябре 1988 г. К концу 1989 г. Digital завершила упомянутые разработки, а также работу с документацией по архитектуре и предварительному проектированию. В ходе широкой проверки в январе 1990 г. высшее руководство потребовало, чтобы работы по программе были ускорены и завершены в пределах "рыночного окна" для новой технологии. <...>

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

После того как ключевые менеджеры проектов усвоили общую концепцию программы, нам предстояло сделать следующий шаг – создать рабочий план и обеспечить обязательство каждой группы выполнить свою задачу в установленные сроки. <...> Необходимость одновременной разработки многочисленных аппаратных и программных систем осложняла задачу координации. Центр управления решал эту проблему комплексной координации по двум направлениям: в плане технического менеджмента и менеджмента проекта. По техническому направлению Центр сформировал команду технических руководителей из основных инженерных групп, известную как EJST (EVAX Joint Systems Team; EVAX – первоначальное название программы Alpha AXP – прим. Р.Б.). <...> Эта группа на еженедельных заседаниях вырабатывала директивы по вопросам технического проектирования и стратегическим вопросам, касающимся сразу нескольких групп. Поскольку в компетенцию этой группы входило решение проблем и обеспечение выполнения решений, EJST превратилась в орган, куда работники представляли технические проблемы для их разрешения.

В области управления проектами менеджер программы сформировал команду менеджеров проектов. Каждый член этой команды был уполномочен соответствующей группой инженерной разработки брать обязательства и отвечать за их выполнение. Эта команда была известна как ASPM (Alpha AXP System Project Managers). Масштабность генеральной задачи и сложность понимания всех деталей взаимозависимостей в ходе работы привели к тому, что менеджерам проекта сам проект, как правило, представлялся невероятно сложным. Поэтому на уровне программы проблема состояла в том, чтобы создать генеральный общий план Alpha AXP. Но этот план создавался значительно медленнее, чем мы ожидали. Неспособность администраторов создать генеральный план привела к возникновению кризиса доверия. Менеджеры проектов грозили мятежом (или уходом в другие проекты). Технические руководители разрабатывали все более масштабную проектную документацию. Менеджеры групп инженерной разработки заявили, что Центр управления программой стоит на пороге кризиса. Нам нужно было создать рабочий план для всей программы, из которого следовало бы, в каком порядке каждый подпроект должен представить результаты своего труда (выполнить свою задачу).

Как координировать работу, не имея плана? Менеджер программы Alpha AXP постоянно требовал от отдельных групп предоставления их планов. От чего зависит ваша работа? Какое время она займет? Какие средства вам потребуются? Каковы основные этапы или параметры вашей работы? Постоянным ответом было: "Не знаю – мне же неизвестно, что делают остальные и когда они закончат свою часть". К этому времени мы уже создали состоящую из опытных менеджеров проектов многофункциональную команду ASPM, в которой было представлено большинство групп разработчиков. И эта команда не имела возможности составить планы работы подразделений, поскольку у нее не было генерального плана.

Выбор стратегии. Для разработки общих параметров плана программы Alpha AXP менеджеры инженерных групп разработки собрались на заседание, которое длилось целый день. Сначала они установили коммерческие цели и исследовали различные технические ограничения. Критерием для включения в план того или иного компонента был ответ на вопрос: "Имеет ли она решающее значение для достижения коммерческого успеха программы Alpha AXP"? Такая постановка обеспечила серьезный подход к содержанию генерального плана, причем решение о включении или невключении того или иного компонента оставалось за ответственной группой разработки. Затем эта группа определяла организационные аспекты такого рабочего плана. Члены группы рассматривали коммерческие, технологические и организационные аспекты для определения приоритетов и порядка работы. Мы дали этой группе статус Совета директоров по разработке систем Alpha AXP (ASBOD – Alpha AXP System Board of Directors; в результате общая структура управления проектом Alpha AXP включала в себя Центр управления проектом, группу технических директоров EJST, группу менеджеров проектов ASPM и все инженерные группы, находящиеся под контролем ASBOD – прим. Р.Б.).

Представление плана. Когда были установлены важнейшие приоритеты и ограничения программы, менеджер программы Alpha AXP приступил к составлению генерального плана. Чтобы дать возможность каждой группе видеть свое место в общей работе, он решил ограничить генеральный план одной страницей текста. Он определил содержание плана в рамках интенсивного периода, в ходе которого просил участников описать свои посылки и задачи и показать, как вписывается в общий план вклад каждой из участвующих групп. Одностраничный формат плана заставил команду управленцев (группу управления) отбирать в него лишь самое важное и позволил участникам увидеть свои участки работы, не перегруженные конкретными сложностями работы данной группы. Далее, на обзорных совещаниях всем участникам было легко видеть картину в одном и том же свете, в котором результаты можно видеть, обсуждать и приходить к общему согласию относительно стоящих проблем. Когда группа управления составила план, он был рекомендован менеджерами проектов (ASPM) и одобрен менеджерами группы инженерных разработок (ASBOD). Теперь члены группы знали, что их цели не будут меняться без явно указанных причин. К тому же другие могут начать составлять свои планы на основе согласованного набора предпосылок. Возникшая в результате страница текста стала точкой отсчета для установления и усиления постоянства целей. Мы назвали ее "соломенная лошадка" – Straw Horse Plan. <...> Позднее мы повысили ранг этого плана, назвав его "оловянной лошадкой" (Tin Horse) и подчеркивая тем самым повысившуюся надежность лежащих в его основе планов и обязательств. Мы пришли к согласию относительно генерального плана размером в одну страницу, исходя из которого бригады (teams) могли создавать собственные планы. <...>

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

Центр управления ввел в практику ежемесячные проверки, информация о которых фиксировалась в документах единого образца объемом в одну страницу. <...>

После уяснения общей концепции программы и составления планов мы все оказались во власти эйфории. Но вскоре на смену ей пришло отчаяние, вызванное пониманием огромной сложности предстоящей работы. Главной проблемой в тот момент было сдвинуть программу с мертовй точки. Модель управления через вовлечение подразумевает тесную связь между наращиванием темпов (стадия признания -- изучения) и стадией контроля. Иными словами, события, установленные в ходе проверки, помогли нам раскручивать маховик всей программы. Центр управления активизировал усилия по разъяснению ее общей концепции, и когда исполнители все активнее стали браться за дело, у них уже не было времени предаваться унынию перед лицом предстоящей работы. Размах нашей программы был поистине колоссальным, и неудивительно, что у многих участников стали опускаться руки. По коридорам пошли разговоры о том, что всю работу не переделаешь, что график будет постоянно срываться и всем придется работать сверхурочно. Этот синдром типичен для любого крупного проекта, особенно если его участники вынуждены брать на себя обязательства, связанные с серьезным риском. В этих условиях руководство программы приняло решение информировать участников даже о небольших успехах. Широко распространяя соответствующие сообщения по сети электронной почты корпорации Digital, мы начали вселять уверенность в своих людей. Этой уверенностью заражались другие группы, и они тоже добивались успеха. Словно волна прокатилась по всем подразделениям, участвовавшим в программе: все новые группы приходили к выводу, что предстоящая работа им под силу; и вот уже каждый коллектив стремится к тому, чтобы его достижения получили огласку. Программа стала набирать обороты.

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

На дальнейших этапах реализации программы Alpha AXP Центр управления программой развернул активную работу с другими фирмами и покупателями. Поэтому мы все время знали, что думают о нашей программе другие. <...>

Все рабочие группы программы Alpha AXP уделяли первостепенное внимание качеству своей работы. Менеджеры неоднократно убеждались в справедливости афоризма Фила Кросби -- "качество бесплатно" (P.Crosby "Quality Is Free: The Art of Making Quality Certain", 1979). Анализ работы различных групп неизменно свидетельствовал: там, где с самого начала качеству уделяют неослабное внимание, задание выполняется в срок или даже досрочно. Однако, руководство программы обратило внимание на то, что мы не занимаемся проверкой работы по повышению качества на уровне систем, а ведь клиента интересует лишь качество конечного продукта. И вот, когда различные проекты начали выстраиваться в единую систему, Центр управления создал независимую группу контроля качества уже на уровне всей программы. <...>

Результаты и уроки. Несмотря на многочисленные трудности корпорация Digital с точностью до месяца (речь идет о сроках серийных поставок) выдержала общий график работ. Система Alpha AXP соответствует проектным рабочим характеристикам при отличном качестве конечных продуктов. Совет директоров Digital утвердил бизнес-план программы Alpha AXP в полном объеме и выделил средства, необходимые для коммерческой реализации семейства машин Alpha AXP. <...>

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

Что нужно было сделать по-другому. Если смотреть с позиций дня сегодняшнего, следовало бы изменить наш подход к программе в двух отношениях. Во-первых, было бы полезно познакомить руководителей проектов с методологией управления в большем объеме и на более ранней стадии. Дело в том, что несколько проектов были завершены со значительным опозданием, и это создало ненужные осложнения для других групп. Центру управления следовало бы быстрее и энергичнее пропагандировать методологию Ляфлера (R.LaFleur "A Seminar in Project Management", 1990). Мы же не начинали эту работу, пока не убеждались, что группа осознала ее необходимость. Некоторым группам, в том числе группе разработки OpenVMS для Alpha AXP, методологию излагали на ранних этапах их деятельности. Но другие группы так и не усвоили эту дисциплину (ни тогда, ни теперь).

Во-вторых, Центр должен был шире практиковать проверки состояния дел в отдельных проектах. Некоторые группы слишком долго готовили графики и планы, которые Центр управления был в состоянии понять. <...>

Программа Alpha AXP – самое сложное предприятие такого рода в истории корпорации Digital – была реализована в срок и с высоким качеством. Для организации коллективной работы, без чего было бы невозможно совершение этого прорыва, Центр управления программы применял жесткую методологию управления.

<==

Важно отметить тех, чей вклад был во многом определяющим в этом масштабном проекте. Гордон Белл (Gordon Bell) занимался проработкой архитектуры. Кен Ольсен (Ken Olsen) настойчиво продвигал идею одностраничных планов. Джеф Калб (Jeff Kalb) ввёл принцип состязательности. Боб Сапник (Bob Supnik) проработал идею создания и принципы работы Центра управления программой.

Проект DEC Alpha AXP (1988-1992). Лебединая песня некогда могущественной корпорации DEC (Digital Equipment Corp.), которая в 1970-1990-х годах была главным конкурентом IBM в области разработки компьютерных систем. Цель – создание единой 64-разрядной платформы нового поколения для всего спектра систем: от микро- до суперкомпьютеров и сопутствующей инфраструктуры (соответствующие ОС, инструментальные средства и др.). Поддержка собственных ОС OpenVMS, Tru64 UNIX (ранее -- DEC OSF/1 AXP, Digital UNIX ), а также Linux, BSD-семейство UNIX, Windows NT. Проект ставил целью осуществить постепенный переход с CISC-архитектуры VAX на RISC-архитектуру Alpha AXP (ранее -- EVAX). Проект был реализован в рекордно короткие сроки. К концу 2000 г. в мире было продано свыше 500 тыс. систем на базе процессоров Alpha. В середине 2003 г. (через 5 лет после исчезновения Digital) фактически снятый с производства процессор Alpha был основой самых производительных суперкомпьютеров!

Предпосылки к началу проекта Alpha AXP были заложены в ходе работ над PRISM (Parallel Reduced Instruction Set Machine, 1985-1989) – 32-разрядным экспериментальным RISC-процессором корпорации Digital c операционной системой Emerald и программируемым микрокодом Epicode (прообразом Alpha PALcode – уровнем абстрагирования от аппаратуры). Проект PRISM был во многом инициирован в стенах DEC энтузиастом RISC-архитектуры Дэвидом Катлером (проект CASCADE, 1984), будущим главным конструктором Microsoft Windows NT и Windows 2000. Главный конструктор PRISM Рик Витек (Rich Witek) первоначально закладывал в проект 64-разрядную архитектуру.

Первые экземпляры процессора Alpha AXP были продемонстрированы в феврале 1991 г. и произвели огромное впечатление на руководство Apple. Джон Скулли (John Scully), тогда возглавлявший Apple, пригласил на званный обед основателя и президента DEC Keна Ольсена (Kenneth Olsen), чтобы сделать предложение о стратегическом партнерстве – использовать Alpha AXP в новых моделях компьютеров Apple. Ольсен отклонил предложение. Как впоследствии вспоминал Уильям Деммер (William R. Demmer), бывший вице-президент Digital, отвечавший за бизнес Alpha AXP и VAX, "Кен не хотел, чтобы будущее корпорации зависело от Alpha". Через несколько месяцев Apple заключила альянс с IBM и Motorola по использованию процессоров PowerPC в качестве основных движков своих компьютеров. Через год Ольсен ушел с поста президента. Еще одним ударом по Digital был уход в 1991 г. из компании легендарного Гордона Белла (Gordon Bell), архитектора PDP-4, PDP-5, PDP-6, PDP-11, VAX-11, Alpha AXP. С 1991 по 1995 гг. Белл совмещал работу в своей новой компании с должностью советника в Microsoft, а после 1995 г. стал штатным сотрудником Microsoft Research и полностью отдал себя исследованиям.

Через 7 лет после упомянутой выше встречи руководства двух компаний Digital была похоронена компанией Compaq, сумевший в рекордно короткий срок при участии Intel и Microsoft уничтожить все следы некогда существовавшей могущественной корпорации. А потом и сама Compaq сдалась на милость победителю в лице HP.

Дополнительная информация

Richard Sites "Alpha AXP Architecture" // Communications of the ACM, February 1993.

Richard Sites, Anton Chernoff, Matthew Kirk, Maurice Marks, Scott Robinson "Binary Translation" // Communications of the ACM, February 1993.

Nancy Kronenberg, Thomas Benson, Wayne Cardoza, Ravindran Jagannathan, Benjamin Thomas "Porting OpenVMS from VAX to Alpha AXP" // Communications of the ACM, February 1993.

Matt Reilly "Designing an Alpha Microprocessor" // IEEE Computer, July 1999.

М.Рэйли "Как рождается микропроцессор Alpha" // Открытые системы, #07-08/1999.

Л.Черняк "Памяти Digital Equipment Corporation (1957 — 1998)" // Открытые системы, #03/2002.

Л.Черняк "От VAX до Alpha" // Computerworld Россия, #08/2005.

Дж. Виджаян "Digital открывает перед процессорами Alpha новые перспективы" // Computerworld Россия, #02/1997.

Д. де Во "Нелегкие времена Digital" // Computerworld Россия, #12/1997.

Р.Богатырев "Даст ли Oberon новый импульс развитию платформы Digital Alpha" // СomputerWeek-Moscow, #40/1997.

Р.Богатырев "Compaq и Digital: шок сменяется прозрением" // СomputerWeekly, #05/1998.

Р.Богатырев "Эволюция UNIX" // СomputerWeekly, #05/1998.

Д.Грей, Л.Род "Alpha на двоих. Compaq передает Intel секреты своего процессора" // Computerworld Россия, #25/2001.

Д.Грей "Технологии Alpha на службе у Intel" // Computerworld Россия, #33/2001.

Дж.Николаи "Будущее расставание с Alpha" // Computerworld Россия, #48/2002.

М.Кузьминский "За явным преимуществом. Alpha 21164 и 21264" // Computerworld Россия, #29/1997.

М.Кузьминский "Микроархитектура DEC Alpha 21264" // Открытые системы, #01/1998.

М.Кузьминский "Вперед под флагом параллелизма. Микропроцессоры Alpha 21364" // Computerworld Россия, #32/1999.

М.Кузьминский "Многонитевая архитектура микропроцессоров. Compaq Alpha 21464, Intel Xeon MP и Itanium Processor Family" // Открытые системы, #01/2002.

М.Кузьминский "RISC сдается, но не умирает. СMP, SMT, EPIC — три перспективных подхода к развитию архитектур высокопроизводительных микропроцессоров" // Computerworld Россия, #06/2002.

Ю.Долбнев "Операционная система Digital Unix" // Открытые системы, #03/1997.

С.Брик, К.Вахрамеев "OpenVMS сегодня и завтра" // Открытые системы #05-06/2000.

Л.Левин "Itanium — третья платформа OpenVMS" // PC Week, #41/2007.

Л.Черняк "От VAX до лезвий. Операционной системе OpenVMS исполнилось 30 лет, но ее ресурс далеко не исчерпан" // Computerworld Россия, #40/2007.

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

2007-11-22T12:18:01Z

Начало заметки см. 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. Ортогональная система языков в проекте "Роса"

2007-11-22T11:47:04Z

Предпроектные исследования в рамках проекта "Роса" велись по двум основным и взаимосвязанным направлениям: (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-11-22T10:59:49Z

Предпосылки проекта "Роса" сформулированы в моей статье "Нужна ли России своя операционная система?" (июнь 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. В.Ф.Турчин, теория метасистемных переходов и метасистемное программирование

2007-10-23T23:50:30Z

Начало заметки см. 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) Эдгар Дейкстра отмечал: "Похоже, что иерархические системы обладают тем свойством, что нечто, рассматриваемое как неделимое целое на одном уровне, рассматривается как составной объект на следующем, более низком уровне с большей детализацией; в результате дискретность пространства или времени, применимая на каждом уровне, уменьшается на порядок величины при переходе от одного уровня к другому, следующему за ним более низкому. Мы воспринимаем стену через понятие кирпичей, кирпичи – через понятие кристаллов, кристаллы – через понятие молекул и так далее. В результате количество уровней, которые могут быть осмысленно выделены в иерархической системе, в некотором роде пропорционально логарифму отношения между наибольшим и наименьшим дискретами, и поэтому, если только это соотношение не чрезмерно велико, мы можем ожидать появления не слишком большого числа уровней. В области компьютерного программирования наш базовый строительный блок имеет дискретность времени менее микросекунды, но наша программа может потребовать несколько часов вычислений. Я не знаю никакой другой технологии, перекрывающей отношение 10¹⁰ и более: компьютер, благодаря его фантастической скорости, кажется, впервые предоставил нам среду, в которой артефакты с высокой степенью иерархичности одновременно и возможны, и необходимы. Этот вызов, а именно противостояние задаче программирования, столь уникален, что новый опыт может рассказать нам очень много нового о нас самих. Он может углубить наше понимание процессов разработки и созидания, он может дать нам лучший контроль над организацией нашего мышления. Если бы он не сделал этого, на мой взгляд, мы вообще не заслуживаем компьютеров! Он уже преподал нам несколько уроков, и один из них, который я выбрал, чтобы акцентировать внимание в этом докладе, заключается в следующем. Мы будем программировать гораздо лучше, если только подойдём к задаче, полностью оценивая её потрясающую сложность, если только мы будем придерживаться скромных и элегантных языков программирования, если только мы примем во внимание свойственные человеческому разуму ограничения и подойдём к задаче как Очень Смиренные Программисты".

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

2007-10-23T23:38:59Z

Начало заметки см. RB30-1.
Окончание заметки см. RB30-3.

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

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

Набросанная нами схема наводит на мысль, что любая сложная система, возникшая в процессе эволюции по методу проб и ошибок, должна иметь иерархическую организацию. Действительно, не имея возможности перебрать все мыслимые соединения большого числа элементов, природа перебирает соединения из нескольких элементов, а найдя полезную комбинацию, размножает её и использует как целое в качестве элемента, который может быть связан с небольшим числом других таких же элементов. Так и возникает иерархия. Это понятие играет огромную роль в кибернетике. Фактически всякая сложная система, как возникшая естественно, так и созданная человеком, может считаться организованной, только если она основана на некой иерархии или переплетении нескольких иерархий. Во всяком случае, до сих пор мы не знаем организованных систем, устроенных иначе.
<…>
Деление системы понятий на уровни не является столь безусловным, как мы молчаливо предполагали. Могут быть случаи, когда понятия k-го уровня непосредственно используются на k+2-м уровне, минуя k+1-й.
<…>
Чтобы быть более универсальной, система должна быть подобной не одной пирамиде, а многим пирамидам, вершины которых расположены приблизительно на одном уровне и образуют множество понятий (а точнее, множество систем понятий), в терминах которых происходит управление действиями животного и которые обычно обнаруживаются при исследовании его поведения. Об этих понятиях говорят, что они составляют основу определённого «образа» внешнего мира, который складывается в представлении животного (или человека). Состояние классификаторов этого уровня является непосредственной информацией для исполнительной части нервной сети (т.е. в конечном счёте для эффекторов). Каждый из этих классификаторов опирается на определённую иерархию классификаторов — пирамиду, по которой движется информация так, как это было описано выше. Однако пирамиды могут перекрываться в своих средних частях (и заведомо перекрываются в своей нижней части — рецепторах). Общее число вершин пирамиды может быть теоретически как угодно велико, в частности, оно может быть много больше общего числа рецепторов. Это тот случай, когда одна и та же информация, доставляемая рецепторами, представляется множеством пирамид в множестве различных форм, рассчитанных на все случаи жизни.

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

Простые и сложные рефлексы

Раздражимость и нервная сеть ведут к понятиям простых и сложных рефлексов.

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

Память

Что есть память в контексте теории Турчина? Что вызвало её появление в ходе эволюции?

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

Иерархия целей и планов

Иерархия распространяется не только на сами системы, но также на планы и цели.

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

Структурные и функциональные схемы

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

В.Ф.Турчин пишет: “На структурной схеме кибернетической системы указывается, из каких подсистем состоит данная система. Часто указывается также, как направлены потоки информации между подсистемами. Тогда структурная схема превращается в граф. В математике называют графом систему точек (вершин графа), некоторые из которых соединены линиями (дугами). Граф называется ориентированным, если на каждой дуге указано определённое направление. Структурная схема с указанием потоков информации есть ориентированный граф, вершины которого изображают подсистемы, а дуги — потоки информации.

Такое описание кибернетической системы не является единственно возможным. Часто нас интересует не столько структура системы, сколько её функционирование, действие. Ещё чаще мы просто ничего не можем сказать толком о структуре, но кое-что можем сказать о функционировании. В таких случаях можно построить функциональную схему. Это тоже ориентированный граф, но вершины здесь изображают различные множества состояний системы, а дуги — возможные переходы между состояниями. Дуга соединяет две вершины в направлении от первой ко второй в том случае, если хотя бы из одного состояния, относящегося к первой вершине, возможен переход в какое-либо состояние, относящееся ко второй вершине. Множества состояний мы будем называть обобщёнными состояниями. Следовательно, дуга на схеме указывает возможность перехода из одного обобщённого состояния в другое. Если структурная схема отражает главным образом пространственный аспект, то функциональная — главным образом временной. Формально в соответствии с данным выше определением функциональная схема вообще никак не отражает пространственного аспекта — разделения системы на подсистемы. Однако, как правило, разделение на подсистемы находит отражение в способе определения обобщённых состояний, т.е. разделения множества всех состояний системы на подмножества, «приписанные» к различным вершинам графа".

Феноменологическое описание

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

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

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

2007-10-23T23:06:52Z

Продолжение заметки см. 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.

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

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

В.Ф.Турчин “Теория метасистемных переходов” // Компьютерра, #25, 02.07.2001 г.
В.Ф.Турчин “Рефал как язык для обработки XML-документов” // Компьютерра, #25, 02.07.2001 г.
Л.Левкович-Маслюк “Четыре проекта Валентина Турчина” // Компьютерра, #25, 02.07.2001 г.
А.Чеповский “Метавычисления – теория метасистемных переходов в программировании” // Компьютерра, #25, 02.07.2001 г.
А.Климов “Главные вехи в истории метавычислений” // Компьютерра, #25, 02.07.2001 г.
М.Отставнов “Валентин Турчин: 'Проплыть между Сциллой и Харибдой'” // Компьютерра, #25, 02.07.2001 г.
“Феномен Турчина” – Радио “Свобода”, 03.04.2001.
В.Редько “Концептуальные теории эволюционной кибернетики. Теория метасистемных переходов В.Ф.Турчина” (1999).
В.Ф.Турчин “О кибернетической эпистемологии”
В.Ф.Турчин “Кибернетическая онтология действия”
А.П.Ершов “О сущности трансляции” (1977) — http://www.europrog.ru/classics/ae1977.pdf
Документы, связанные с В.Ф.Турчиным из архива А.П.Ершова
Материалы о В.Ф.Турчине из журнала “Индекс”

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

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

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

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

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

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

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

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

Нервная сеть

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

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

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

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

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

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

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

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

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

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

RB29-2. Джордж Пойа о решении задач в программировании

2007-09-25T11:46:22Z

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

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

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

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

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

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

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

Ну вот мы и подошли к вершине нашего повествования. К той схеме, которую Джордж Пойа озаглавил "Как мы думаем" (с.253).

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

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

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

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

Цитата из книги "The Age of Reason" (Baltimore, 1956) выдающегося американского просветителя, политического деятеля и публициста Томаса Пэна (Thomas Paine, 1739-1809), именем которого назван штат Пенсильвания: "Каждый исследователь, изучавший деятельность и развитие человеческого ума, основываясь на наблюдениях над собственным умом, не мог не заметить, что существуют две различные категории того, что называют мыслями: к первой относятся те, которые мы порождаем активно, посредством акта мышления, обдумывания, ко второй – те, которые вспыхивают в нашем сознании самопроизвольно. Я всегда почитал за правило общаться с этими добровольными пришельцами со всевозможной вежливостью и старался изучить, насколько мне позволяли мои способности, заслуживают ли они внимательного приёма; именно благодаря им я и приобрёл почти все знания, которые имею".

Косвенная ссылка на книгу "Афоризмы" немецкого физика и писателя Георга Кристофа Лихтенберга (1742-1799). Пойа пишет: "Лихтенберг как-то заметил, что не следует говорить "я думаю", но – "думается", подобно тому как говорят: "светает", "морозит". Лихтенберг утверждает, что существуют спонтанные акты мышления, которыми мы не можем управлять, подобно тому как мы не можем управлять великими силами природы. Мы могли бы сюда ещё добавить, что разум наш иногда ведёт себя подобно упрямой лошади или мулу – странному животному, к которому мы должны приноровиться и которого должны время от времени понукать, чтобы заставить его служить нам, ибо, вообще-то говоря, он довольно часто отказывает нам в своих услугах".

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

RB29-1. Джордж Пойа о решении задач в программировании

2007-09-25T11:36:24Z

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

В нескольких заметках Дейкстры (EWD480, EWD512, EWD881) содержится указание на книги известного математика Джорджа Пойа, посвящённые подходам к решению математических задач ("How to Solve It", "Art of Plausible Reasoning" и др.). Дейкстра уловил важную аналогию. Он видит в этих книгах ответ на вопрос, как нужно подходить к решению задач в программировании. Собственно, ценность и универсальность этих книг в отношении подхода к решению задач в сфере интеллектуальной деятельности отмечают очень многие известные специалисты, чьи интересы выходят за рамки чистой математики. В частности, их выделяет наш лауреат Нобелевской премии по физике Жорес Алфёров.

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

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

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

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

Биографическая справка. Джордж Пойа (George Polya, 1887-1985) – математик с мировым именем. Родился в Будапеште. В отечественной литературе известен как Георг Полиа (немецкий вариант его имени и фамилии) и Дьёрдь Пойа (венгерский вариант). Но наибольшее распространение получил американский вариант (Джордж Пойа). В предвоенные годы работал в Швейцарии (в ETH Zurich), Англии (Oxford University, Cambridge University) и Германии. Затем, как и многие другие учёные, вынужден был покинуть Европу и переехать в США. Сферой его научных интересов были такие области математики, как теория чисел, комбинаторика, теория вероятностей. Пойа большую часть своей научной карьеры провёл в ранге профессора математики в знаменитом Стэнфордском университете в США.

Некоторые книги проф. Пойа были переведены на русский язык:
1. Г.Г.Харди, Дж.Е.Литтльвуд, Г.Полиа "Неравенства" – ИЛ, 1948.
2. Г.Полиа, Г.Сегё "Задачи и теоремы из анализа" (в 2-х томах) — Гостехиздат, 1956.
3. Г.Полиа "Как решать задачу" – Учпедгиз, 1959.
4. Г.Полиа, Г.Сегё "Изопериметрические неравенства в математической физике" – Физматгиз, 1962.
5. Г.Полиа "Математика и правдоподобные рассуждения" – ИЛ, 1957.
6. Дж.Пойа "Математика и правдоподобные рассуждения" (1975).
7. Дж.Пойа "Математическое открытие. Решение задач: основные понятия, изучение и преподавание" (1970).

Две последних представлены в Открытой электронной библиотеке в Европейском центре программирования (EuroProg.ru).

Для представления взглядов проф. Дж.Пойа я выбрал книгу "Математическое открытие", пожалуй, наиболее ценную для нашей цели изучения природы программирования. В оригинале на английском языке она вышла в свет двумя отдельными томами (в 1962 и 1965 гг.); в 1968 г. второй том был переиздан с исправлениями и дополнением. Это очень взвешенный взгляд мудрого человека, изложенный простым и понятным языком. И здесь для нас будет важна целостность видения: посмотреть на глубинные проблемы мышления глазами проф. Пойа в рамках одной конкретной его книги.

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

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

"Процесс решения задачи,— уточняет он,— представляет собой поиск выхода из затруднения или пути обхода препятствия, — это процесс достижения цели, которая первоначально не кажется сразу доступной. Решение задач является специфической особенностью интеллекта, а интеллект – особый дар человека; поэтому решение задач может рассматриваться как одно из самых характерных проявлений человеческой деятельности…"

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

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

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

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

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

Итак, найти решение означает построить мост между отправным и конечным пунктами абстракций (предпосылкой и заключением). Выстроить его в виде взаимосвязи рассуждений (цепочки или более сложной схемы). Представление этой взаимосвязи напрашивается выполнять в графическом виде. Хотя… Есть естественный язык, есть язык формул, есть язык образов (и не только графических). У каждого — свои плюсы и минусы. Обязательно ли использовать только один из них? Или можно комбинировать? Математика несмотря на всю свою строгость и формальность наглядно демонстрирует, что требуются все три вида. Да и естественным языком не стоит пренебрегать, сколь бы расплывчатыми и многозначными не казались его формулировки. "Достаточно часто отмечалось, что язык, которым мы пользуемся, полон метафор (слабых, посредственных и ярких). Однако мне неизвестно,— пишет Пойа,— замечено ли также то, что многие из этих метафор взаимозависимы: они могут быть как-то связаны между собой, как-то объединены, могут образовывать более или менее независимые или, наоборот, более или менее сцепленные между собой группы". Запомним этот момент. В дальнейшем он нам пригодится.

А что есть решение, что служит результатом наших умственных усилий? Это объект или процесс? Пойа рассматривает оба значения слова "решение". Он пишет: "Решение (объект, solving object) — объект, удовлетворяющий условию задачи. Если в задаче ставится цель решить алгебраическое уравнение, то решение (объект) — это корень уравнения, т.е. величина, удовлетворяющая уравнению. Решение (объект) может существовать только у задач на нахождение. В отчётливо сформулированной задаче должна быть заранее чётко указана категория (множество), к которой принадлежит решение (объект),— мы должны знать наперёд, что мы ищем: треугольник ли, число ли, или ещё что-нибудь. Такое указание (чёткое выделение множества, к которому принадлежит неизвестное) является важной частью задачи. "Найти неизвестное" означает найти (отождествить, построить, провести, получить,…) решение (объект) [или множество всех решений (объектов)]." Пойа выделяет особенности и второго значения слова "решение". Он уточняет: "Решение (процесс, solving procedure) — процедура (построение, схема операций, система выводов), заканчивающаяся нахождением неизвестного в задаче на нахождение или ликвидацией сомнения в справедливости (или ложности) утверждения, высказанного в задаче на доказательство. Таким образом, решение (процесс) — термин, применимый к обоим видам задач. В начале работы мы обычно не знаем процедуры решения, надлежащей схемы операций, но мы неустанно ищём её в надежде, что, в конце концов, определим её полностью; эта процедура является частью наших поисков; она по смыслу, по сути дела,— наше неизвестное, она (употребим такое выражение) наше "процедурное неизвестное". Можно говорить о "работе над решением" (work of solving) или о "результате решения" (result of solving)…"

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

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

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

Пойа упоминает о методе Декарта. О чём идёт речь? В своих "Правилах для руководства ума" французский философ и математик Рене Декарт (1596-1650) постарался сформулировать универсальный метод решения задач. Его метод выражается в трёх пунктах.

1. Задача любого вида сводится к математической задаче.
2. Математическая задача любого вида сводится к алгебраической задаче.
3. Любая алгебраическая задача сводится к решению одного-единственного уравнения.

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

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

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

Итак, Пойа формулирует четыре уровня, четыре аспекта:
1. Геометрические образы (приближение к образным формам в мышлении).
2. Связи (взаимосвязь форм, соответствия, отображения, отношения).
3. Вычисления (язык формул, вбирающий в себя образы и связи).
4. Эвристика ("суфлёры", рецепты решений).

Пойа терпеливо ведёт нас к своей модели, той заветной модели, которая поясняет, как же мы думаем. Но не будем торопить события, нам ведь важно это понять, не так ли?

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

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

Пойа приводит слова Т.Гоббса из его "Левиафана": "От желания возникает мысль о некоторых средствах, при помощи которых мы видим осуществлённым нечто подобное тому, к чему мы стремимся, и от этой мысли — мысль о средствах для достижения этих средств, и так далее, пока мы не доходим до некоторого начала, находящегося в нашей собственной власти". В этих словах, как пишет Пойа, "с замечательной краткостью и точностью изложен фундаментально важный метод, определяющий процесс решения задачи". Он продолжает: "Итак, перед нами стоит задача. Иными словами, у нас есть цель A, к которой мы не можем прийти сразу, и мы стремимся найти подходящий образ действий для её достижения. Эта цель может принадлежать к области практики или к области теории, возможно, она относится к математике… "От желания возникает мысль о некоторых средствах" — это хорошо подмеченное свойство ума. Цель подсказывает средство: обычно вскоре вслед за желанием нам приходит мысль об определённых действиях, необходимых для осуществления этого желания… Но вернёмся к словам Гоббса: "От желания возникает мысль о некоторых средствах" B, с помощью которых можно получить A… Мы думаем, что могли бы получить A, если бы имели B. А из мысли о B возникает мысль о средствах, например, о C, с помощью которых можно получить это B… "И так далее, последовательно"… "пока мы не доходим до некоторого начала, находящегося в нашей собственной власти"… Мы могли бы получить D, если бы имели E, но ведь у нас есть E! На этом E заканчивается ход наших мыслей; мы обладаем E, оно "в нашей собственной власти", дано, известно…"

Далее Пойа продолжает: "То, о чём мы только что говорили, можно назвать составлением плана. За ним должна следовать, конечно, реализация плана… Заметим, что составление плана и его реализация идут в противоположных направлениях. Мы начинаем составление плана с A (цель, неизвестное, заключение); мы его заканчиваем, достигнув E (заданные нам объекты, данные, условие). Реализуя же наш план, мы напротив, продвигаемся от E к A; таким образом, об A, т.е. о нашей цели начинаем думать в самом начале, достигаем же её в самом конце. Если движение в направлении цели рассматривать как движение в прямом направлении, то можно сказать, что при составлении плана мы продвигались в обратном направлении. Таким образом, описанным Гоббсом важный метод решения задач можно было бы назвать составлением плана в обратном направлении, или продвижением от конца к началу; греческие геометры называли этот метод анализом, что по смыслу означает "решение от конца к началу". Если же мы продвигаемся в противоположном направлении, т.е. от объектов, которые находятся в нашем распоряжении, по направлению к цели (в нашем случае от E к A), то такой метод решения (в противоположность первому методу) называют составлением плана в прямом направлении, или продвижением от начала к концу, или синтезом (что по-гречески означает "соединение")".

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

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

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

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

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

Пойа раскрывает важный принцип: Respice finem. Он пишет: "Стремление достичь цели следует рассматривать как стимул, оно подсказывает нам действия, которые, возможно, приведут к достижению цели. Желанный конец диктует средства. Поэтому смотрите в конец, не спускайте глаз с вашей цели; она направляет ваши мысли. Respice finem означает "Смотри в конец"; эта фраза была обиходной во времена, когда латынь была общеупотребительной. Она взята из средневекового гекзаметра: Quidquid agis prudenter agas et respice finem (что бы ни делал, благоразумнее делай и смотри в конец). Гоббс поясняет это: "… во всех ваших действиях часто имейте перед глазами то, чего вы хотите достигнуть, как ту вещь, которая направляет все ваши мысли на пути к её достижению". Раздумывая над концом задачи, мы надеемся, что возникнет мысль о подходящих средствах для её решения. Чтобы сократить время, необходимое для прихода этой мысли, нужно стараться представить себе конец с максимальной отчётливостью: Что требуется? Какого рода объект вы хотите найти? Что представляет собой неизвестное? В чём состоит заключение? Мы должны применять самые настойчивые усилия, чтобы вызвать в своём воображении подходящие средства: Как можно получить такой объект? Где можно отыскать подобный объект? В каком магазине можно приобрести подобную вещь? Как можно вывести такое заключение?"

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

Окончание заметки см. RB29-2.

RB28. Закон Гордона Мура и закон Дэвида Мэя

2007-09-13T11:15:56Z

Пред. заметки, посвящённые новой ОС "Роса", см. Оглавление.

Многие знают закон Гордона Мура (Gordon Moore), одного из основателей корпорации Intel. Этот закон, сформулированный ещё в 1965 г. ("Cramming more components onto integrated circuits", Electronics Magazine, 19 April 1965), гласит, что новые модели микросхем разрабатываются спустя примерно одинаковые периоды (18–24 мес.) после появления своих предшественников, а их ёмкость (число транзисторов) при этом каждый раз возрастает примерно вдвое. Мур говорил не о мощности, не о быстродействии, а о росте сложности процессора. Нередко его закон упрощают, трактуя как двукратный рост быстродействия процессоров каждые два года. Что и в самом деле наблюдается на протяжении последних десятилетий.

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

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

Какую картину мы наблюдаем сегодня? Производительность растёт темпами, заданными законом Мура, а программное обеспечение как было неповоротливым, так им и остаётся. Быть может, здесь есть какая-то закономерность? В своей статье "Оберон как эсперанто программирования" ("Мир ПК-диск", сентябрь 2005) я дал некую оценку распространения закона Мура на объёмы инструментария (систем программирования). Признаюсь, не знал, что в том же сентябре 2005 г. в своей лекции "The Return of Innovation" другую закономерность подметил Дэвид Мэй (David May), архитектор семейства транспьютерных микропроцессоров (группы T2, T4, T8, T900) в знаменитой английской компании Inmos (язык Occam), а ныне — профессор Бристольского университета в Великобритании. Закон Мэя гласит, что эффективность программного обеспечения падает вдвое каждые 18 месяцев, компенсируя закон Мура.

Как отмечает Мэй, в соответствии с законом Мура каждые 18 месяцев удваивается отношение производительности к стоимости. Это позволяет увеличивать отношение функциональности к производительности (при фиксированной стоимости) или уменьшать стоимость при фиксированном отношении функциональности к производительности.

Мэй отмечает, что нынешние программные системы полны ошибок, чересчур велики и сложны для понимания. С этим трудно не согласиться. Беда в том, что такая ситуация устраивает очень многих. Устраивает производителей процессоров (в них нуждаются постоянно, чтобы мощью процессоров гасить непрерывное падение эффективности ПО). Устраивает производителей операционных систем (их задача – привязать к себе пользователей, при сохранении стоимости на новые версии ОС нагрузить до предела новые процессорные мощности, демпфируя их рост). Устраивает производителей инструментария (он усложняется и пухнет, но при этом позволяет лишь держаться на плаву на достигнутой отметке). Такой расклад удобен тем компаниям, которые заинтересованы за счёт избыточной сложности приковывать к себе клиентов и именно на этом строить свой бизнес. Но в этом не заинтересованы потребители (которые и расхлёбывают все прелести ненадёжных тысячеслойных систем), а также те разработчики, которым нужно создавать технологически совершенные системы, чтобы не привязываться к процессу постоянной компенсации старых ошибок путём введения ещё большего числа новых. Но они во многом подневольны и вынуждены использовать то, что диктует рынок. Собственно говоря, ИТ-индустрия и выстроена в такой последовательности воздействия одного на другое. Первичны процессоры, далее идут операционные системы и лишь потом инструментарий. Сегодня уже как-то неловко говорить о том, что в идеале должно быть в точности наоборот. Впрочем некий исторический экскурс в эту проблематику сквозь призму работ швейцарской школы Вирта и отечественного проекта МАРС (Модульные асинхронные развиваемые системы, ВНТК "Старт") лет десять назад я уже давал. См. серию из трёх статей под общим названием "Язык как основа архитектуры":
1. Проект Lilith — http://www.europrog.ru/paper/lilith.pdf
2. Проект "Кронос" и путь к технологиям XDS — http://www.europrog.ru/paper/kronos.pdf
3. Средства кросс-разработки и технологии XDS — http://www.europrog.ru/paper/xds.pdf

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

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

Думаю, немногие знакомы со статьей профессора Дэвида Парнаса "Старение программного обеспечения" ("Software Aging", 1994). Того самого Парнаса, с работ которого начала 1970-х ведётся отсчёт эры модульного программирования и принципа информационного сокрытия (information hiding). В статье достаточно убедительно показан тот феномен, как программа, будучи вроде бы математической абстракцией (которая должна оставаться справедливой и спустя 200 лет), тем не менее подвержена старению. Причины — она живёт в мире изменений. Старение, по словам Парнаса, может и будет возникать в любом успешном продукте. Это надо знать и, если требуется строить максимально адаптивную систему, закладывать данное знание в проект. Чтобы этого добиться (добавлю от себя), недостаточно только предусматривать возможности возникновения различных классов изменений как на стадии разработки продукта, так и в период его использования и развития. Важно выстраивать фундамент с возможностью расширения/коммутации и минимизацией зависимостей. Модульное программирование (вышедшее из модульного проектирования) как механизм разбиения большого на малое и как средство конкретизации функциональности (с целью последующего обобщения) обладает наибольшей устойчивостью и гибкостью для подобных целей. ОО-проектирование (как механизм обобщения для последующей конкретизации) хорошо себя зарекомендовало в тех областях, где нет белых пятен и где фундамент можно строить надолго. Но таких сфер гораздо меньше, чем мы думаем. Сочетание достоинств этих подходов, а также функционального и сценарного программирования вместо нынешней диктатуры ООП – вот путь, по которому мы планируем идти.

В рамках проекта "Роса" мы подошли к идее создания полноценной собственной методологии разработки сложных программных систем, которая позволила бы вобрать в себя целый комплекс вопросов построения/конструирования систем в условиях промышленного разделения труда с сохранением гибкости и свободы для работы распределённых коллективов, вовлечённых в движение Open Source. Причём идя не по пути усложнения и насыщения возможностями разные интерфейсы, языки и сопутствующий инструментарий, а по пути концептуальной экономии (ортогональность средств), учитывая позитивный и негативный опыт таких подходов, как IBM Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), Dynamic Systems Development Method (DSDM), Scrum, Agile Unified Process (AUP), Cleanroom Software Engineering, Modular Approach to Software Construction Operation and Test (MASCOT), а также ряда других.

Всё это подразумевает формирование своей достаточно универсальной методологии, своего инструментария, своего набора языков, своей операционной платформы. При этом нам потребуется постараться снизить порог вхождения, сделать приемлемой для нынешних разработчиков миграцию в эту методологию, а также обеспечить поддержку параллельного сосуществования хотя бы одной из трех популярных операционных платформ: POSIX (Си), Java Platform (Java), .NET/CLR (C#).

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

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

1. В настоящее время мы видим проблемы доминирования Windows-семейства и противостояния Linux. Проблемы технологические, проблемы социальные, проблемы экономические.

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

3. Мы знаем, что в области работ европейской школы проф. Вирта (ETH Zurich) за три с половиной десятилетия накоплен богатый неиспользованный потенциал. Главная причина: технологический, научный и маркетинговый изоляционизм.

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

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

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

7. Мы понимаем, что приоритет технологического совершенства, создаваемого группой специалистов-единомышленников в условиях свободного творчества, требует принципиально иного подхода к работе — приоритета исследований, что отражено в нашей концепции Open Research Programming.

8. Мы ставим перед собой цель проведения НИОКР до начала производства новой ОС (где и будут формулироваться конкретные бизнес-требования к превращению полуфабриката в продукт).

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

10. В случае невозможности перехода к стадии производства продукта (из-за недостаточного ресурсного обеспечения по завершении НИОКР) мы рассматриваем вариант изготовления из полуфабриката ОС продукта, предназначенного для сферы автоматизации научных исследований в рамках финансирования по линии европейских проектов.

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

Если говорить о направленности ОС и о проработке вариантов для разных ниш (с точки зрения перенацеливания ОС), то можно отметить следующие группы (учитывающие специфику аппаратного обеспечения):
1. Встроенные ОС (Embedded OS)
2. Клиентские ОС (Desktop OS).
3. Серверные ОС (Server OS)
4. Сетевые ОС (Network OS: LAN OS, Web OS)

А также следующие направления (учитывающие специфику целевой аудитории):
1. Инструментальная ОС (Developer's OS)
2. ОС для автоматизации научных исследований (Scientific Research OS)
3. ОС для сферы образования (Education OS)
4. Офисная ОС (Office OS)
5. ОС для домашнего использования (Home OS)
6. ОС для индустрии развлечений (Entertainment OS)

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

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

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

RB27. Пути восхождения к новой ОС

2007-08-31T13:51:37Z

В ходе публичных и внутренних обсуждений не раз поднимались едва ли не центральные вопросы проекта: (1) Что из себя будет представлять новая ОС? и (2) Как мы будем решать эту задачу?

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

Сначала неплохо бы для себя решить вопрос: новая ОС — это действительно нечто новое или же переделка известных систем на новый лад? Вопрос простой и сложный одновременно. Для меня ответ очевидный, не раз его озвучивал — новое, иначе проект теряет смысл. Не переделка UNIX и не переделка Оберона (BlackBox, Bluebottle или чего еще). Нужно ли для этого нового сохранять возможность использования старых средств и наработок? — Почему нет? Надо знать цену вопроса.

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

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

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

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

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

Нередко можно слышать, что простые языки и системы (как язык Оберон и система Oberon) – это не более чем академическая забава, что ИТ-индустрии (а заодно и науке с образованием) нужны мощные, современные и, разумеется, сложные вещи.

Это один из ключевых вопросов, имеющих отношение к нашему проекту, поэтому остановлюсь на нём подробнее.

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

Зачем пытаться обобщить, отрезать лишнее, выявить ядро? Когда? Во имя чего? Это нудно, тяжело, не возвышает над другими. И, главное, снимает зависимость других от тебя. Т.е. лишает тебя дивидендов. Сегодня и завтра.

Паранойя сложности — как наркотик. Который точно нащупала ИТ-индустрия и ловко этим пользуется. Ей это позволяет не останавливать производство всё новых и новых "пилюль" для массового потребления (что пользователей, что разработчиков, что проектировщиков), постоянно извлекать прибыль, ставить в зависимость от себя. И всем хорошо. А мы говорим — простота... Пожалуй, в современном программировании, как нигде ещё, справедлива поговорка "простота хуже воровства". В книге "Язык и ментальность" профессор В.В.Колесов (зав.кафедрой русского языка Санкт-Петербургского государственного университета) пишет по этому поводу: "Простой — по смыслу слова "открытый" навстречу всем влияниям и зависимый от обстоятельств жизни... Как толкует слово Владимир Даль, простой — "ничем не занятый, сам по себе, не сложный по натуре, но слишком прямой, чтобы сгибаться перед всяким". Простые языки не сгибаются и – получают по полной программе. Чему удивляться, что простые вещи (Лисп, Форт, Пролог, Smalltalk, Оберон и др.) попирают ногами? Даже Си не миновала сия незавидная участь. Удивляться не стоит. Такова жизнь.

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

Наверное, нам всем всё же не стоит закрывать глаза на то, что сложность программного обеспечения выходит из-под контроля. Но почему теряется контроль? Давайте задумаемся. Только ли потому что сложные системы можно делать исключительно сложными инструментами? Неужели? Оставим в стороне Оберон. Лисп — сложный инструмент? Си — сложный инструмент? Значит, дело скорее в мозгах. В наработанных стереотипах. В том, что когда срочно нужен результат, когда нет времени обдумать, делают по накатанному. По стереотипам. А туда ли накатана дорожка? Кто её накатывал? Какие он принимал решения, какие выбирал критерии и почему отбрасывал другие варианты?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь о разрыве науки и производства. И это тоже имеет непосредственное отношение к теме заметки – путям восхождения к новой ОС.

Как показывает опыт, исследователи редко в состоянии довести свои идеи до продукта качественной реализации. Нередко они останавливаются на пол-пути, считая свою миссию завершённой. Они идеи сформулировали, показали миру, что идеи реализованы и работают. И достаточно. Что такое product management, им, как правило, неведомо.

В производстве другая проблема. Там могут довести продукт. Но на основе каких идей? Верно, тех, по которым есть минимум рисков (кадры, заказчики, сроки, ресурсы). Не последнюю роль играет конъюнктурная обоснованность и модность тех или иных решений и инструментов. Экспериментальным разработкам очень редко находится место в современном программном промышленном производстве. Слишком велики риски.

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

Пока основную нагрузку на себя берут связки исследовательских подразделений компаний (крупных; мелкие редко могут себе позволить такую роскошь) с лабораториями при университетах. Но крупные компании во главу угла ставят что? Правильно: сохранение и усиление своего влияния на рынке. Что и даёт необходимую прибыль. А для этого технологическое совершенство не только не полезно, а даже вредно, ибо может подорвать завоёванные позиции. В результате ряд интересных совместных разработок (скажем, Стэнфордского университета и Альмаденского центра IBM) тихонько спускают на тормозах. Как тут не вспомнить и компанию Borland, которая похоронила в своих недрах Turbo Modula-2 лишь бы она не подорвала рыночные позиции Turbo Pascal. Это привело к скандальному уходу из Borland соучредителя и вице-президента Нильса Йенсена вместе с возглавляемой им группой. В конечном итоге технологическое совершенство пало жертвой амбиций и финансовых интересов.

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

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

Собственно, модель Open Research Programming, которуя я ранее излагал, даёт необходимый фундамент для этого. Можно относительно быстро концентрировать интеллектуальный потенциал на направлениях решения серьёзных, востребованных задач. Решать задачу последней мили (и даже вывода на рынок продуктов, минуя "заградотряды" монополистов). Результатом такой концентрации может быть не только и не столько сам базовый конечный продукт (его бесплатность, открытость и высокое промышленное качество исполнения — важнейшие принципы), сколько побочные вещи (кадры, технологии, другие продукты: взаимовыгодное сотрудничество с производством и наукой в решении многих побочных задач). Но концентрация интеллектуального потенциала должна строиться на сильной задаче (социальном и технологическом заказе) и на принципах взаимовыгодного сотрудничества всех вовлечённых в это людей, способного привнести необходимые ресурсы для её решения. Когда финансы — не основа мотивации, а лишь необходимое топливо. Для "инвесторов" (речь не только о финансах) привлекательность подобных промежуточных организаций, связывающих науку и производство и способных выводить на орбиту качественные и серьёзно проработанные вещи, достаточно высока.

Однако на всё нужно время.

RB26. Дуальность и другие контуры "Росы"

2007-08-24T12:35:58Z

Организационные моменты

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

1. Цели проекта и пути их достижения
2. Требования к ОС
3. Процессорные архитектуры
4. Языки и межъязыковое взаимодействие
5. Внутренняя информационная инфраструктура

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

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

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

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

Надо сказать, что идеи Open Source Initiative и "базарная модель" Эрика Реймонда наложили свой отпечаток на восприятие методов коллективной работы над открытым программным обеспечением. Как выясняется, это достаточно сильный стереотип. Желание начать кодировать и строить проект сразу вокруг единой базы исходников сталкивается с непривычными, новыми взглядами (инициативы Open Research Programming) на ведение проектов подобного масштаба силами географически распределённых специалистов, которые работают "за идею". Как уже отмечал, ключевой недостаток для создания ОС — свобода распределённого программирования для сложных систем подобного масштаба может давать эффект лишь при наличии уже кем-то сделанного базиса. Напомню то, о чем ранее писал в своих заметках. Организационно-технологический аспект в устах Эрика Реймонда в “Соборе и базаре” (1997) выливается в несколько пунктов. Главным из них он называет децентрализованный характер разработки при наличии у всех участников свободного доступа к исходным текстам. Пресловутый “базар”. При этом отмечает зону эффективности “базарной” модели разработки. Это наличие “печки”, от которой и вокруг которой все танцуют: “Абсолютно ясно, что никто в одиночку не может с нуля создать программу, опираясь на “базарную” модель. Один человек вполне в состоянии тестировать, отлаживать и совершенствовать программу, придерживаясь такого подхода, но будет крайне сложно начать реализацию проекта в “базарном” режиме. Так не делал Линус. Так не делал и я. Для зарождения сообщества разработчиков требуется работоспособный и готовый к тестированию продукт”.

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

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

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

По завершению этих этапов (которые и определяют НИОКР, специфичные для Open Research Programming) можно будет переходить к работе по созданию (производству) ОС либо в рамках, традиционных для Open Source Initiative ("базарная модель"), либо в корпоративном стиле ("соборная модель").

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

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

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

Технологические вопросы

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

Можно ли совместить несовместимое? Можно, и тому есть примеры. Сначала о том, как совместить, а потом уже о примерах (на закуску).

Контуры новой ОС вырисовываются в сопоставлении трёх миров: хорошо зарекомендовавшего себя UNIX (в центре нашего внимания QNX и MINIX 3, а также пост-UNIX в лице Plan 9), революционного экспериментального Оберона (Oberon System, BlackBox, Bluebottle) и модного исследовательского Singularity.

Singularity – это попытка Microsoft Research использовать идеи Оберона в несколько ином ракурсе. Нельзя сказать, что Обероны они не упоминают в своих работах, но при этом старательно размазывают реальный источник и суть заимствования.

Небольшая справка. Виртовские проекты Lilith/Modula-2 и Ceres/Oberon были во многом стимулированы американскими проектами Xerox Alto (Mesa) и Cedar. Причём даже не заочно-теоретически, ибо проф. Вирт ездил в Xerox PARC и имел прямые контакты с исследователями этой знаменитой лаборатории. Поэтому в отношении виртовских вещей (включая и Bluebottle Юрга Гуткнехта) корректней говорить не как о чём-то принципиально новом, а как о более чётко расставленных акцентах (чисто инженерные решения) на в общем-то известных до этого вещах. Т.е. компактная сбалансированность, сочетаемость идей и механизмов. Целью Вирта в его проектах было показать, как можно добиться совершенства путем разумного упрощения железа и софта. Возможно, здесь к месту будут слова Антуана де Сент-Экзюпери: "Совершенство достигается не тогда, когда уже нечего прибавить, а когда уже ничего нельзя отнять". На сайте EuroProg выложено немало редких материалов по проектам Alto/Mesa и Cedar, а также Lilith/Modula-2 и Ceres/Oberon.

Относительно Singularity. Надо понимать, что это — один из исследовательских проектов Microsoft Research. Он заслуживает внимания, причем повышенного, но не того "придыхания", которое мне встречалось в некоторых форумах. Магия имени Microsoft играет с людьми злую шутку. Немногие представляют себе внутреннее устройство Microsoft Research и специфику их работы. В проекте ETH Bluebottle, насколько мне известно, было занято около 3-4 человек. В проекте Singularity — на порядок больше. Считается, что это крупнейший исследовательский проект в стенах Microsoft Research, в который вовлечены специалисты из разных исследовательских подразделений. Он был инициирован производственными подразделениями Microsoft: Microsoft Core Operating System Division (COSD) и Microsoft security team. Прицел: на рынок встроенных ОС (embedded OS) и серверных ОС. Масштаб: порядка 300 тыс. строк. В качестве образца-прототипа они (точнее, лидер проекта — Galen Hunt) называют... разумеется, Xerox Cedar (а не Oberon и не Bluebottle). Декларируемая ими сверхзадача: показать, как можно писать компактную конкурентноспособную ОС с нуля, используя возможности обеспечения надёжности за счёт языка реализации высокого уровня (Sing#) и языкового инструментария (Bartok).

Для информации: впервые в публичном доступе Bluebottle появилась 1 января 2003 г. Проект Singularity (как это неоднократно отмечалось в различных интервью 2005 г.) стартовал в 2003 г. Тогда как первый программный документ Singularity Design Motivation (своего рода манифест проекта) появился в декабре 2004 г.

Если говорить о возможности концентрации интеллектуального потенциала, то в случае "Росы" в количественном выражении он в перспективе будет сопоставим с Singularity team в Microsoft Research (возможно, даже выше). Но количество не всегда переходит в качество, поэтому придется попотеть, чтобы работа внутри команды была продуктивной. Да и гандикап в пять лет будет давать о себе знать, но у нас есть преимущество — мы детально видим перед собой их "грабли" (и вполне неплохо разбираемся в том, что они называют своими ориентирами). Они опираются на тройку: SIP — CBC — MBP; software-isolated processes, contract-based channels и manifest-based programs. Уже сейчас можно сказать, что наши решения будут отличаться. И даже не в деталях.

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

Теперь несколько скучных теоретических моментов.

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

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

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

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

Итак, ОС и язык программирования (точнее, его реализация — система программирования) в пределе могут считаться одной и той же сущностью. Будем считать это некоей гипотезой и посмотрим, что она может нам дать для понимания.

В самом деле, любая ОС является программной системой (как и система программирования). Она имеет дело с унифицированным управлением задачами и распределением ресурсов (чем занимаются многие системы программирования). У языка программирования (его реализации) есть ядро — исполняющая система (run-time system). В этом смысле ОС и язык близки (для простоты изложения буду иногда приравнивать язык к его реализации; надеюсь, из контекста будет понятно, что в действительности подразумевается).

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

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

программный (API, процедурный интерфейс системных вызовов),
командный (CLI, command language interface),
пользовательский (UI, реализуемый обычно через GUI).

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

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

Пойдём дальше. Взглянем на две интересующие нас ОС, которые точно можно считать разными по архитектуре: UNIX и Oberon System.

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

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

Основу основ любой ОС составляют средства мультипрограммирования (multiprogramming, multitasking), т.е. средства диспетчеризации (планирования) процессов (задач). Думаю, стоит даже считать UNIX'ом любую ОС, которая использует именно UNIX-механизм мультипрограммирования (вне зависимости от реализации языкового слоя – программного, командного, пользовательского).

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

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

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

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

UNIX и Oberon – два полюса, две крайности. Дело за "малым" — тщательно и критически переработать накопленную информацию (а также раздобыть уточняющую) и попробовать найти новое решение. Желательно (для преемственности и гарантии практичности), чтобы оно позволяло понятным образом трансформироваться в предельные сущности — процессы UNIX и модули Оберона.

Практические контуры

Теперь к от теоретических рассуждений к практическим контурам новой ОС. К совмещению несовместимого.

Новая ОС может быть сделана дуальной. Иными словами, у неё снаружи могут быть доступны два мира – высокоуровневый (обероноподобный) и низкоуровневый (UNIX). Они сосуществуют друг с другом исходя из простого принципа – надёжный модуль (safe), использующий хотя бы один ненадёжный модуль (unsafe) считается ненадёжным.

В новой ОС осуществляется отход от моноязыковости. Выделяются два вида языков: привилегированные (пост-Оберон, Haskell, Python) и непривилегированные — Си и Java. Привилегированные языки тесно связаны своими исполняющими системами и обеспечивают гармоничную работу с ОС на уровне её высокоуровневых концепций. Непривилегированные работают в традиционном режиме и обеспечивают обогащение новой ОС унаследованным ПО из мира UNIX (GNU и др.) и мира Java (включая инструментарий Eclipse). Для переноса программного обеспечения из UNIX полноценным образом реализуется операционная платформа POSIX.

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

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

Esmertec

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

В 1993 г. три друга, три товарища, учившиеся аспирантуре в швейцарском ETH, основали компанию Oberon microsystems. Их звали Cuno Pfister, Clemens Szyperski (ныне в Microsoft Research), Beat Heeb. В 1994 г. они сделали первый вариант BlackBox. Хотелось создать своими руками хорошую среду, чтоб и Оберон заиграл и народ полюбовался, как здорово работают идеи Вирта и Гуткнехта.

И все бы ничего, но тут как гром среди ясного неба грянула Java. Что делать? Срочно была предпринята коллективная ревизия Оберона — "наш ответ Чемберлену". Собрали военный совет, тут добавили, там подправили — вот оно, что-то вышло. Новоиспечённому языку дали (из рыночных, как они говорили, соображений) имя Компонентный Паскаль (Component Pascal). Было это в 1997 г. Вирта позвали в крёстные отцы. Что делать — согласился, надо же поддержать молодёжь.

[Пишу по памяти — весной 1998 г. готовил публикацию по Компонентному Паскалю в ComputerWeek-Moscow и связался с Куно Пфистером. Тот живо откликнулся и прислал материал, который и пошёл в печать. В то время у них уже была своя ОС реального времени для встроенных систем с именем Portos.]

В 1999 г. от Oberon microsystems отпочковалась компания Esmertec. Создавали её уже четыре "танкиста" — Daniel Diez, Beat Heeb, Hansruedi Heeb и Peter Eichenberger. Во многом развитию нового направления способствовал потенциал той самой Portos. Эта ОС поддерживала два языка — Компонентный Паскаль (спец. версию для задач реального времени) и Java. Ядро реального времени делалось, разумеется, не на Java. Ну а инструментарий для кросс-разработки (на базе BlackBox) нарекли именем Denia — курортное местечко в Испании, на Коста-Бланка. Portos не нужна была ни виртуальная машина, ни интерпретатор кода, ни JIT-компилятор. Использовались идеи М.Франца.

Попытки продвинуть Змей-Горыныча о двух головах (CP/Java) заметным успехом не увенчались. Очень уж мешалось название "Компонентный" да ещё "Паскаль" в сфере микромира. Java — это класс, Java — это сила! Правильно. Сделали ставку на раскрученную вещь, зная, что уж она у них работать будет, как часы. Portos переименовали и стёрли с карты мира (чтоб никто и не вспоминал). Теперь "героя Дюма" звали Jbed — "ложе для Java". Брат Пфистера — Бернд подсуетился насчёт инвестиций, основал свой фонд, начал накачивать денег. К делу подключили связи по Европе — Франция, Германия, Швейцария. Идея народ вдохновила — ещё бы, Sun ещё там только на бумаге чертила красивые диаграммы, расставляла столбики с надписью "Java Micro Edition — руками не трогать", а они взяли и рванули. На святое замахнулись, на самое ядрёное ядро. Кто помнит, Java ведь с этой идеи начиналась, захвата микромира — "мы им там всем покажем кузькину мать!".

К началу 2007 г. количество устройств, в которых используется Jbed, достигло 100 млн. штук. Стали мировым лидером в области J2ME. Верховодил в компании француз Alain Blancquart. Кстати, ушёл в никому не известную Esmertec из Borland Europe, где занимал высший пост. Стала сколачиваться нехилая команда, пошли люди из IBM Europe, а теперь — стоит глянуть на топ-менеджмент и совет директоров: что ни персона, то ого-го!

Michel Bon — 8 лет возглавлял France Telecom
Ulrich Schumacher — бывший президент Siemens Semiconductor Group
Jean-Pascal Aubert – бывший вице-президент Bull
Michel Kuntz – бывший вице-президент Alcatel
Sylvie Vollet – бывший топ-менеджер Apple Computer Europe
Chase Bailey — бывший главный технолог в Cisco
Jean-Luc Gianduzzo – 12 лет проработал в топ-менеджменте Hewlett-Packard, затем занимался развитием новых технологий в Cisco Systems Europe.

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

История имеет ещё то продолжение, что в определённых моментах мы близки к подходам Esmertec. Они давно уже многие вещи засекретили, изъяли из публичного обращения, оставив на поверхности одну Java и обозначив компактный Smalltalk, но те, кто следили за их ростом, этими вещами обладают и спокойно могут додумать то, что и как там сделано (на уровне архитектуры и подходов). Считайте, что в технологическом (а не рыночном) понимании мы будем своеобразными конкурентами Esmertec. Но делать будем иначе, зная их плюсы и минусы. К тому же наша задача – перенацеливаемая ОС. Не только встроенные системы (реального времени), хотя они – в первую очередь.

RB25. Новая европейская ОС

2007-07-23T10:26:31Z

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

RB24. Две культуры программирования

Европе есть кем и чем гордиться. Назову лишь некоторые имена, многие из которых отмечены высшими наградами профессиональных ассоциаций, включая IFIP, ACM, IEEE Computer Society:

Алан Тьюринг, Морис Уилкс, Джеймс Уилкинсон, Чарльз Энтони Хоар, Эдгар Кодд, Тим Бернерс-Ли (все — Великобритания);
Конрад Цузе, Карл Адам Петри, Фридрих Бауэр (Германия);
Хайнц Рутисхаузер, Никлаус Вирт (Швейцария);
Эдгар Дейкстра, Адриан ван Вейнгарден (Нидерланды);
Петер Наур, Пер Бринч Хансен (Дания);
Оле-Йохан Дал, Кристен Нюгард (Норвегия);
Сергей Алексеевич Лебедев, Андрей Николаевич Колмогоров, Андрей Андреевич Марков, Сергей Львович Соболев, Моисей Исаевич Шёнфинкель, Леонид Витальевич Канторович, Алексей Андреевич Ляпунов, Сергей Юрьевич Маслов, Виктор Михайлович Глушков, Андрей Петрович Ершов, Валентин Федорович Турчин (СССР);
Владислав Турский (Польша);
Хайнц Земанек (Австрия);
Деннис Цикритзис (Греция).

Европа по праву гордится своими достижениями. Среди них:

формальная модель алгоритма (Алан Тьюринг);
первый компьютер (Конрад Цузе);
первый язык программирования (Plankalkul);
первая теория трансляции (Хайнц Рутисхаузер);
реляционная модель данных (Эдгар Кодд);
первый ПК, созданный в университете (Никлаус Вирт, Lilith);
воплощение математических моделей в железе и языке программирования (Тони Хоар, Inmos Ltd., CSP, Occam, транспьютер).

Среди ведущих парадигм программирования явные европейские корни имеют:

структурное программирование (К.Бём, Дж.Якопини, Э.Дейкстра);
объектно-ориентированное программирование (Э.Хоар, О.-Й.Дал, К.Нюгард);
модульное программирование (П.Наур — Дания, Д.Парнас — США).

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

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

Plankalkul (Германия, 1945)
Алгол-60 (IFIP, 1960)
CPL (Великобритания, 1962)
РЕФАЛ (CCCР, 1966)
Симула-67 (Норвегия, 1967)
Паскаль (Швейцария, 1970)
Пролог (Франция, 1972)
ML (Великобритания, 1973)
Эль-76 (СССР, 1976)
CSP (Великобритания, 1978)
Модула-2 (Швейцария, 1979)
Z (Франция-Великобритания, 1977)
Occam (Великобритания, 1983)
ABAP (Германия, 1984)
Eiffel (Франция, 1986)
Erlang (Швеция, 1987)
Оберон (Швейцария, 1988)
Python (Нидерланды, 1991)
OCaml (Франция, 1996).

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

World Wide Web (CERN, Швейцария, 1991)
Активные (веб)-документы (браузер+аплеты, Oberon System, ETH Zurich, Швейцария, 1991-1993)
Linux (University of Helsinki, Финляндия, 1991).

К сожалению, мы редко об этом задумываемся. Если попросить какого-нибудь специалиста назвать десяток операционных систем, отличных от мэйнстрима (UNIX, DOS, Windows), то он наверняка окажется в несколько затруднительном положении. А если попросить ещё назвать такой десяток именно европейских — тем более.

Хотя как раз-таки в сфере инфраструктурной, сфере системного программирования Европа смогла сохранить ценности и традиции своей школы.

Вот лишь несколько примеров:

ОС на основе активных документов, Oberon System (ETH Zurich, Швейцария, 1991-1993);
ОС реального времени MARS (Технический университет Вены, Австрия, 1992);
Nemesis (экзоядро, University of Cambridge, University of Glasgow, University of Twente, Swedish Institute of Computer Science, Великобритания-Нидерланды-Швеция, 1997);
кластерная ОС Plurix (университет Ульма, Германия, 1999);
L4 (микроядро, университет Карслруэ, Технический университет Дрездена, Германия, 1999);
встроенная ОС Jbed (Oberon microsystems, Esmertec, Швейцария, 1999);
встроенная ОС Camille (экзоядро, INRIA, Франция, 2000);
виртуальная ОС-машина Xen (Кембриджский университет, Великобритания, 2003);
ОС на основе активных объектов, Bluebottle (ETH Zurich, Швейцария, 2003);
DEMOS (аппаратная реализация ОС Inferno на FPGA, университет Йорка, Великобритания, 2004);
LSE/OS (наноядро, Epita System Laboratory, Франция, 2005).

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

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

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

Государственная ОС для проекта создания новой ОС — это:
1) вариант продвижения ОС на внутренний рынок России;
2) возможность финансовой поддержки стадии производства и, возможно, стадии НИОКР.

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

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

Казалось бы, если проект не политический, а в первую очередь научно-технологический, то откуда будут исходить риски?

Всего несколько моментов:

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

2. Проект посягает на сложившееся статус-кво, которое устраивает в России очень многих.

3. Проект при позиционировании как альтернативы инфраструктуре от Microsoft имеет наглость отделять себя от Linux-направления, которое рассматривается как единственный возможный выбор в любой перспективе на внутреннем рынке.

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

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

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

1. Проект уходит от замкнутости ETH-разработок и будет использовать мощный потенциал OpenSource-движения, реализуя наиболее радикальную форму воплощения идей сообщества открытых исходных текстов (public domain под зонтиком Open Research Programming).

2. Проект станет одной из важнейших точек притяжения последователей европейской школы программирования в противостоянии с моделью американизации мировой ИТ-индустрии. И это один из главных стратегических моментов всего проекта.

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

Вот логика рассуждений.

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

2. Мы не можем позиционировать свою ОС как русскую (российскую) по целому ряду причин. И далеко немаловажный из них — богатая география участников, выходящая за рамки одной страны. Нет смысла делать из системы яблоко раздора на национальной почве. Будет она государственной в России — пусть тогда с полным правом зовётся российской. А так — будет самостоятельной, без привязки к стране.

3. Для России справедливо утверждение "Нет пророка в своем Отечестве". Т.е. если делаем для своей страны и активно об этом заявляем, то ни уровень проработки, ни квалификация кадров почти ничего для общественного мнения не значат. Есть устойчивый стереотип: у нас для себя делать не умеют.

Какой напрашивается вывод?

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

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

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

Теперь, думаю, понятно, почему нами используется модель открытого исследовательского программирования Open Research Programming. Понятна ставка на виртовскую школу. Понятна наукоёмкость. Понятен отход от моноязыковой системы. Понятно требование технологического совершенства. И понятен уникальный статус проекта, который за счёт такой идеи способен привлечь к себе на продолжительный период очень сильные кадры.

RB24. Две культуры программирования

2007-07-23T10:18:34Z

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

11 сентября прямым рейсом из Цюриха в аэропорт Пулково прибыла небольшая швейцарская делегация в составе профессоров ETH Zurich Никлауса Вирта и Юрга Гуткнехта. Так начиналось Большое турне Вирта по России. За три с небольшим недели он посетил ведущие университетские центры страны: С.-Петербург, Москву, Нижний Новгород, Екатеринбург, Новосибирск, Томск.

В 71 год пойти на столь изматывающую поездку в далёкую Россию — это надо иметь большое мужество. И понимать, во имя чего всё это делается. Европейская наука проиграла в жестокой схватке с американским бизнесом. И теперь потребуется немало усилий, чтобы осознать всю глубину падения и постараться выправить положение. Без России и стран бывшего Союза это сделать практически невозможно.

Cразу после возвращения Вирта из поездки по России и Польше, 20-21 октября 2005 г. в Цюрихе прошёл Европейский саммит по компьютерной науке (European Computer Science Summit), главным организатором которого стал преемник Н.Вирта на посту декана факультета информатики ETH Zurich, ученик А.П.Ершова, автор языка Eiffel, французский учёный Бертран Мейер.

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

Прямым итогом этих двух событий стало формирование в России научно-образовательного некоммерческого проекта Европейского центра программирования (EuroProg, European Programming Centre), который ставит своей целью создание влиятельного информационного и координирующего центра в сфере компьютерного программирования для стран европейского региона, прежде всего, Восточной Европы, включая Россию, Беларусь и Украину. Он создаётся на базе событийного сайта Oberon2005, подробно освещавшего Большое турне Вирта по России. Формирование ведётся при участии Высшей Политехнической школы ETH Zurich, Института компьютерных систем при ETH (Цюрих, Швейцария), а также Института систем информатики им. А.П.Ершова (Новосибирск, Россия).

Фактически строится новая модель сотрудничества университетских и исследовательских центров Европы с привлечением независимых профессиональных программистов и представителей программной индустрии. Строится модель, компенсирующая острую нехватку деятельности научно-исследовательских институтов и опытно-конструкторских бюро в сфере программирования. Как и при создании А.П.Ершовым знаменитого новосибирского центра на базе Академгородка, включавшего триаду “образование-наука-индустрия” (НГУ, ВЦ СО АН СССР, НФ ИТМиВТ), большая роль уделяется подбору и концентрации важнейших информационных материалов в рамках общедоступной открытой некоммерческой библиотеки (Open Digital Library). Другими составными элементами проекта станут Музей программирования, Открытая энциклопедия программирования, инструментальный репозитарий, а также научно-производственный центр, координирующий ведение проектов и НИОКР в рамках модели открытого исследовательского программирования (Open Research Programming), которая является альтернативой Open Source. Открытие Европейского центра программирования намечено на осень 2007 г.

Другим отголоском событий 2005 г. стало образование влиятельной некоммерческой и неправительственной организации Informatics Europe (первоначально под именем euroTICS), которая ставит своей целью объединить усилия образования, науки и индустрии Европы на основе европейских традиций информатики. Это традиционная форма ассоциации с центром в ETH Zurich, в которую уже вошли преимущественно университеты Западной и Восточной Европы, включая такие страны, как Швейцария, Франция, Германия, Австрия, Великобритания, Италия, Испания, Нидерланды, Дания, Россия, Украина, Болгария, Чехия, Румыния, Литва, Турция.

Европа существенно слабее Америки в отношении поддержки собственной индустрией академической науки и образования. Да, есть ряд крупнейших европейских компаний, которые так или иначе способны влиять на эти процессы: Airbus, Nokia, Ericsson, Philips, Thomson, Siemens, SAP AG и др. Но это влияние пока достаточно слабое.

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

Удары наносились, прежде всего, по инфраструктурным вещам:
1) языкам программирования;
2) железу;
3) кадрам (образование);
4) операционным системам.

Проф. Эдгар Дейкстра (Edsger Dijkstra, Нидерланды, 1930–2002), один из отцов-основателей программирования, так охарактеризовал ключевые события, которые привели к формированию однополярного мира и разрушению европейской культуры программирования: "Принятие в Германии Алгола-68 оказало парализующий эффект на немцев, подобный тому, которому подвергся Советский Союз, когда русские в конце 1960-х приняли решение разрабатывать свою новую национальную серию компьютеров на основе поразрядно-совместимой копии IBM 360. То была величайшая победа Америки в холодной войне".

Вкратце история противостояния Америки и Европы, на мой взгляд, выглядит так:

Алгол-60 — отправная точка размежевания школ программирования: американской и европейской (после совместных работ под эгидой IFIP Европа взяла на вооружение Алгол-60, Америка — Фортран);
клонирование IBM 360/370 в серии ЕС ЭВМ в СССР и странах СЭВ явилось гарантией технологического отставания советской супердержавы, сдерживавшей амбиции Америки;
затяжное принятие раздутого Алгол-68 – разящий удар по европейским языкам программирования;
вымывание европейских производителей компьютеров (ICL — Великобритания, Nixdorf, Siemens — Германия, Bull — Франция; ИТМиВТ — СССР).
падение роли IFIP, доминирующая роль американских ассоциаций ACM и IEEE CS;
гегемония американских стандартов высшего образования (ACM/IEEE Computing Curricula);
американизация культуры языков программирования (Бейсик, Кобол, Фортран, Си, C++, Java, C#);
американизация исследовательских и промышленных операционных систем (UNIX, DOS, Windows).

Примерно в течение 15 лет (1960–1975) центральной организацией, регулирующей процессы развития науки и индустрии в сфере компьютерного дела в мире являлась IFIP (International Federation for Information Processing, Международная федерация по обработке информации; штаб-квартира во Франции, теперь в Австрии). Она была организована на первом Всемирном компьютерном конгрессе (World Computer Congress) в Париже в 1959 г. под эгидой UNESCO.

Но IFIP была центром де-юре, а де-факто таковым стала американская ассоциация ACM (Association for Computing Machinery, 1947) вместе с примкнувшей к ней IEEE Computer Society (1946). Единственным противовесом им (в локальном масштабе) стало Британское компьютерное общество (BCS, British Computer Society, 1957).

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

Отличительные черты американской школы программирования:

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

Отличительные черты европейской школы программирования:

научные исследования — основа основ;
инженерные решения требуют продуманности и отказа от излишнего усложнения;
контролируемый рост сложности систем;
интенсивный рост (за счёт высокой культуры образования и разработки специального инструментария).

Одним из немногих, кто вовремя понял всю суть процесса деградации науки и культуры под звёздно-полосатым флагом глобализации применительно к компьютерной сфере, был голландский проф. математики, один из первых профессиональных программистов, апологет европейской школы Эдгар Дейкстра. Предметом исследований Дейкстры было именно программирование как интеллектуальный вызов, как процесс творчества и созидания, а не просто набор отдельных языков, приёмов или методов. В работе "Мои надежды на вычислительную науку" (1979, "My Hopes of Computing Science", EWD709) он писал: "Ассоциация ACM имеет специальную группу по языкам программирования (Special Interest Group on Programming Languages), но не по программированию как таковому; её новейшее периодическое издание посвящено языкам программирования и системам (Programming Languages and Systems), но не программированию. Программистское сообщество почти болезненно зациклено на программной нотации; оно делится по сути на такое же количество субкультур, каково число распространённых языков программирования; субкультур, ни одна из которых чётко не отделяет истинные проблемы от проблем, порождаемых исключительно соответствующим языком программирования (подчас превращаясь в религию)".

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

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

В работе "Два взгляда на программирование" (1975, "Two views of programming", EWD540) Дейкстра писал: "Я придерживаюсь того мнения, что программирование – один из наиболее сложных разделов прикладной математики, поскольку оно также является одним из наиболее сложных направлений инженерии, и наоборот. Когда я попытался разъяснить одному из моих коллег-математиков, почему я придерживаюсь этого мнения, он довольно бесцеремонно отказался выслушать мои доводы и вместо этого обвинил меня и моих единомышленников-компьютерщиков в том, что мы до сих пор не создали язык программирования, который сделал бы программирование настолько простым, насколько ему и подобает быть! Возможно, мне стоило бы спросить его, почему математики до сих пор не разработали нотацию, которая позволила бы любому, невзирая на отсутствие профессиональной подготовки, заниматься математикой?"

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

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

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

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

О том, к чему ведёт американизация культуры программирования, Э.Дейкстра весьма рельефно вскрыл в своей работе "Почему американская компьютерная наука кажется неизлечимой" (1995, "Why American Computing Science seems incurable", EWD1209). Он пишет: "По жестокой шутке истории, впрочем, американское общество выбрало именно двадцатое столетие для того, чтобы становиться всё более и более нематематическим (кстати, явление, рассмотренное Моррисом Клайном и вызвавшее у него глубочайшее сожаление). Мы достигли парадоксального состояния, когда из всех так называемых "развитых наций" именно США сильнее всех зависят от программируемых компьютеров и хуже всех интеллектуально оснащены в данном направлении. Предположение о том, что проблема программирования может быть вылечена математическими средствами, мгновенно отвергается как совершенно нереалистичная. В результате разработка программ ограждена от возможности стать поддисциплиной информатики. Имеет место значительная озабоченность корректностью, но она почти полностью направлена на верификацию программ a posteriori, потому что опять же это легче укладывается в мечту о полной автоматизации. Но, разумеется, многие рассматривают верификацию a posteriori как установку телеги впереди лошади, потому что процедура "сначала программирование, потом проверка" поднимает насущный вопрос, откуда берётся программа, подвергающаяся проверке. Если же она выведена, то верификация сводится к простой проверке вывода. А между тем методология программирования, переименованная в "программную инженерию", стала настоящим раем для гуру и знахарей. Будучи лишённой того, что обычно рассматривается как основное направление компьютерной науки, американская компьютерная наука стала большим неудачником. И мы не вправе винить за это университеты, поскольку, когда промышленность, наиболее нуждающаяся в их научной помощи, неспособна понять, что это высокотехнологичный бизнес, лучшие университеты оказываются бессильны. Университетам следует быть более просвещёнными, чем их окружение, и они способны на это, но не очень стараются это показывать. В нынешней политической ситуации непохоже, что можно ожидать быстрых улучшений; в ближайшем будущем нам придётся жить среди предрассудков, подобных тому, что программирование – это "настолько просто, что им могут заниматься даже члены республиканской партии".

А что вообще дала информатика как наука?

Небольшой экскурс в исторические достижения информатики как науки и своё видение первичной роли науки Эдгар Дейкстра дал в работе "Научная фантастика и научная реальность в информатике" (1986, "Science fiction and science reality in computing", EWD952). Он пишет: "Что же информатика делала в этой блистательной изоляции? Точнее говоря, что она делала, не теряя претензий на прикладную значимость? Да, сделала она немало; фактически, куда больше, чем я могу разъяснить в рамках данной лекции, но я могу хотя бы передать вам общие моменты. В 1960-е годы она разработала теорию синтаксического разбора, необходимую для поднятия уровня компиляторов выше уровня поделок, напичканных ошибками, и превратив её в предмет, пригодный для обучения. Это было главное достижение: я, например, помню весьма отчётливо, как в 1962 г. те из нас, кто действительно написал компилятор, выглядели в глазах остальных как некие полубоги. Этого никогда бы не произошло, если бы мы со временем не научились давать формальное определение синтаксиса компилируемого языка: без подобного формального определения слишком сложно было бы определить существование проблемы компиляции. Теория конечных автоматов и теория сложности были разработаны, чтобы задать основные количественные границы того, что в принципе может быть вычислено; опять же, в основе этих теорий лежит весьма формальный постулат о природе вычислений, постулат, без которого эти теории не могут существовать. Для разработки операционных систем была поставлена и решена проблема синхронизации процессов; были доказаны первые теоремы об отсутствии тупиков; первой предпосылкой этого достижения стало формальное определение явления, интуитивно известного как тупик (deadlock). В 1970-е годы центр внимания сместился от синтаксиса к семантике, сначала к детерминированным последовательным программам, а вскоре охватил также сферу недетерминированности и параллельности. Я не буду подробно описывать различные направления: они простираются от модели типизированного лямбда-исчисления до разработки преобразований программ с сохранением семантики. В этом десятилетии программы стали самостоятельными математическими объектами. Кратчайший способ уловить изменение направления внимания – это, пожалуй, отметить, что если раньше задачей программ было управлять поведением машины, то теперь ею стало выполнение наших программ. Верификация и разработка программ развились в разделы формальной математики до такой степени, что теперь уже не считается безответственным опубликовать программу, не испробовав её на компьютере. Что ж, это далеко не полный обзор того, как информатика стала наукой, и я приношу свои извинения всем неупомянутым мной, кто внёс свой вклад в её становление. Надеюсь, что он всё же достаточно полон, чтобы донести до вас аромат квинтэссенции самой дисциплины. Она стала замечательной дисциплиной, поскольку разделение между "чистой" и "прикладной", столь традиционное для многих других дисциплин, совершенно поблекло и существенно утратило своё значение. Роскошь работы в окружении, в котором различие между чистой и прикладной наукой лишено смысла, — это, пожалуй, ещё одно признание того факта, что компьютер общего назначения действительно заслуживает эпитета "общего назначения". Она обладает всей пикантностью чистой математики, будучи более формальной, чем многие другие отрасли математики. Она не может избежать такой формальности, поскольку любой язык программирования, будучи интерпретируемым механически, представляет своего рода формальную систему. В то же время она обладает всей прелестью прикладной математики, поскольку огромная мощность современных компьютеров даёт такие возможности для создания хаоса, что её методы необходимы, если мы не намерены попасться в ловушку сложности, которую сами же и создали. Научиться не попадаться в собственноручно произведённую ловушку сложности, сохранять вещи достаточно простыми и научиться достаточно эффективно мыслить о своих разработках — вот центральная задача информатики. Это также было осознано больше десятка лет назад, когда "разделение задач" стало находкой программной терминологии. Заметьте, пожалуйста, что путь, которым информатика пробивала свою нишу, был сам по себе примером успешного "разделения проблем". Каждый раз, когда мы вкладываем уйму умственной энергии в тщательную разработку любой дискретной системы, мы делаем это не просто для удовольствия: мы всегда надеемся, что результат наших усилий будет использован во благо другим. Мы надеемся, что он будет удовлетворять нужды, соответствовать ожиданиям и доставлять удовольствие своим пользователям. В донаучный период разработки систем неформальное понятие "удовлетворения пользователя" было единственным приемлемым критерием качества программного обеспечения. Недостаток "удовлетворения пользователя" как критерия качества состоит в том, что это не техническое понятие: он не задаёт технического направления разработчику и, кроме того, может быть достигнут другими средствами, помимо технических, например, агрессивной рекламой или промывкой мозгов. К науке это не имеет ни малейшего отношения. Задачи должны быть разделены, и тут на сцене появляются функциональные спецификации. Роль формальной функциональной спецификации – просто служить логическим барьером между двумя совершенно разными проблемами, известными как "проблема удовлетворённости" и "проблема корректности". Проблема удовлетворенности касается вопроса, соответствует ли система, отвечающая таким-то и таким-то формальным спецификациям, вашим ожиданиям и надеждам. Проблема корректности касается вопроса, соответствует ли данная разработка таким-то и таким-то формальным функциональным спецификациям. Логический барьер был необходим, чтобы поставить проблему корректности перед информатикой: он изолирует уютную нишу информатики от проблемы удовлетворенности, решению которой наука мало чем способна помочь. Заметьте, пожалуйста, что я не утверждаю, что одна из проблем важнее другой; в конце концов, цепь не прочнее самого слабого звена. Однако я утверждаю, что проблема корректности представляет ту самую часть, которую нам удалось втиснуть в "тонкий пограничный слой" Бонди, где разумное применение научной мысли может принести пользу, тогда как неформализованная проблема удовлетворенности в действительности лежит на пределами компетенции науки. У вас могут быть самые разные проблемы, начиная с опасного перекрёстка и заканчивая такими, которые угрожают самому существованию целых поколений. Однако наука никогда не решает ваши проблемы, она решает лишь свои собственные, и заключение о том, примете ли вы решение формальной научной проблемы как таковой в качестве приемлемого решения своей задачи, лежит целиком и полностью на вас. Другими словами, наука никогда не предлагает моделей реальности, она лишь строит свою теорию, и вопрос, примете ли вы своё восприятие действительности в качестве достаточно достоверной модели для этой теории, — полностью ваша проблема. Достоверность и реалистичность больше не являются научными понятиями, и учёный уступает право разглагольствования о них философам, пророкам и поэтам. С этой точки зрения роль науки довольно ограничена, на самом деле до такой неутешительной степени, что многие предпочитают закрывать глаза на ограниченность науки. Акцентировать внимание на этих ограничениях не принято в научной среде, поскольку помимо прочего это вызывает вопрос, а зачем тогда общество должно терпеть учёных. Это не шутка: все мы знаем, что если бы сегодня общество вдруг решило изгнать своих учёных, это было бы не в первый раз. И теперь, когда наука "вышла в народ", она также не столь популярна среди публики в целом. Люди всегда питали противоречивые чувства по отношению к технологии, и с чем более мощными технологиями они сталкиваются, тем драматичнее становится двойственность этого отношения. Они чувствуют угрозу со стороны технологии сильнее, чем когда-либо прежде; в то же время их надежда на спасительную мощь науки и технологии всё больше крепнет. В старые добрые временя традиционного шаманства требовались только снадобья от всех недугов, Эликсир для вечной юности и Философский Камень для сотворения золота".

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

RB23. О языках реализации в проекте новой ОС

2007-07-17T08:18:17Z

На каких языках программирования будет реализована новая ОС? Какие языки планируется поддерживать? Будет ли это моноязыковая система (как обычно принято в проектах проф. Вирта) или мультиязыковая? Будет ли взаимодействие языков напоминать подходы .NET или Eclipse?

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

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

Как уже говорилось, в проекте будут задействованы три важных аппарата — конечные автоматы (Finite State Automata), сети Петри (Petri Nets), нейронные сети (Neural Nets). Как они друг с другом соотносятся? Как известно, машина Тьюринга является основополагающей концепцией, фундаментом, на котором стоит здание современного компьютерного мира. С точки зрения выразительной мощности, конечные автоматы слабее машины Тьюринга и сетей Петри, при этом конкретное ограничение сетей Петри (т.н. автоматные сети) являются эквивалентом конечных автоматов. Иными словами, по выразительной мощности сети Петри занимают промежуточное положение между конечными автоматами и машиной Тьюринга (при введении т.н. сдерживающих дуг они эквивалентны машине Тьюринга). Хорошо известно, что чем более ограничена формальная модель, тем легче её анализировать. Т.е. по возможности лучше использовать менее мощный аппарат (более специализированный).

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

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

Фактически в языковом слое будет два уровня – формальных моделей и традиционных языков.

Слой традиционных языков будет предусматривать три направления:
1. императивное программирование (ИП)
2. функциональное программирование (ФП)
3. сценарное (скриптовое) программирование (СП)

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

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

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

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

1. Идея модулей появилась не у Дэвида Парнаса, а парой лет раньше — у Петера Наура. И назвал он модули "кластерами действий" (Peter Naur "Programming by action clusters". BIT, 1969, #9).

2. Идея кластеризации (термин хорошо известен в области обработки данных и в сфере "железа") приглянулась Барбаре Лисков (MIT) и она застолбила этот термин для своего языка абстрактных типов данных — CLU (1975). Собственно CLU есть "половинка" от CLUSTER. Кластер Барбары Лисков — это своего рода модуль (АТД-модуль), в котором инкапсулированы (связаны друг с дружкой) абстрактный тип данных (АТД) и операции над ним.

3. Если смотреть на модульное программирование с позиций проф. Вирта (модули Оберона и Модулы-2), то ощущается нехватка более объемлющей конструкции -- набора модулей (в Компонентном Паскале в роли таких наборов выступают каркасы-frameworks). Этот набор помимо того, что просто перечисляет относящиеся к нему модули (куст модулей, удобный для групповой загрузки-выгрузки-подмены), ещё и вводит определённые правила композиции (будем называть конфигурированием набора модулей). Вот почему возникла потребность в понятии, отличном от термина "модуль", но родственном ему по истории и по смыслу. Так возникла мысль использовать название программный "кластер" и ввести термин "кластерно-модульное программирование".

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

Идея компактного ортогонального языкового базиса исходит из исследовательских работ (МАИ и ВЦ СО АН СССР) по созданию системы "Модула-Лисп-Пролог" (середина-конец 1980-х), в которых мне довелось участовать на уровне проектирования и реализации связки Модула-Пролог (Пролог-M2), WAM-реализации Пролога (Warren Abstract Machine) и проектирования ран-тайма этой тройки языков.

Макетирование ОС будет вестись исключительно на рабочих языках с имитацией средств новых языков. И только после обкатки и готовности нового инструментария будет переписываться на новые языки (если в этом появится необходимость). Рабочими языками проекта, как уже ранее говорилось, будут Компонентный Паскаль и Оберон(-2). Рабочим инструментарием — BlackBox.

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