Компонентный ассемблер для цифрового пространства. Часть 1

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

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

В то же время, единое программное цифровое пространство не существует. Существует несколько экосистем, слабо связанных друг с другом. Разработка внутри одной экосистемы (iOS, Android, Java, …) существенно проще, чем разработка, затрагивающая несколько экосистем. Замечу, что границы между экосистемами искусственно выстроенные, их могло не быть, так как использованное оборудование, в сущности, универсально.

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

Возьмем простой пример. Язык Go [1], по многим характеристикам, является вполне подходящим для создания частей цифрового пространства. Особенно, если обратить внимание на подход к OOP (интерфейсы, отсутствие наследования и утиная типизация). Но, одновременно, в Go постулируется, что это язык для разработки (монолитных, статически линкованных) программ, что странно: шаг вперед, два шага назад.

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

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

Нужен ли нам вообще язык программирования для поддержки программирования межкомпонентного взаимодействия? Или нужна, скорее, некая надстройка, типа IDL (Interface Definition Language) вместе с обеспечивающими взаимодействие инструментами?

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

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

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