Эта схема не соответствует ГОСТ/ISO

Кроме «демократизации», приятно ещё программировать не в слепую.

А так, чтобы видеть промежуточные результаты, да ещё чтобы и отобразить их можно было нормально.

А мне и не надо. Я делаю лучше.

Начну с мотивации: заметил, что в лично моём случае суть применения оптимизации к компилируемому коду - преобразования нескольких графов (CFG, Def-Use, иных). На C/C++ описывать эти преобразования не очень легко. Поэтому возник вопрос (на будущее, в текущих моих проектах пока не требуется): есть ли способы это дело более удобно описать хотя бы для одного графа?
UPD. Нашёл что-то похожее в проекте Coccinelle: https://coccinelle.gitlabpages.inria.fr/website/cocci_internals.pdf https://coccinelle.gitlabpages.inria.fr/website/papers/popl09.pdf

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

Людей на курсах можно обучить любому языку.

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

Такие люди и SQL не осилят.

Да. Но эти всякие "визуальные", "графовые" и какие там ещё языки они не осилят тоже.

Это немного ортогонально графовому представлению программы. Было популяризировано Light Table и Swift Playground, но встречается во многих экспериментальных разработках в этой области.

Так, но luna делает и то, и другое.

Не факт. По-моему есть две категории "необучаемых": те, кто не понимают (формализованную) логику вообще (ну, их и логике не обучали и не пытались), и те, кто не может уложить в голове конкретно императивное mutable state-based программирование, хотя логику в целом понимают. Соответственно, вторая группа вполне обучаема SQL/"графическому" программированию. Вероятно, (высокоуровневому) функциональному/логическому программированию тоже.

Что как бы подтверждает мой тезис об ортогональности. 😊

У меня закрадывается подозрение, что "графическое программирование" строят на уровне "классов", но на уровне "объектов" было бы полезнее/понятнее. С другой стороны, "объекты" нужны тоже более высокоуровневые, наверно.

А хоть каких-то статей / исследований и даже других мнений на эту тему (есть две категории "необучаемых") Вы не видели, кстати?

И понимание формальной логики не нужно для тривиального "программирования", нет? ;)

И разве нет категории, которая не может уложить в голове что-то отличное от "императивного mutable state-based программирования"? Если да, то направление "демократизации" должно зависеть от соотношений этих категорий, по-хорошему.

> И понимание формальной логики не нужно для тривиального "программирования", нет? 😉

Нет. Достаточно иметь ограниченную среду с конечным числом сущностей и иметь мгновенный фидбек. Собственно так дети и програмиируют в том же blockly

А художники и vfx-дизайнеры в The Foundry Nuke или Blackmagic Fusion

> А хоть каких-то статей / исследований и даже других мнений на эту тему (есть две категории "необучаемых") Вы не видели, кстати?

Мнений-то на эту тему полно, а статьями я не интересовался. Утверждать, что "есть только две категории" я не берусь — исследований не проводил, просто грубое обобщение личного опыта.

> И понимание формальной логики не нужно для тривиального "программирования", нет? ;)

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

> И разве нет категории, которая не может уложить в голове что-то отличное от "императивного mutable state-based программирования"?

Так эта категория вокруг нас — это просто большинство программистов, нет?

> Если да, то направление "демократизации" должно зависеть от соотношений этих категорий, по-хорошему.

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

Да 90% профессиональных программистов обходятся без формальной логики вообще. 🤷‍♀️