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

Источником компонентов должен быть репозиторий с полу-бинарными компонентами, то есть компонентами, скомпилированными в промежуточный код. При сборке приложения, компоненты должны до-оптимизироваться и до-компилироваться для конкретного процессора/среды исполнения. До-компиляция может быть ahead-of-time (тут тоже есть разные варианты) или just-in-time, думаю, что надо иметь возможность выбора. Естественно, что компоненты могут быть написаны на разных языках.

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

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

Что принципиально надо сделать для перехода от Вира к Виру-2?

• Перейти от репозитория с однопроцессорными, бинарными компонентами к репозиторию с полу-бинарным процессорно-независимым компонентам. Естественно, что для компиляции я буду использовать LLVM. На самом верхнем уровне здесь все понятно.

• Упростить подключение всего существующего софта к приложению на Вир-2, минимум, это легкое подключение динамических библиотек, а для этого, сделать над-языковый «язык» описания интерфейсов, скорее всего, основанный на LLVM. Не собираюсь связываться в начале с подключением ООП, то есть, по сути, сначала подключение всего, что есть на С.

• Сделать интеграцию с одной или несколькими стандартными IDE, в первую очередь с отладчиками и deployment tools. Скорее всего готовое приложение на Вир-2 должно представлять из себя набор DLL (SO) с верхушкой, написанной на чем-то естественном для целевой платформы. Пока думаю о Visual Studio.

• Сделать платформенно-независимую среду исполнения программ, позволяющую писать приложения, независимые от OS API и оборудования. Вот об этом надо говорить подробнее.

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

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

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

Что в Вире-2 должно быть принципиально новым, если говорить о среде исполнения?

Очевидно, что

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

То есть, мы изначально должны говорить не о наборе неких функций или модулей (POSIX, WIN32, NaCl Pepper), а о том, каким способом должен строится portable abstract layer или «переходник» между приложением и базовым слоем софта на устройстве.

Для меня очевидно, что переходник не должен быть монолитом, а должен собираться (автоматически) под каждое приложение с грануляцией на уровне функций. Некоторый функционал добавляется в переходник, если он нужен для работы хотя бы одной компоненты приложения.

Так же очевидно, что в переходнике должен быть

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

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

Впрочем, про переходник надо думать и писать отдельно.

Теперь существенный для меня вопрос: зачем я об этом пишу в открытом доступе?

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

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

Примерные этапы работы:

• Эксперимент по использованию SDL2 в программе на Вир. Сделано.

• Разработка языка А1 (ассемблер 1) и компилятора для замены того, что сейчас есть в Вире. Язык нужен, чтобы было немного удобнее программировать, чем на существующем А0 и чтобы учесть новые требования. А компилятор, точнее front-end нужно переписать, чтобы порождать LLVM IR. Итогом работы будет:
  • Компилятор, выдающий промежуточный код (LLVM IR)
  • До-компилятор, строящий код компоненты для конкретной платформы и отладочную информацию. Надеюсь использовать LLVM as is.
  • Сборщик, который «оформляет» код в нужный для платформы формат (например, DLL). Так же, надеюсь на

 В работе front-end и эксперименты по генерации IR. 

• Разработка переходника (сначала принципы, потом реализация для Windows). Замечу, что программы, сделанные на Вире, уже используют переходник (то есть не обращаются напрямую к OS API), но этот переходник не удовлетворяет требованиям переносимости и расширяемости. Итог:
  • программа под Windows работает с новым переходником

• Интеграция с Visual Studio (по крайней мере с отладчиком). Итог:
  • Более-менее привычная для людей среда разработки

• Работа над мульти-платформенным репозиторием

• Переход на вторую платформу (Android), включая до-генерацию, переходники, интеграцию и т.д.

По ходу работы, очевидно придется разбираться со всякими «вкусными» вещами, например:

1. Region-based/thread-based memory manager
2. Средства коллективной работы
3. Над-языковая спецификация интерфейсов (symfiles)
4. Развитие скриптового языка (зачатки есть в Вире) для связывания компонент.
5. И т.д.

Интенсивность работы будет существенно зависеть от нагрузки в других делах/проектах, но ведь тут главное начать: Тихо-тихо ползи, улитка…