Го, я создал

Меня много лет не отпускало желание создать некую платформу, но всегда находились причины не делать этого. Начал я эту платформу в 1995, но российский кризис 1998 года заставил меня поставить это дело на паузу. Платформа была инновационная, одной из инноваций, например, был Object-Relational Mapping. Что бы вы понимали: Hibernate — это, наверное, самый известный и старый OR-mapper, появился в 2001 (initial release). Да и после появления Hibernate прошел примерно десяток лет прежде чем фраза OR-mapping перестала требовать разъяснений в общении с рандомным программистом.

В 1995 это было тру-инновационно, и о том, как на самом деле называется то, что я делаю, я узнал из эссе Scott Ambler через пару лет. Сейчас в 2020, эти статьи до сих пор на месте, а тогда информации в интерете толком не было, как и не было Google, короче вообще хрен что найдешь :). Это был тот год, когда появилась Java, как средство для программирования так называемых applets (это такие штуки в web браузере, которые уже вроде бы не существуют). Про Java на сервере тогда никто не помышлял, Sun рассказывал что она будет работать не только в браузере, но и в утюгах. Получилось все наоборот 😀. Ах да, еще Windows 95. Платформа, кстати, сразу писалась под Windows 95.

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

Соответственно, в мире, где за месяц можно стать “программистом” с нуля и пойти зарабатывать деньги, победил ассоциативный массив aka мапа (читай JavaScript object) и REST. Справедливости ради отмечу , что странные сложные вещи опять начинают проявляться в мейнстриме, типа Kubernetes, но насколько я понимаю текущий тренд, индустрия в этот раз решила схитрить и сказала, что это все для неких DevOps, которые вроде как наполовину админы и эти сложности — их админские проблемы. Программистам же эти сложности не нужны и им оставили ассоциативный массив: JavaScript object, REST и МоngoDb, которая четко уловила тренд забрать у программистов все, что сложнее мапы. Ну те же транзакции…

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

Платформа

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

Сложно в двух словах объяснить что такое Платформа. Самые хитрые скажут: “ага, не можешь просто объяснить, значит сам не понимаешь”. Отвечу, могу: легко и в нескольких словах, но для этого у нас должен быть общий дискурс. Проще говоря один словарик. Если я говорю платформа (с маленькой буквы), то что это значит? Если говорю “деньги”…, “транзакция”…, “ценность”…, “стоимость”…, “время” наконец? Мы должны одинаково понимать эти слова. Можем ли мы дать им максимально четкое определение?

Если такой вроде бы простой вопрос “что такое деньги?”, кому то кажется глупым, то нет — это вполне валидный и важный для основ платформы вопрос. (Ну а если кому то интересен ответ, то рекомендую вот эту книгу: The Bitcoin Standard, неважно как вы относитесь к криптовалютам, 90% книги про суть денег: золота, стеклянных шариков, баксов, биткоинов — какую бы форму деньги не приобретали).

Что значит термин “платформа”. Многие программисты часто не задумываются о значениях этих слов. Ну платформа и платформа, не делая особых различий между платформой (platform), фреймворком (framework), или библиотекой (library). Дискуссий на тему отличий фреймворка от библиотеки было немало, и по этому вопросу всем все вроде понятно, но я повторюсь.

Библиотека — это кусок кода который вы пользуете, как хотите. Фреймворк — это некоторая среда, в которой исполняется ваш код. Фреймворк, накладывает ограничения на ваш код: предоставляет контракты которым вы должны следовать, и тому подобное. То есть вы не можете писать “как вам хочется”, вам надо следовать этим правилам и контрактам.

Границы, естественно не четкие, например какая нибудь библиотека по синтаксическому разбору кода, может просить вас реализовать Visitor с которым она будет иметь отношения в процессе работы. С точки зрения кода визитера, эта библиотека — фреймворк. То есть мы пишем код в соответствии с контрактом, и наш визитор крутится “внутри” процессов синтаксического разбора. С точки зрения же нашего основного приложения, код этого парсера — библиотека, которую мы пользуем для синтаксического разбора.

Мне кажется вернее смотреть на эту историю с точки зрения Control Flow/Inversion of Control (IoC). Если у нас “нормальный” control-flow, ну то есть вы дергаете код, то этот код — библиотека. Если дергают вас, то этим занимается фреймворк. Я специально взял слово “нормальный” в кавычки, поскольку для меня лично с 2002 года — с первого приложения на Eclipse Platform, которое я написал, нормальный control-flow это как раз IoC 😀

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

Простой пример — драйвера операционной системы. Код Adobe Photoshop в конечном счете дергает код написанный NVIDIA, не зная о том как запаривалась NVIDIA при разработке драйвера. (Я безусловно уверен что Abobe и NVIDIA знают о существовании друг друга, но если бы не знали, ничего бы не изменилось и все в целом работало). Более того, на конкретной машине код Adobe не будет работать без кода NVidia, а их код не будет иметь смысла без вендоров типа Adobe.

Для чего и зачем

По духу и по сути самым близким аналогом того, что я хочу построить является Eclipse Platform. И я, конечно же, не говорю о средствах разработки.

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

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

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

Приведу пример: Eclipse Platform 2.x, предполагала, что пользователь — разработчик ПО. Соответсвенно Eclipse Platform 2.x включала в себя код для создания средств разработки, редакторов кода, управления проектом, интеграцией с системой контроля версии, и прочее. Кроме того она предоставляла минимум, необходимый для разработки на любом языке — текстовый редактор (конечно, без подсветки синтаксиса, но все же), интеграцию с CVS (да да, git еще не существовал, а SVN был всегда унылым глючным и бессмысленным куском говна, вечной бетой).

Eclipse Platform 2.x из коробки — это среда программирования для всего, и одновременно для ничего (чтобы получить среду для программирования например на Java, надо инсталировать соответствующие плагины). С версии 3.x ребята абсолютно разумно решили что пользователем платформы может быть не только программист, а виртуально любой пользователь десктопа, втыкающий в какое то десктопное приложение.

Так в версии 3.x появилась Eclipse Rich Client Platform (RCP). Это тоже, безусловно, платформа, нацеленная на создание десктоп приложений (любых). Eclipse RCP, вообще ничего не предоставляла из коробки, ну то есть конечный пользователь вообще не мог решить никакой задачи с помощью этой платформы, она целиком для программистов, которые хотят создавать десктопные приложения, пользуясь всеми возможностями предоставляемыми Eclipse RCP.

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

Естественно в любой платформе границы условны. Тот же Eclipse RCP и Eclipse Platform поверх Eclipse RCP — это про терминологию. В реальности существует лишь функционал поверх существующего, решающий более частную задачу. Например: Text Editor <- Code Editor <- Java Code Editor. Какой срез всего существующего функционала я назову платформой, вопрос не технический.

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

К сути

Как я писал выше, любая платформа — это многослойная история. И у каждого слоя есть свой спектр пользователей. В основе всего лежит некая архитектура плагинов и расширений, позволяющий платформе, и продуктам на ее базе, безгранично развиваться. На самом базовом уровне, я хочу платформу для создания веб приложений. Это примерно слой который предоставляет Meteor, AWS Amplify и еще, я уверен, множество проектов. Но эта цель требует важных уточнений.

Логичный вопрос здесь: почему новая платформа, а не Meteor и так далее? Смотрим вебсайт Meteor и видим что они себя позиционируют как:

The most efficient way to build Javascript apps. Meteor is a mature, open source Javascript framework used by over half a million developers around the world to build responsive web, desktop and mobile apps more efficiently.

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

The most efficient way to build Javascript apps. Да, я бы хотел чтобы Платформа была самым эффективным решением для создания приложений, но класс таких приложений несколько отличается от Meteor.

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

Одна из целей Платформы — эффективное создание Web приложений, но слово JavaScript в эту цель не входит. Забегая вперед скажу что я начал 100% TypeScript, но и это не важно. Если вдруг окажется что Rust, или самодельный диалект REBOL, или ClojureScript, окажется более эффективен для создания приложений на Платформе, то этот язык и будет использоваться для создания веб-приложений.

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

Web, desktop and mobile apps. Я пока рассматриваю только Web и десктоп приложения. И это существенное отличие. Помните мы говорили о том, что чем шире область, тем меньше возможностей. Очевидно, что платформа созданная эксклюзивно для десктоп приложений будет богаче, чем платформа, для десктоп и мобайл.

Framework. Ну и самое главное, Meteor — фреймворк. Я делаю платформу. Разницу между фреймворком и платформой мы выясняли ранее. К сожалению, или к счастью, нельзя сделать из фреймворка платформу, не переписав его чуть менее чем полностью.

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

Проект

Проект находится тут https://github.com/anticrm/platform и он пока больше в исследовательском, экспериментальном режиме. На этом этапе нет четких планов, поэтому можно себе позволить рассматривать любые реализации, идеи, да и в целом ничем никого не ограничивать, кроме права не использовать эти идеи или код в проекте.