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


На это я тоже уже отвечал:

К сожалению, исходники как раз наглядно показывают, что без поллитры и активной помощи автора в них фиг разберешься :

— Диаграммы не помещаются на экране (даже при zoom out)
— Взаимодействие между отдельными функциями (типа bad_case/foreach_current/и т.п. во всяких cs.drn и т.п.) непонятно (может они вызываются откуда-то извне? неизвестно).
— они достаточно низкоуровневы, чтобы без комментариев разобраться было уже невозможно:
Код:

set found_keywords [ gen_cpp::find_keywords $first $keywords ]
set alien_keywords [ gen_cpp::find_not_belonging $first $keywords ]

— местами это по сути псевдокод, только в визуальном обрамлении (например, alt_edit.drn -> shadow), то есть от визуальности он не выигрывает вообще ничего. В частности, для диаграмм типа alt_edit.drn -> update, если использовать паттерн матчинг (Haskell, Erlang, Nemerle), то даже текстовая запись будет не менее, а то и более наглядна

СМ>

СМ>Прогрессивный мир нынче смотрит на: метапрограммирование, зависимые типы, typesets, proof-carrying code. Крайне интересны исследования в области total functional programming.

СМ>Многое из перечисленного выше отлично работает вместе с Драконом. То же функциональное программирование, отлично сочетается с Драконом (ДРАКОН-Эрланг например).

НИфига он там не сочетается. Цитирую:

2. Перегрузка функций (наличие нескольких функций с одним именем) запрещены в DRAKON Editor'е по
политическим мотивам.
3. Ветвление логики делается только стандартными средствами Дракона, pattern matching (case of, when) для этого не используется.

На драконе даже алгоритмы с ФВП записать не удастся