DRAKON.SU

Не считаю Мне эта реализация не нравится по многим пунктам, поэтому и отношение к ней индифферентное. Да и то хорошо, что она вообще есть! Нельзя ждать от слишком многого от энтузиастов.

Свою реализацию писать очень хочется, но разве что с первой пенсии

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

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

Раз уж так неудобна реализация, опишите пожалуйста, как Вы видите процесс без "много и часто открывать/закрывать всевозможные окна и формы, с введенным в них текстом".

Кстати, показ кода на Обероне внутри икон Дракон-схемы(который Вам не шибко понравился) и есть тот самый, "полностью раскрытый", контейнер.

У меня нет готовых методов, но как я понял из приведенной выше статьи, декларативная часть языка ДРАКОН разрабатывается параллельно процедурной, а объединяются они только в момент трансляции программы. Может быть, я ошибаюсь.

Проблему я вижу в следующем.
С одной стороны, алгоритм делится на две части:

И в той, и в другой частях языка ДРАКОН остается достаточно много листинга.
С другой стороны на иллюстрации http://store.oberoncore.ru/lib/paper/grafit_A4.pdf видно, что согласование идентификаторов происходи только на первых этапах разработки. Это все относится к технологии ГРАФИТ-ФЛОКС, где есть строгое разделение одного языка и применяется он для конкретных задач.

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

Хочу высказать предположение.
Если следовать схеме на рисунке grafit_A4.pdf и строго разделять процедурную и декларативную части языка, собирать их только в момент трансляции программы, то ошибками времени компиляции можно будет проверить логику программы.

Вы не ошибаетесь. Они действительно объединяются только в момент трансляции программы.
http://store.oberoncore.ru/lib/paper/grafit_A4.pdf

Хочу дать пояснение. Технология Графит-Флокс, используемая в НПЦАП им. Пилюгина — это одна из возможных реализаций языка ДРАКОН.

Эта реализация нигде (повторяю, нигде) не описана. Она никому не известна и не доступна, кроме работников НПЦАП.

Это частное техническое решение, не рассчитанное на распространение за пределами НПЦАП.