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

Пример. Для AVR-ок я пользуюсь Algorithm Builder. Тоже визуальная среда, между прочим. И тоже "сокращает время проектирования в несколько раз" - так продекларировано, и соответствует действительности.
НО, там визуализирован только поток исполнения, но не связи. Да, есть хинт - переменная такая-то и такая-то, вот ее локализация... А кто туда чего записал, когда, и почему - сам думай.
Так это самое первое, что я отметил в HiAsm (еще в те стародавние времена) - тут визуализировано ВСЕ.
И эту разницу я знаю не в теории, а на практике. Многолетней, между прочим.
А вы мне про "понять невозможно" рассказываете


Дык "примерно-то" уже было описано на форуме. Примерно там, где коллега Вячеслав написал

Конкретный элемент типа FileStream является конкретизацией (наследником) некого базового элемента, у которого методы Read и Write являются пустыми.
DataToFile является надстройкой (контейнер, элемент), в которой используется элемент-Pointer
Элемент-Pointer имеет св-во типа "класс-элемента", и в нашем случае - это как раз базовый класс для всяких там Stream-ов
Сей элемент принимает некие данные типа OBJ (то ли через поток, то ли через верхнюю точку), а среда ему автоматически делает точки и иконку в соответствии со "св-м класса"
И эти данные - фактически наш сегодняшний Handle мультика.

Тут никакого велосипеда не изобретается - все языки программирования имеют такую "отверточку"
При этом, не хочу я уже иметь элемент типа динамический мультик, и думать про себя, что на самом деле их там много.
А хочу иметь массив объектов (фактически - целочисленный массив хэндлов), подключать его, например, к EnumArray, выход которого - на этот элемент-Pointer, и через него - сотворять с конкретным объектом все, чего душа пожелает.
Меня в усмерть утомило, по каждому чиху внутри динамического контейнера - "выходить" из него, заниматься какой-то селекцией, с последующим выполнением задуманного.
Если таких "чихов" штук 20 - это начинает полностью противоречить "помогает думать"
По настоящему помогает - наличие внутри контейнера элемента памяти, хранящего нужный хэндл для употребления в элементе-Pointer-е.
Или хэндл на массив, если по жизни - именно перечисления необходимы будут.


В общем, делов-то - на копейку: визуальное замыкание, наследование, объекто-указание.
И я больше не буду делать MatrixWave на Дельфи, а буду - на HiAsm
Хотя - нет, буду делать BackEnd, адекватный таковому FrontEnd-у.