Как я дошел до жизни такой и до архитектурного программирования

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

1984-1989 Проект Кронос

Про проект Кронос можно прочитать здесь: kronos.ru, статья Руслана Богатырева. Я отмечу только главное.

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

Характерные особенности проекта:

• Одна архитектура железа
• Все ПО написано на одном языке Модула-2
• Все ПО написано с нуля, никаких зависимостей от другого (внешнего) софта

Особенности проекта, обеспечивающие высокую скорость разработки: моносистема, нет зависимостей.

1989-1991 Сохранение и развитие

Проект Кронос завершился в конце 1980-х, и, во многом, завершился вынуждено. Перестройка шла полным ходом, экономика СССР рассыпалась. Надежды на большое внедрение таяли.

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

Я продолжал работать над компиляторами и основная задача этого этапа была обеспечение переноса ПО. Для этого были эксперименты над генерацией на другие процессоры, например, на один из первых 32-х разрядных процессоров NS 32032 от National Semiconductor и трансляция на язык Си. Именно трансляция Модула-2 в Си стала существенным итогом этапа, принесла деньги и дала возможность идти дальше.

На первый план в моих работах вышла переносимость ПО.

1991-1994 Оберон и расширяемость

В 1991 году была поездка в ETH Zurich к Никлаусу Вирту, знакомство с компьютером Ceres, языком Оберон, Оберон системой и компилятором OP2.

Вернувшись из Цюриха я начал работать над компилятором Оберона, и вместе с коллегами над компиляторами Модула-2/Оберон в x86 и трансляторам в Си, которые продавались под названием X2C, где X - это Модула-2 и Оберон-2.

Несколько позже я начал работать с коллегами над расширяемой системой Mithril. Этап был завершен защитой кандидатской диссертации, посвященной двойному компилятору и ООП системой Mithril.

Именно тогда, я получил прививку от объектно-ориентированного подхода, убедившись в том, что ООП - это не так хорошо, как выглядит. Уже гораздо позже, я сформулировал для себя, что свойства расширяемости недостаточно. Важными свойствами развиваемой и долгоживущей системы должна быть возможность не только добавлять (расширять), но и заменять и удалять части. А это уже не совсем или совсем не ООП.

Принципиальные особенности этапа: би-языковость, расширяемость и переносимость.

1994-1998 XDS и заказы

Начиная с 1994 года мы начали работать по заказам от западных компаний, и большинство заказов были на разработку компиляторов. Они делались на основе XDS (eXtensible Development System) - переработанного би-языкового компилятора. Изначально XDS поддерживал 2 языка (Модула-2, Оберон-2) и два генерации кода (x86, Си). По ходу выполнения заказов добавлялись как языки (SL1, диалект Паскаля), так и генераторы (68k, Sparc, …).

В кандидатской диссертации, я писал о схеме компиляции 1+e => M, когда два похожих языка, отличающиеся небольшой добавкой e (М2, О2) компилируются в M архитектур. Очевидно, такая схема семантически существенно проще, чем схема без ограничений N => M. Впрочем, добавление "заказных" языков, а потом и языка Java разрушило это схему.

От схемы 1+e => M, было недалеко до мысли о том, что надо делать компилятор для "семейства" близких языков, а чтобы обеспечить "близость" надо это семейство разрабатывать целиком.

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

2002-2005 Эксперименты в области сборочного программирования

Мысль о том, что надо делать технологию программирования, а не отдельные программы, такие как Оберон система, привела к экспериментам в области сборочного программирования. А.П. Ершов писал в статье "Предварительные соображения о лексиконе программирования" (1983 г.) про три формы программирования: синтезирующее, сборочное и конкретизирующее. Я не помню, что было раньше, моя тоска о потерянной со времени Кроноса интенсивности разработки или перечитывание статьи Ершова, но так или иначе, я несколько лет, одновременно с разработкой коммерческих проектов экспериментировал с компонентами и сборкой на основе Дельфи и DLL.

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

Эксперименты были не простыми, под капотом программы на Дельфи происходили "чудеса", которые заставили перейти на следующий этап.

2006-2012 Сборочное программирование, среда разработки "Вир"

Устав от бессмысленной борьбы с Дельфи, я смастерил очень простой (и странный) язык программирования, написал для него очень простой (и странный) табличный компилятор для x86 и это привело к прорыву в сборочном программировании. Достаточно быстро я научился собирать программы из компонент, написанных на этом языке, и одной из первых программ была среда разработки "Вир", которую я делал одновременно с другими программами.

Как и во времена Кроноса, между теми программами, которые я собирал и процессором не было ничего "чужого", за исключением остатков на Дельфи, которые я постепенно выкидывал.

Снова отсутствие зависимостей!

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

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

Принципиальные особенности: технология программирования, интенсивность, сборочное программирование, отсутствие зависимостей.

2014-2019 Системный архитектор

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

Принципиально: понимание того, что понятие "архитектуры ПО" находится в зачаточном состоянии.

2014-2018 Эксперименты с языком сборочного программирования

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

В ходе экспериментов я пытался использовать существующие языки, например, Go и Rust, и пришел к выводу, что другая технология программирования заставляет разрабатывать другие языки.

Я потихоньку начал осваивать новую профессию - разработку языков программирования и писал статьи, см. например, "Компонентный ассемблер. Часть 1", "Часть 2". Тогда же у меня оформилась мысль, что надо разрабатывать "семейство языков".

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

2019-2021 Экспериментальный язык разработки приложений

В 2019 году я сменил профессию, и официально стал заниматься разработкой языка программирования. Одним из фокусов в работе над этим языком было построение системы типов см. "Разработка типовой системы языка программирования приложений". Работа была доведена до прототипа языка, компилятора с генерациями кода 1) нативной через LLVM IR и 2) в байт-код проприетарной VM, набора стандартных библиотек и поддержки исполнения. После этого, разработка этого языка была заморожена и начался следующий этап.

Принципиально: семейство языков, обобщенная система типов для семейства.

2022-2023 Семейство языков, Тривиль

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

В сентябре 2023 рабочая версия языка и его компилятор, написанный на самом Тривиле, были сделаны.

Разработка языка Тривиль и компилятора описана в серии статей, см. .

Принципиально: семейство языков, переносимость, минимизация зависимостей.

2023-н/в Архитектурное программирование

См. статью "Третья структурная эволюция. Введение в архитектурное программирование".

Архитектурное программирование объединяет все, что я считаю принципиально важным: это технология интенсивного программирования, поддерживающая явную архитектуру ПО и сборочное программирование, основанная на семействе языков, обеспечивающая  переносимость  и минимизирующая зависимости.