Вроде там уже есть некоторые прагмы

Да, оно для микроуровней, для схемотехники, где все статически задано.

Это просто потому, что последние лет 20-25 ООП - выбор "по умолчанию", и никто не говорит "вы что, с ума сошли - использовать ООП?! Это слишком сложно и непонятно! Мы разработчиков не найдём! Никто не знает, как правильно разрабатывать ОО-системы!". А до того ещё как были! 😃
Но на самом деле я не вижу большого количества именно "воинственных" ФП-шников. 🤷‍♀️

Но на самом деле, не всё программирование алгоритмическое. Когда мы работаем с вводом/выводом в широком смысле (даже ячейка памяти), это уже не алгоритмы, а процессы. И на этом уровне работает большинство программистов.

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

В принципе, возражений нет, за исключением — а почему обязательно ФП? Мне ближе графовый подход. Ведь смотрите, как просто. Есть узлы-операции, у них есть зависимости-ребра. Эти самые ребра являются эквивалентом именованных значений из ФП. Нужны "процессы" для ячеек памяти — добавляем новый тип M-зависимостей. Пусть теперь операции обращения к памяти, а также вызовы процедур принимают и вырабатывают M-состояния.

Мне кстати тоже ближе flow based programming

FBP кстати компонентно ориентированный подход а с DAG все становиться еще и иммутабельным

да, есть прагмы, но управления качеством кода компилятора и кодогенератора, вроде бы, совсем нет http://pascalabc.net/downloads/pabcnethelp/topics/LangGuide/CompilerDirectives/index_directives.html Хотя нет - 0-based  строки это про язык и генератор в некоторй степени.

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

Кстати FBP можно формализировать и в текстовом виде. Простой пример Linda:
https://en.wikipedia.org/wiki/Linda_(coordination_language)

То, что я выше описал -- это как раз и есть "известный формализм". И тут, в каком-то смысле, возвращение к раннему ФП в Лиспе, где у нас вычисления описываются вполне понятной структурой данных. Ограничения, безусловно есть. Если мы остаемся на уровне DAG, то можно делать и топологическую сортировку, и множество других интересных вещей. Опять же, на уровне DAG нас не интересует время в явном виде. Порядок операций (включая состояние памяти!) определяется просто ребрами-зависимостями.

Собственно, даже у Харрисона с Филдом описаны оба этих подхода: редукция графов (Haskell и проч.) и dataflow. Они эквивалентны.

Как бы "и чё"? Вычислительной семантики-то у этой модели всё ещё нет. 😊

Почему нет? А как бы без нее компиляторы-то работали? :)

Да, это интересный малоизвестный язык.

Тогда опишите, пожалуйста, выч. семантику предложенной Dataflow модели.

А я же тут давал несколько раз эту ссылку :) https://hal.inria.fr/hal-01723236/file/sea-of-nodes-hal.pdf

Sea-of-nodes - это всё ещё НЕ вычислительная модель.

Почему же? Еще Клифф Клик неформально ее описал. Помните, где он говорит о сетях Петри для выполнения на уровне CFG.

Я в одном своем проекте выполняю код прямо на уровне виртуальной SoN-машины.