| На каких языках программирования будет реализована новая ОС? Какие языки планируется поддерживать? Будет ли это моноязыковая система (как обычно принято в проектах проф. Вирта) или мультиязыковая? Будет ли взаимодействие языков напоминать подходы .NET или Eclipse?
Прежде всего, хотел бы обратить внимание на существенную особенность проекта – активное использования математического аппарата. За счёт этого роль языков реализации несколько изменяется. Можно вычленять определённые аспекты решения, выносить это на уровень формальных моделей, заниматься тщательным анализом и получением оптимального решения в рамках математического аппарата, после чего преобразовывать в вид, необходимый для исполнения ("e;протаивать"e; модель). И неважно – будет ли это некий код для абстрактной машины или же исходный текст для традиционных языков программирования.
Роль "e;картриджей данных"e;, в которых будет заключаться квинтэссенция формальных моделей, будет сильно повышаться. Их использование позволяет добиться более высокого качества, получить невероятную компактность с высоким уровнем надёжности решения (верификация, уверенность в правильности кода). Это приводит к новой профессии (проектной роли) – аналитика формальных моделей.
Как уже говорилось, в проекте будут задействованы три важных аппарата — конечные автоматы (Finite State Automata), сети Петри (Petri Nets), нейронные сети (Neural Nets). Как они друг с другом соотносятся? Как известно, машина Тьюринга является основополагающей концепцией, фундаментом, на котором стоит здание современного компьютерного мира. С точки зрения выразительной мощности, конечные автоматы слабее машины Тьюринга и сетей Петри, при этом конкретное ограничение сетей Петри (т.н. автоматные сети) являются эквивалентом конечных автоматов. Иными словами, по выразительной мощности сети Петри занимают промежуточное положение между конечными автоматами и машиной Тьюринга (при введении т.н. сдерживающих дуг они эквивалентны машине Тьюринга). Хорошо известно, что чем более ограничена формальная модель, тем легче её анализировать. Т.е. по возможности лучше использовать менее мощный аппарат (более специализированный).
Если пояснять совсем неформально, то конечные автоматы оперируют понятием состояния (системы, конкретного ее элемента) и законами перехода из состояния в состояние при том или ином воздействии (изменении условия). При этом состояние у них – суммарное, сводное. И если допущена ошибка проектирования (не учтены все состояния на данном уровне), то требуется полностью переделать автомат (продумать новые сводные условия и законы перехода). В сетях Петри гибкость выше. Там состояние (системы, элемента) – это вектор разметки (совокупность условий, в частном случае – да/нет). Если что-то не учли, можно поправить топологию сети (добавить позицию и изменить разметку). В сетях Петри есть активные элементы (переходы, изменяющие разметку-состояния) и пассивные элементы (позиции, хранящие разметку). Напрямую элементы одной категории не могут соединяться дугами. По сути это двудольный граф (в одной доли - переходы, в другой – позиции). Т.е. при прочих равных условиях сети Петри – это "e;народные тропы"e;, а конечные автоматы – полноценные автобаны.
Нейронные сети в нашем проекте играют роль формирования приближённых решения в рамках заданной оптимальности. Тут не существенна возможная ошибка – решение всё равно будет верным. Но сколь оптимально – этот тюнинг и поможет осуществить именно аппарат нейронных сетей. Сети допускают получение оптимальности в ходе "e;научения"e;, накапливания информации об условиях и режимах того или иного объекта. В какой-то мере это напоминает оптимизацию исполняемого программного кода на основе многочисленных запусков и автоматического анализа узких мест (инкрементальная оптимизация).
Фактически в языковом слое будет два уровня – формальных моделей и традиционных языков.
Слой традиционных языков будет предусматривать три направления:
1. императивное программирование (ИП)
2. функциональное программирование (ФП)
3. сценарное (скриптовое) программирование (СП)
Соответственно, планируется реализовывать системы программирования (как минимум, по одной) для каждого направления, при этом предусматривается тесное межъязыковое взаимодействие внутри этой среды. ФП-слой будет работать поверх ИП-слоя. Связующий СП-слой будет работать поверх ИП-слоя и ФП-слоя (напоминает матрёшку).
Для поддержки более высокоуровневых концепций, отвечающих за работу на уровне архитектуры (т.н. супермодули, программные кластеры) и обеспечение асинхронности, планируется специальный язык, близкий к идеям кластерно-модульного программирования. Для ФП и СП будут выбираться по одному существующему языку с таким прицелом, чтобы они могли полноценно закрыть направление, минимизировали затраты по переносу в нашу среду и позволяли обеспечить технологическую независимость на будущее (исходя из нашего развития данного языка, которое так или иначе будет синхронизироваться с оригиналом). Кроме того, важным условием будет ортогональность языков (их взаимодополнение).
Модули. Модульное программирование будет играть важнейшую роль в проектировании и реализации проекта. Многие проблемы современных ОС идут от непонимания сути этой парадигмы, от её утрированного толкования мэйнстримом.
В основе архитектурных решений нашего проекта и их реализации будут лежать принципы кластерно-модульного программирования (идея супермодулей, в определённом смысле всплывала у Бертрана Мейера). Небольшое замечание относительно термина "e;кластерно-модульное программирование"e;.
1. Идея модулей появилась не у Дэвида Парнаса, а парой лет раньше — у Петера Наура. И назвал он модули "e;кластерами действий"e; (Peter Naur "e;Programming by action clusters"e;. BIT, 1969, #9).
2. Идея кластеризации (термин хорошо известен в области обработки данных и в сфере "e;железа"e;) приглянулась Барбаре Лисков (MIT) и она застолбила этот термин для своего языка абстрактных типов данных — CLU (1975). Собственно CLU есть "e;половинка"e; от CLUSTER. Кластер Барбары Лисков — это своего рода модуль (АТД-модуль), в котором инкапсулированы (связаны друг с дружкой) абстрактный тип данных (АТД) и операции над ним.
3. Если смотреть на модульное программирование с позиций проф. Вирта (модули Оберона и Модулы-2), то ощущается нехватка более объемлющей конструкции -- набора модулей (в Компонентном Паскале в роли таких наборов выступают каркасы-frameworks). Этот набор помимо того, что просто перечисляет относящиеся к нему модули (куст модулей, удобный для групповой загрузки-выгрузки-подмены), ещё и вводит определённые правила композиции (будем называть конфигурированием набора модулей). Вот почему возникла потребность в понятии, отличном от термина "e;модуль"e;, но родственном ему по истории и по смыслу. Так возникла мысль использовать название программный "e;кластер"e; и ввести термин "e;кластерно-модульное программирование"e;.
Ортогональный базис. Еще одна важная идея, которая так или иначе проглядывалась в проектах ETH Zurich, а в нашем проекте получит несколько иное развитие. Система поддержки языков (ран-тайм) будет интегрирована с ядром. Принципиальная разница состоит в том, что у нас будет не моноязыковая система, а мультиязыковая, при этом число привилегированных языков будет лимитировано (пока видится 3 базовых и один уровня супермодулей). Ран-тайм будет разрабатываться под наиболее эффективное взаимодействие этого базиса ортогональных языков, покрывающих основные парадигмы. Соответственно в ран-тайм просочится и поддержка примитивов формальных моделей (мат.фундамент).
Идея компактного ортогонального языкового базиса исходит из исследовательских работ (МАИ и ВЦ СО АН СССР) по созданию системы "e;Модула-Лисп-Пролог"e; (середина-конец 1980-х), в которых мне довелось участовать на уровне проектирования и реализации связки Модула-Пролог (Пролог-M2), WAM-реализации Пролога (Warren Abstract Machine) и проектирования ран-тайма этой тройки языков.
Макетирование ОС будет вестись исключительно на рабочих языках с имитацией средств новых языков. И только после обкатки и готовности нового инструментария будет переписываться на новые языки (если в этом появится необходимость). Рабочими языками проекта, как уже ранее говорилось, будут Компонентный Паскаль и Оберон(-2). Рабочим инструментарием — BlackBox.
Что будет с другими языками? Их перенос в новую ОС – задача много менее приоритетная, нежели построение триады базовых языков. Если понадобится расширять номенклатуру языков, новые языки пойдут уже на общих основаниях и без тех привилегий, которые имеют базовые.
|
