Тут так: мне не кажется, что "Редактор блок-схем" -- наше светлое будущее

Начинаю кое-что припоминать
Было оно значит так: ТС набрел на сайт oberoncore.ru, на котором декларируется принадлежность к инженерному программированию (как потом мне стало понятно, термин-то они ввели, а что такое инженерия - понятия не имеют)
И представил там HiAsm. Накинулся на него народ - мама не горюй. Пришлось заступаться, и посбивать несколько спесь с "ученых".
Некоторые потом даже признали "некоторую академичность среды"
И там же кучковался Паронджанов ( с книгой "Как улучшить работу ума") - очень большой теоретик Графического программирования с помощью именно блок-схем.
И этот графический язык, со своими некоторыми правилами, назвал он -- ДРАКОН. И на сайте даже поддерживается редактор именно этих блок-схем, и даже с возможностью генерации кода.

Чем мне не нравится этот подход.
Там разделены императивные и декларативные связи. И визуализированы только императивные.
Т.е., смотришь на схему - и запросто можно не увидеть некоторых подводных камней. Которые обусловлены каким-нибудь конфликтом данных.
И, по словам Паронджанова - "невозможно объединить ужа с ежом"

В общем, я там сказал народу что-то типа того: "... это Вы, ни разу не видевши визуализацию, кидаете все в одну кучку. Мой же вкус уже гораздо тоньше -- у нас же Уж с Ежом прекрасно объединяются в элементе Memory, например. И никаких проблем"

В общем, думаю, что когда Pirr начинал эту тему, то вопрос блок-схем его так же сильно интересовал.

А теперь смотрите, я попытаюсь связать свои выводы с изложенными ранее принципами.
Пусть меня интересует, прежде всего, управляемость проекта и его безошибочность (скажем, это будет пункт 2).
Пока что мне известен только один способ достижения безошибочности - структурирование задачи, чтобы каждый логический уровень иерархии был ограничен по объему.
Есть такая гипотеза (никем не опровергнутая), что в схеме из 10 элементов за конечное время разработки можно достигнуть нулевого количества ошибок.
Не 0.1, не 0.01, не 0.0001, а именно 0. Видимо потому, что количество ошибок измеряется целым числом.
И для 10-ти элементов - это не месяц работы... И, пожалуй, даже и не неделя.

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

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

И мое мнение такое, что доработка языка HiAsm значительно более перспективна, чем языка, в котором нельзя скрестить Ежа с Ужом

И хотел бы обратить внимание еще вот на что. Схема, нарисованная в каком то языке предназначена не только для того, чтобы ее компилировать, но и чтобы ее мог прочитать другой (пункт 2).
В профессии Инженера второе не менее важно, чем первое.
А сейчас я рассматриваю крайний случай, совсем непривычный для простого народа: я допускаю, что компилирования вообще нет.
((сделайте паузу, чтобы прошел шок, потом читайте дальше ))
Вовсе не потому, что я противник компиляции. Просто, сначала надо создать язык (потому что сегодняшнего языка HiAsm чуть-чуть не хватает), а потом думать об автоматической компиляции. Естественно, достойной Инженерной практики.
Ну а пока, я намерен обойтись применением человеков-программистов вместо компилятора.

((продолжение следует))