DRAKON.SU

Как вам такие иконы Вопрос?

Можно группировать иконы в одну большую через изменение фона, но это лишь в программировании может понадобиться, выделить то, что находится внутри одного if.

Блок switch-case, в старых языках программирования можно отобразить case без break, в новых языках, и не в программах, это будет заблокировано.

Блок для default не нужен, просто от крайней иконы вправо-вниз выводим линию, как else у if.

Что мы тут имеем?
Имеем прямоугольник (то есть ДЕЙСТВИЕ!!!) с какими-то непонятными нашлёпками и выходами.
То есть визуальное представление уже неудачно, путает, сбивает с толку.
Это примерно как вы бы предложили изменить общепринятый набор цифр: "А давайте вместо 4 будем рисовать 3, только дополним нижнюю часть до окружности".
В результате алфавит изменился (уже издержки!), и даже при прочих равных его эргономичность ухудшилась из-за похожих до степени смешения элементов.

Экономия пространства - большое дело, но этого недостаточно.

Мне, например, в принципе непонятно желание алгоритмического отображения логики.
Я считаю принципиальным УХОД от такого отображения!
Потому что алгоритм - это алгоритм, а логика - это логика. Для логики существуют БОЛЕЕ АДЕКВАТНЫЕ языки:
- логические формулы;
- таблицы истинности (в более общем случае - таблицы решений).

Если в алгоритме важно его "симультанное восприятие" и непрерывность скольжения взгляда по маршруту, то понимание логики - совершенно другая задача.
Встретившись на пути маршрута, она ВСЕГДА требует остановки и вдумчивого анализа.
При этом обратим внимание на особенностях представлений логики на том или ином языке:
- язык формул наиболее компактен;
- язык таблиц явно демонстрирует полноту рассмотренных вариантов;
- язык алгоритмического описания наиболее труден для восприятия и анализа, и его следует считать неадекватным.

Обратите внимание: в приведённых примерах вы говорите ВСЕГО ЛИШЬ о банальной развилке!
Соответственно, для лёгкого восприятия алгоритма ДОСТАТОЧНО задать абстрактное условие ("а тут мы проверим что-то") и показать ветвление.
Что именно мы проверяем - ИЗЛИШНЯЯ детализация НА ДАННОМ УРОВНЕ представления.
Надо будет - переключим контекст и увидим вопрос, формулу, таблицу и т.п. (но никак не алгоритмические переплетения абсолютно элементарных решений, которые зачем-то вытащили на верхний уровень, загромождая его и КРАЙНЕ затрудняя восприятие основной задачи этого уровня).

В иконе case сейчас тоже прямоугольник с нашлёпкой - стрелкой, хотя логически больше на if похоже. Если икона будет прямоугольной, в неё легко сделать вход слева, что даёт преимущество в компактности схемы.

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

Хотя и иконы Вопрос с нашлёпками выглядят неплохо, как и циклы в Силуэте.

Внизу нашлёпку можно и не делать, по-умолчанию Да может быть внизу. Если схему могут читать неподготовленные люди, добавляем на схему Пояснения, касающиеся не только иконы Вопрос, но и других.

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

Иконы Вопрос без подписей на уменьшенной схеме отлично видны.

А зачем вы мне приводите плохое в оправдание худшего?
Я тут неоднократно писал, что почти все визуальные элементы здесь никуда не годятся (разве что как "иконы", посвящённые устаревшему ГОСТу).
Всё потому, что над их дизайном думали исключительно из соображений черчения по трафарету.
Когнитивной эргономики в них чуть меньше чем нисколько.
Но это не повод придумывать ещё одну плохую штуку, причём там, где в ней нет необходимости.

А если вы ещё немного подумаете, то поймёте, что т.н. "схема" НИЧЕГО не проясняет, а только очень даже успешно МАСКИРУЕТ любую проблему.
Вот в таблице истинности вы волей-неволей перечислите ВСЕ варианты - и тем гарантируете полноту анализа.
Формула полноты не гарантирует (она вообще для другого уровня предназначена).
А алгоритмическая схема сложнее для восприятия, чем формула, но так же нисколько не гарантирует полноты.

Кроме того, вообще подменять математический анализ проблемы алгоритмическим блужданием в пространстве вариантов - крайне дурная практика (хотя, увы, очень распространённая).
Хороший инструмент должен пресекать такие поползновения в корне, предлагая АДЕКВАТНЫЙ инструмент в контексте каждой подзадачи.

Это абсолютно очевидное требование к инструменту (которого пока никто так и не сделал).
Главное, чтобы "схематичность" была адекватна.
Алгоритм ОЧЕНЬ РЕДКО когда является адекватным. Только для узкого круга задач программирования - и то до тех пор, пока не потребуется локально использовать более удобный формализм.

Я пока что не видел ничего лучшего, особенно то, что не было взято из ГОСТ-а, взять те же циклы ДЛЯ и в Силуэте, вторые очень наглядные, первые я вообще не вижу, через одну икону не могу найти пару, ГОСТ иконы не выразительны, на любую блок-схему без слёз не взглянешь, даже если попытаться нарисовать в ДРАКОН-стиле. Поэтому я и против стрелочных циклов, их очень плохо видно, и они явно из ГОСТ в наследство достались. У нас видимо разные взгляды, это нормально, я здесь публикую идеи не для того, чтобы реформировать ДРАКОН-схемы, а чтобы получить обратную связь на то, что делаю. Мне ну очень нужен инструмент для написания любого кода в редакторе схем, и не только нового, но и для работы со старым.

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

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

Это очевидно.
И это плохо.
По-хорошему надо снести всё и выстроить заново, конструируя осмысленно, системно.
Не лепить заплатки и надстройки, а именно выстроить целостную и СОГЛАСОВАННУЮ картину.
Разработать когнитивно-эргономичный алфавит.
Печально, что за полтора десятка лет такую задачу никто так и не поставил.

А вам не приходило в голову, что они не взлетают вовсе не из-за закрытости?
А из-за того, что каждый такой автор прежде всего пытается РЕШИТЬ ТОЛЬКО СВОЮ ЗАДАЧУ.
Причём не просто решить, а решить так, как он это понимает. Без вышеупомянутого системного подхода.
Не говоря уж об изначально кривой формулировке задачи...
В результате становится неважно, закрытый код или открытый.
Проект просто никому не интересен.

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

Благодаря открытым инструментам многие заинтересовались ДРАКОН-ом, я в их числе, но эти инструменты не позволяют мне решать мои задачи по программированию. Были отличные закрытые инструменты, но из-за их закрытости не произошло их дальнейшего развития.

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

Пример стрелочного цикла, реальный кусок кода из DRAKON Editor, во вложении он же в схематическом виде:

Тот же цикл в блочном виде и висящей иконой выхода, схема тоже во вложении:

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

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

Вы собираетесь разработать новую программу ДРАКОН-конструктор, исходя из разработанных вами принципов?
Или нет?
Какие у вас планы по продвижению ваших идей?

Я открыл специальную тему для вашего ДРАКОН-конструктора
«DrakonTeo»

viewtopic.php?f=143&t=6994

Прошу следующие сообщения делать не здесь, а в указанной теме (чтобы все было в одном месте).

Укажите ваше название, и я изменю DrakonTeo на ваше название.

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

А в целом, цикл "для" в Дракон-е, фактически, находится особняком в методологии "двумерного структурного программирования/моделирования", выделяя явную структуру с единственным входом (но с возможностью множества досрочных выходов несмотря на контекст предусловия с оттенками квантора всеобщности "для всех ...", в общем, как в "мейнстриме").
Стрелочный цикл является частью "маршрутного" языка, сохраняя декларируемую в "двумерной структурщине" возможность переплетения связей между условиями. Так, например, ниже в цикле есть не только досрочный выход, но и альтернативный вход:

В стрелочных циклах есть некоторые плюшки и для "строгой структурщины", например:
https://forum.drakon.su/viewtopic.php?f=94&t=6597

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

Вероятно, форма "один в один" касается не только циклов, если говорить о полностью прозрачной автоматической "мгновенной" трансляции текст <=> схема. У меня нет опыта в такой трансляции, но задача преобразования произвольного логического выражения (и сочетания условий во вложенных if...then if...) в комплекс икон "вопрос" (разложение выражения с конъюнкциями и дизъюнкциями на составляющие, извлечение отрицаний и формирование множества связанных икон "вопрос", применение рокировок для избежания пересечений и пр.), как минимум, не выглядит тривиальной.
Среди участников форума, например, Olegar делает трансляцию Java в схему, может быть, у него есть подробности о такой проблематике (и в смежных вопросах по поводу break/continue, ранних return и пр.):
https://forum.drakon.su/viewtopic.php?f=208&t=6971#p105354

Вероятно, нужно забыть про "визуальную логику", и для всех условий обходится одной иконой и одним направлением по умолчанию ("один в один").
Когда-то здесь был представлен язык ДАЛВЯЗ:
https://forum.oberoncore.ru/viewtopic.php?f=121&t=5628
https://forum.oberoncore.ru/viewtopic.php?f=121&t=4556

Там применялась одна икона "ромб" для всех условий, "да" всегда вниз без надписей:

Причём именно такая форма ромба универсально удобна -- она работает и как "указатель" (ака "вариант"), позволяет и крупную нагрузку:

Границы циклов можно задать альтернативно -- предложенными иконами для "силуэта".

Или же для границ циклов можно рассмотреть приёмы из Flowgorithm в AutoCAD -- замкнутые выделенные на маршруте структуры ("циклическая" линия на "шампуре" -- "двойная" или обратная -- не должна давать возможность размещения икон), необходим лишь один ромб, с надписями или иными метками (тот же закрашенный нужный уголок), для "висячих" икон кроме овала (return) можно использовать "соединитель" из блок-схем -- кружок со спецсимволом (например "#" -- ака "хештег" -- на начало или continue, "*" -- ака отрицание или ингибиторная дуга -- break):

Скорее всего, удовлетворению таких хотелок мешает принцип "валентных точек" или построение схем на основе "маршрутов".
Например, в этой схеме:

если всё же запрещать подобные неструктурные переходы (вовнутрь "case 3" в примере), то нужно ещё постараться над формулировками (для многих случаев), почему нельзя, ведь нет пересечений и пр. (к слову, в дополнительную нагрузку особенно тем, кто засыпает над толмудами стандартов C++).

В целом, глобально, в языке должны быть замкнутые структуры как в Р-схемах Вельбицкого (грубо, там именно линии формируют структуры вычислений, а не фигуры). Тогда возможна любая прозрачная работа в стиле вот этого Rocket Designer-а:
https://www.youtube.com/watch?v=_LohGp7ey2s

К слову, есть и некая вертикальная редакция Р-схем в виде "ленивого Дракона":
* https://forum.drakon.su/viewtopic.php?t=5616
* https://forum.oberoncore.ru/viewtopic.php?f=7&t=6486#p109635

Но, если говорить о предельно универсальном алгоритмическом языке, то, всё же, Р-схемы далеко не всем понятны с первого взгляда, особенно суть подобных циклов:

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

Что же до досрочного выхода из цикла, есть висящие иконы break, для повторения цикла continue, и есть множественные выходы из схемы return, ровно так, как и в реальном коде, только в отличие от кода, они на схеме прекрасно видны.

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

Всё же нужен логический конструктор, не только разворачивать if(?), но и в присваивании a=?, в return ?, в циклах. Иначе сложные логические конструкции придётся строить в текстовом виде, а не на схеме.

Пока вижу это как ответвление справа от иконы цикла или полки, на выходе вопросов два висящих возврата true и false.

Требуется обозначение анонимных функций, обозначение массивов данных, в которых могут быть анонимные функции.

Анонимная функция идёт справа от Действия.

К параметрам функции добавляем снизу прямоугольник со списком видимых в ней внешних переменных, даже можно использовать для языков, где это не требуется указывать (c, js), просто в качестве справки для себя, хранить в специальном комментарии.

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

При наличии висящих икон (break, continue, return) зачастую потребуется делать выход ДА справа, иначе шампур будет разорван. Возможность поворачивать икону это большой плюс, избавляемся от отрицания в вопросах, где зачастую и не ответишь Да или Нет, "Не переходить вниз?", Да (не переходить), Нет (не переходить), это будет узкое место в построении логических связей, и источник ошибок.

Меня сейчас вполне устраивает в инверсной иконе Вопрос закрашенный уголок справа. Где необходимо, дополняем Пояснениями на схеме, где Да и Нет, в программном коде это не требуется. Доработка икон минимальная оказалась, схема прекрасно читается боковым зрением, что с пояснениями, что без них.