| Начало заметки см. RB32-1.
Базовый язык-микроядро
Проф. Вирт, на мой взгляд, очень верно нащупал важное направление развития инструментария. В то время как все помчались насыщать языки всё новыми могучими средствами и переносить центр тяжести на графические среды, он понял, что идти надо в противоположном направлении. Вычленяя квинтэссенцию и вынося за рамки компетенции данного языка паразитную нагрузку. Это напоминает выделение в наборе команд процессора базового минимума, из которого строится остальное (RISC), напоминает идею микроядра ОС (в противовес моноядру), напоминает Форт-системы… Микроядро - это один из важных принципов создания программных и технических систем. Чтобы подчеркнуть эту аналогию, я решил использовать название "e;микроядро"e; в отношении как языка, так и ортогональной системы языков.
Оберон - это удачный вариант микроядерного языка традиционного императивного программирования, ориентированного на самую распространённую процессорную модель Эккерта-Неймана. Другим языком-микроядром можно назвать классический Си. Отличительной особенностью Оберона является сбалансированность языка, опирающаяся на принцип концептуальной экономии и внутреннюю ортогональность: механизм расширения типов (type extension), обобщение процедур (процедурные типы), концепция модуля.
Вообще говоря, число языков-ядер (не обязательно микроядер) существенно меньше общего числа языков, но тем не менее представляет возможности выбора с учётом исповедуемого ими понятийного пространства (так или иначе отражаемого в парадигмах языков). В дополнение к упомянутым Оберону и Си можно отметить классику (а не современные вариации): Лисп, Рефал, Пролог, Форт, Smalltalk, Паскаль, Occam.
Графические средства, ориентированные в большей степени на человека, очень полезны (особенно для общения людей между собой), но как только мы вспомним о том, что человеческий фактор является ахиллесовой пятой контроля сложности, то поймём, что чувство меры здесь должно превалировать над желанием облегчить труд. Мы нередко тем самым облегчаем труд создания новых сложностей. Автоматике нужны языки и совсем не графические. Графика (в широком смысле) - это просто удобная форма, позволяющая человеку на том или ином участке работы. Мы внимательно изучаем это направление прежде всего с точки зрения поддержки языков спецификаций и моделирования. Для каждого формального "e;графического"e; языка у нас будет соответствующий текстовый эквивалент. Мы изучаем самые разные варианты на сей счёт. Отечественные ДРАКОН(ы) для разработки программного обеспечения отечественного "e;Бурана"e; и других масштабных космических проектов - лишь один из изучаемых вариантов. Впрочем, история их создания весьма интересна и с ней стоит поближе познакомиться.
Но вернёмся к языку-микроядру, к языку-чемоданчику под названием Оберон. Каким бы замечательным и компактным ни был язык-чемоданчик, он не в силах адекватно решать все проблемы. И здесь не стоит впадать в крайность - обожествлять язык. Давайте смотреть правде в глаза: Вирт со своей командой из ETH Zurich во многом абстрагировались от проблемы коллективной работы многих десятков специалистов над одним проектом. Система Oberon (да и BlackBox, хоть и в меньшей степени) - это системы индивидуального программирования. "e;Эгоцентрические"e;. Не удивительно, что Вирт и его коллеги не заморачивались проблемами масштабирования разработки (а тем более, промышленной разработки). Сам язык Оберон (включая и его последующие диалекты), ушедший от приоритета интерфейса и полноценного разделения модуля на интерфейс и реализацию (как было в Modula-2), сделал шаг в направлении эгоцентризма. В результате процесс перевернулся с ног на голову: интерфейс стал результатом того, что разметили в реализации. Тогда как в распределённых коллективах (да ещё в тех задачах, которые делаются не под кальку) нужно жёсткое фиксирование интерфейсов (в первую очередь) и вариативность реализаций под тот же интерфейс (во вторую). Впрочем, внести соответствующие коррективы в тот же BlackBox не столь трудно.
Размышляя над проблемами неприятия Оберона мировым программистским сообществом (и как языка, и как системы, и как подхода), я пришёл к выводу, что не последнюю (если не решающую) роль в этом сыграл технологический изоляционизм, заложенный Виртом в идею индивидуального программирования (а также пресловутая моноязыковость). Т.е. для небольших групп исследователей, для программистов-одиночек - это полезный инструмент (позволяет быстро конструировать требуемую программу/систему), но для полноценного использования в коллективной разработке имеет много врождённых недостатков.
Поясню свою позицию. Меня удивляет, когда начинают возводить в абсолют инструмент и отвергать всё остальное. Зачем? Вопрос квалификации и умения грамотно оперировать разными инструментами (понимая их сильные и слабые стороны). Маргинальность, оторванность от масс произрастает из попытки навязать непременно своё (пусть самое лучшее), отвергая привычное. Это, на мой взгляд, тупиковый путь. Поясню и то, что понимаю под словом "e;эгоцентризм"e; в отношении Оберона: это попытка сделать Оберон центром мироздания. Вирт просто (ради научного интереса) облегчил себе жизнь (и решил задачу получения минимального, полезного, универсального языка весьма элегантно). Он облегчил жизнь и многим программистам-индивидуалам, особенно "e;непрофильным"e; (физикам, биологам, астрономам и т.п.). Но осложнил программистам, которые должны работать в большой команде на современном производстве ПО. Впрочем, он и не мог этим заниматься, поскольку надо знать соответствующие потребности и иметь немалое число разработчиков-исполнителей. Я рассматриваю Оберон вполне прагматично. Это хорошее приближение к идее языка-ядра (даже микроядра). А чем меньше "e;паразитных"e; связей, тем более устойчивее система. И тем дольше она проживёт в мире постоянных изменений.
Оберону нет смысла лезть туда, куда их просто никто не пустит - в "e;жирную"e; инфраструктуру, созданную Microsoft, Sun, IBM и др. Но это и не надо. Во-первых, он может её "e;нагло"e; пользовать. Во-вторых, он может применяться в качестве универсального чемоданчика с инструментами для программиста-индивидуала. В-третьих, он показывает себя во всём блеске там, где инфраструктуры нет (наш проект).
В своей известной работе "e;Долой жирные программы"e; (1986) проф. Вирт выделил несколько причин сложности: постоянный дефицит времени (спешка - худший советчик), наращивание функционала вместо его вдумчивого пересмотра и обобщения (при эволюционировании требований), монолитность программных конструкций. Последнее особенно важно в контексте идеи ортогональной системы языков. Вот что пишет Вирт: "e;Важная причина, ответственная за программную сложность, лежит в "e;монолитном"e; дизайне, когда все мыслимые возможности сразу закладываются в систему. Каждый потребитель платит за все возможности, но реально использует лишь немногие из них. В идеале же, должна предлагаться только базовая система с заложенными в неё существенными возможностями, но эта система должна иметь потенциал для различных расширений. Тогда каждый потребитель мог бы выбирать функции, действительно необходимые для его задачи"e;.
Эти слова следует распространять и на инструментарий (языки), и на саму ОС. Нужен наращиваемый базис. При этом сам базис должен быть тщательно продуман и сбалансирован. Это лежит в русле идеи настраиваемых (конфигурируемых, адаптируемых) сущностей и систем.
Но Оберон - не панацея (для программирования в целом). Потому после многих лет исследований разных языков (включая реализацию в 1980-х годах языковой системы "e;Модула-Пролог"e; с примкнувшим к ним Лиспом) я пришёл к идее ортогонального базиса языков (сбалансированный набор взаимодополняющих, минимально пересекающихся в понятийном пространстве - языки-ядра разных парадигм). Нельзя сказать, что ортогональность как внутри языка (по концепциям и средствам), так и между языками - откровение в программировании. В той или иной мере этот принцип использовали ранее. Но в том виде и контексте, как это задумано для нашего проекта, - подход весьма нешаблонный. Просто идея ортогональности, воплощённая Виртом в одном языке (внутренняя ортогональность и сбалансированность классического Оберона), развивается в сторону языков-ядер (внешняя ортогональность и сбалансированность системы языков). Развивается в понимании того, что синтаксис - не просто внешняя форма, во многом он связан с семантикой, и только в такой органичности может давать существенный выигрыш в процессе программирования. Иными словами, не надо парадигмы и разнообразные конструкции языков затаскивать в один синтаксис. Это прокрустово ложе. Оно отсечёт немало ценного и полезного. При этом желательно иметь чувство меры. Если создаются новые диалекты известных языков, которые планируется объединять в устойчивые языковые системы, то по возможности нужно нивелировать синтаксические расхождения. Хотя это тонкая, непростая работа.
Понятие ортогональности
В контексте вопросов, поднятых в этой заметке, хотел бы обратить внимание читателя на одну статью 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.
Обратимся к его статье. Она называется "e;Неудачные инженерные качества ОО-языков"e; ("e;Bad Engineering Properties of Object-Oriented Languages"e; // ACM Computing Surveys, December 1996). Статья написана через 15 лет после шумной рекламной кампании Smalltalk, в эпоху доминирования C++ в этой сфере и на фоне едва народившейся Java, создавшей основу для разработки C#. На фоне примерно 5-летней практики не известных широкой общественности, родственных языков Eiffel (1986), Оберон (1988) и Modula-3 (1988).
Карделли пишет: "e;Парадигма объектно-ориентированного программирования (ООП) вышла из эпохи 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 (сколь трудно изучить и использовать язык).
Карделли отмечает: "e;Языки, ориентированные на прототипы (Prototype-based languages), уже пытаются уменьшить сложность языков, ориентированных на классы (Class-based languages), путём предоставления более простых, более композиционно удобных средств. Даже в рамках ориентированных на классы языков мы теперь имеем лучшее понимание того, как достичь простоты и ортогональности, но многое ещё остается сделать"e;.
Карделли в своей статье высказал важную мысль: "e;Ортогональность средств языка уменьшает сложность языков программирования"e;. Мысль, которую давно осознал проф. Вирт, продемонстрировавший миру практическое её воплощение.
Небольшой терминологический комментарий. Важно делать различия между обобщающим понятием объектоцентрического языка (object-based language, где объекты просто поддерживаются на уровне сущностей языка) и уточняющими понятиями классоцентрического языка (class-based language, где каждый объект должен быть отнесен к определенному классу) и объектно-ориентированного языка (object-oriented language, где к иерархии классов добавляется наследование). Группа языков, ориентированных на механизм делегирования (Delegation-based languages), включает в себя и языки, ориентированные на прототипы (Prototype-based languages). Прототип рассматривается как объект, который одновременно является экземпляром и шаблоном. Детально это изложено в статье 20-летней давности "e;Dimensions of Object-Based Language Design"e; // OOPSLA'87, написанной Питером Вегнером (Peter Wegner), профессором университета Брауна (Brown University, США).
Наряду с этим Вегнер дает определения понятиям "e;согласованность"e; (consistency) и "e;ортогональность"e; (orthogonality) в отношении языка программирования (я это называю внутренней согласованностью и внутренней ортогональностью).
Согласованность. Набор языковых средств является согласованным, если они могут сосуществовать, т.е. если существует "e;язык-модель"e;, который реализует эти средства.
Ортогональность. Набор языковых средств является ортогональным (независимым), если для каждого подмножества средств существует язык, который обладает этим подмножеством и не имеет средств в дополняющем подмножестве.
Вегнер пишет: "e;Объекты, классы и наследование далеки от ортогональности. Классы определяются через объекты, а наследование, в свою очередь, через классы..."e; Очевидно, что подобные понятия согласованности и ортогональности можно распространить на интегрированные наборы/системы языков и говорить, в частности, о внешней ортогональности (в системе интегрированных языков).
Архитектура ортогональной системы языков
Вернёмся к обсуждению нашей ортогональной системы языков. Важный социальный аспект этой идеи: интеграция разноплановых языков-ядер (основанных на классике) позволяет сплотить программистов, а не содействовать их размежеванию, как это сплошь и рядом происходит в случае "e;силового продавливания"e; раздутых универсальных мультипарадигматичных языков. В программировании к вопросам веры (а выбор языка и следование ему - во многом сродни религии) стоит подходить деликатно. И не пытаться причесать всех под одну гребёнку.
Надо отметить, что предпосылки к подобной ортогональной схеме были заложены как минимум 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 лет), нынешняя популярность этих языков, наличие понятных спецификаций и открытых реализаций). Компромисс реализуется через принцип "e;базис-надстройка"e;.
На одном из интернет-форумов я уже в шутку говорил, что "e;Роса"e; - это будущий кровопивец с милым и ласковым названием. Он присосётся к армии Си и UNIX-разработчиков (к Linux), к Java-сообществу, к Haskell-сообществу, к Python-сообществу. Подтянет их к себе (новое - это всегда интересно и приковывает внимание). При этом даст им в руки действительно новый инструмент. Весьма и весьма полезный. Технологичный, открытый, бесплатный, без ограничений на коммерческое использование... Для каждого из этих миров появится масштабируемая перенацеливаемая ОС, которая фактически предложит солидную, продуманную подпорку их ран-таймов. Через них пойдут на общих основаниях и остальные языки.
Попутно будет заметно улучшен инструментарий BlackBox (поскольку станет основой для макетирования нашей ОС и трамплином для запуска базиса). Т.е. его модернизация (или даже кардинальная переработка) будет практически востребована масштабным проектом.
Открытая разработка в течение длительного времени позволит создать хорошие подъездные пути к новой ОС и подготовить будущих разработчиков приложений для "e;Росы"e; к такому переходу. Для языков ортогонального базиса будет создан инструментарий нового поколения, более сильный, нежели существующие в индустрии сегодня. С возможностями использования приложениями "e;бортовых"e; микро-ОС (как в случае BlackBox). Мы будем некоторое время сохранять альтернативу Лисп-Рефал, хотя всё идет к тому, что в нашем ортогональном базисе из этих двух кандидатов будет в итоге выбран именно Рефал.
UNIX-программисты заполучат уникальные средства мультипрограммирования и компонентного программирования, которые они до этого не имели. Как известно, всё познается в сравнении. И новое - особенно. Выделенные в мэйнстриме технологические зоны прорыва (UNIX, Си, Haskell, Python) помогут встать новой ОС и её инструментарию на ноги. А потом - путем мягкой миграции (совмещения старого и нового) - заполучить много новой крови для своего развития.
Поясню планируемую структуру ортогональной системы языков в "e;Росе"e;.
Ортогональный базис (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. Сам. Может попросить коллегу. Если сущности (в разных гранях) можно разнести по отдельным языкам (напр., нижнего, среднего и верхнего уровня), то "e;протаивание"e; сущностей с новыми отношениями (операциями) над ними в другом понятийном пространстве позволит добиться герметичности (по надёжности и контролю сложности), которая сродни герметичности отсеков подводной лодки. Здесь нужно иметь чувство меры. Один язык, в который впихивается всё - это крайность (опять же учитывая разделение труда в промышленном производстве ПО). Разбиение на множество языков - это введение соответствующего числа понятийных уровней. В нашем случае пока видится оптимальным вариант из трёх уровней - "e;железячный"e; (M), алгоритмический (R) и архитектурный (Metasys), со скрытым уровнем настройки на "e;железо"e; (F). Язык Metasys во многом служит основой интеграции и прокладывает мостик к композиции с сущностями других языков.
При импорте сущностей источник импорта из другого языка будет префиксироваться именем соответствующего языка реализации. Обработка исключений (с учетом её косвенной формы через настраиваемое поведение ASSERT-инвариантов) будет фундаментом всех языков ортогонального базиса.
На системном уровне будет задействована пара "e;Оберон-Рефал"e; (наши диалекты этих языков). При этом Рефал будет нести на первых порах минимальную нагрузку - он понадобится для различных сценарных вещей и высокоуровневых (мета)манипуляций. Несмотря на всю свою простоту его реализация таит массу подводных камней (по эффективности и тюнингу движка). Рефал рассматривается нами как альтернатива Лиспу (и Прологу). Кроме того, хорошо зарекомендовавшая себя технологически схема "e;Ада-Лисп"e;, используемая в NASA и в Минобороне США, очевидно имеет у нас иное, микропредставление - "e;Оберон-Рефал"e;. По Рефалу надо понимать, что многие задачи можно на нём решать, имея в виду возможность почти мгновенного расширения языка за счёт встроенных функций, реализованных на Обероне (M+R).
Синтаксис языков. Вводится модель вариативного синтаксиса. Для M и R, в частности, поддерживаются как равноправные Паскаль-подобный синтаксис (Модула-2, Оберон) и Си-подобный синтаксис. Автоматически (нажав конпку) можно переключиться из одного представления синтаксиса в другое. В отношении зарезервированных слов/идентификаторов поддерживаются два варианта: верхний регистр (MODULE) или нижний регистр (module). Допускается смешение в одном модуле разных режимов выделения зарезервированных слов (будут выделяться за счет настройки среды программирования). Альтернативные формы синтаксиса смешиваться в одном модуле не могут.
Синтаксис языка T (назван в честь Турчина, автора Рефала) будет переработкой синтаксиса Рефала. Семантика в основе своей будет сохранена. Язык S по семантике будет близок Smalltalk, но синтаксис планируется вариативный.
Оперирование сущностями этих языков будет осуществляться через единую основу модулей и кластеров (супермодулей), которая подразумевает раздельную компиляцию (и наличие отчуждаемых интерфейса и реализации). Оперирование (композиция отношений) возлагается на наш новый архитектурный язык Metasys.
Следующий ортогональный уровень (надстройка): Haskell, Java, Python. Он также приводится к единой основе (кластерам). Оперирование композицией экспортируемых сущностей - через Metasys. Metasys будет отвечать и за высокоуровневую хинтовку параллельного (асинхронного) программирования, а также за контроль инвариантов и протоколов, фиксируемых на уровне интерфейсов.
При проработке описания параллелизма/асинхронности учитывается опыт языков БАРС и ПОЛЯР из проекта МАРС (Модульные асинхронные развиваемые системы, 1985-1988, ВЦ СО АН СССР, ВЦ АН СССР, Институт кибернетики Эстонской ССР, НПО "e;Импульс"e;) и используемый там механизм управляющих сетей (модификация сетей Петри).
Таким образом, распределение языков по уровням ОС видится примерно таким:
Микроядро: M
Ядро: M, R, Metasys
Сервисный уровень: M, R, S, T, Metasys
Прикладной уровень: R, S, T, Java, Haskell, Python, Metasys.
Новый язык R (преемник классического Оберона) намеренно идёт по пути ужесточения ограничений, по пути повышенной надёжности, герметизации.
Важная особенность - все языки-ядра ортогонального базиса (M, R, T, S) имеют технологическую независимость от внешних лиц и организаций. Они будут находиться полностью под нашим контролем. Это наши языки (диалекты) и наши реализации. При этом переход на них с языков-оригиналов достаточно прост (близки и по синтаксису, и по семантике), возможна и реализация соответствующих миграционных конверторов. Мы минимизируем риски. Критериями модификаций исходных языков будет устранение "e;заусенцев"e;, избыточных при интеграции в ортогональном базисе, а также выделение интерфейсных (общих базовых) сущностей (в контексте экспорта-импорта).
Развитие языков прикладного ортогонального уровня (Haskell, Java, Python - где степень ортогональности много слабее базовой четвёрки) находится вне нашей компетенции. А потому мы будем брать под контроль мониторинг их эталонных открытых реализаций, синхронизацию публичных релизов с нашей реализацией. Будем вырабатывать механизм быстрого погружения нового релиза в нашу ортогональную систему.
Каждый прикладной язык этой тройки будет снабжен охватывающей сущностью высшего уровня (программным кластером). Безопасность их работы будет обеспечиваться виртуализирующим слоем. Он имеет как вариант трансляции исполняемого кода в набор команд виртуального процессора (саркофаг), так и перенацеливаемую форму представления (не обязательно схема семантического словаря Михаэля Франца), которая может на лету конкретизироваться под целевой процессор (включая виртуальный). При этом перенацеливаемая форма может статически анализироваться на предмет безопасности выполняемых действий. Аналогичные шаги будут предприняты в отношении языка Си, который будет обеспечивать POSIX-шлюз совместимости с UNIX.
Если программисту нужны свои любимые языки (как-то C++, C#, Ada и др.) - вполне вероятно, что со временем они появятся в "e;Росе"e;. Просто наша группа ими заниматься не планирует по целому ряду причин. У нас два уровня языков - свой (M, R, S, T, F, Metasys) и для массового разработчика (Java, Haskell, Python, Си).
Наша позиция в смысле контроля сложности достаточно ясная: идти в направлении, указанном проф. Виртом, но быть до конца последовательными. Выделять языки-ядра, которые чётко очерчивают понятийный уровень. Герметизировать их с возможностью интеграции в устойчивую сбалансированную ортогональную систему языков.
На этапе макетирования новой ОС мы планируем параллельно прорабатывать и реализовывать новые языки (2-3 года) и писать на Компонентном Паскале в среде BlackBox (диалект Оберона, адаптация в направлении Java) с учётом продвижения по линии новых языков. Подробная информация об инструментальной системе BlackBox представлена в центре компетенции BlackBox в России (компания "e;Метасистемы"e;, г.Орёл) - http://www.oberoncore.ru/ С имитацией языка M на стадии макета успешно справится XDS Modula-2 новосибирской компании Excelsior, созданной участниками проекта МАРС. Эта система программирования оттачивалась для заказных работ с крупнейшими телекоммуникационными компаниями мира и в ходе реализации отечественного проекта СОКРАТ, результаты которого многие годы успешно применяются в НПО Прикладной Механики им.М.Ф.Решетнева, для разработки бортового программного обеспечения российских спутников связи (система Глонасс).
|
