а не, по дефолту вроде бы fasm, но там много пакетов для разных платформ и т.п.

на свой вкус я бы сделал панельку с "иконами" (блоками), перетаскивание мышью. Ну и закастомил бы кодеген.

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

хотя у того же uml говорят свои проблемы https://habr.com/ru/company/vdsina/blog/561272. В статье много умных терминов, но вангую, что опять-таки все упирается в проблемы самого моделирования, синхронизации его с продуктом и прочие сложности. Может на галерах его и используют, если времени много и денег, а в небольшой разработке моделировать как-то сомнительно выглядит, разве что, как выше отмечалось, для сложных алгоритмов, но не факт, что лучше выйдет.

сюда вопрос. Как другому человеку передать смысл алгоритма?
1. етественный язык - запутаешься
2. блок схемы - тоже запутаешься из-за подпрограмм (или больших ветвлений)
3. умл? возможно, но специфично
4. ???

5. просто кодом - тоже не очень эффективно в большинстве случаев

для этого обычно используют псевдоязыки

среднее между строгим яп и естественным языком

Питон нарример

да хоть и питон

Там не про проблемы UML о чём автор пишет напрямую:
Вы уже должны были понять: дело не в каких-то недостатках UML. Мы просто отказались от бизнес-анализа и формальных спецификаций
Может ты статью перепутал?

для передачи смысла алгоритма от одного человека к другому идеально подходит ... youtube

asciinema, чо там мелочиться

Лоо

есть люди, которым в принципе ничего не объяснишь и они обычно склонны находиться на высоких должностях, хех).  Я не особо в курсе DDD, но вроде как именно там активно поднимался вопрос синхронизации между языками программистов и специалистов, там вроде как есть словарь предметной области, определение понятий и стремление к устранению недопонимания. Потом это переводится на язык диаграмм, но разработка идет в терминах клиента, вернее его специалистов, но скорее получается что-то такое:
1. вот этот квадратик - это платеж, понимаш?, да\нет
2. тот такой - нет
3. ок, что это тогда, опиши текстом\нарисуй\приведи пример?
4. по моему суперпрофессиональному стажу с 20 лет опыта ведущего специалиста в супердупер госконторе ведущей отрасли ведущих отраслей это больше похоже на транзакцию в отчетности нумер три нуля одын.
4. ок, я почитал три нуля одын, вот этот квадратик - это транзакция, понимаш, да\нет?
и так по циклу) Кроме того, разные виды диаграмм друг друга дополняют, если не доходит по структурным, то тогда их уточняют диаграммы поведения. Но опять-таки, чем больше уточнений - тем труднее синхронизировать модель с продуктом, модель всегда будет в чем-то условна.

но а если брать прокачанного спеца или другого разраба, то все зависит от его скиллов скорее всего).

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

что-то поискать можно тут https://online.visual-paradigm.com/diagrams/features/diagram-templates, но если стоит задача передать именно сложный алгоритм, то проще взять что-то из юмл, мне кажется, там есть параллельщина.

По картинке как раз и получается, что «Ди - ни нужно»