Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Даю ссылку на Краткое описание языка ДРАКОН. Всего 124 страницы. Много рисунков.
ВП>О космических кораблях нет ни слова. Все примеры очень простые, бытового характера.
ВП>http://drakon-practic.ru/drakon.pdf
Предположим, Драконом пользуются для написания реальных программ
Несколько вопросов:
1) Системы контроля версий. Насколько удобно сделать diff между произвольными ревизиями кода?;
2) Насколько удобно закомментировать какую ветку или часть кода, насколько легко это все вынести в отдельную процедуру?;
3) Книгу я просмотрел очень мельком, все примеры там бытового характера. А вот в реальности насколько удобно рисовать эти диаграмки? Отображают ли эти диаграмки полностью структуру программы с полной детализацией, или же за детализацией нужно нажимать кучу клавиш, переменные скрыты и размазаны, и чтоб реально понять что как работает, придется очень сильно потрудиться?

Спрашиваю это все потому, что визуальными средствами написания программ я пользовался на практике и в реальных проектах. И могу сказать, что обплевался. Простейшие рефакторинги делать крайне затруднительно. На диаграмме не все, чтобы увидеть детали, надо нажимать на прямоугольник и смотреть проперти. А если детализация ого-го, то схема крайне перегружена и ее хрен разберешь. Дополнительно, пока какой управляющий блок набьешь, проклянешь все на свете. diff ни хрена ни сделать — если что работало, кто то что то поменял, и работать перестало, хрен докопаешься до причины. Перед использованием всего этого требуется проходить черти какой инструктаж, ибо куча неочевидных моментов.
Я видел кучу рекламных роликов о том, что вот, наконец то, появился новый язык, программисты не нужны, специалисты в предметной области сами все напишут. И в 100 процентах случаев заканчивалось тем, что приходится привлекать программистов, несмотря на наглядность читаемого представления, эти программисты страшно матерятся, тратят в 10 раз больше времени, а также программистов требуется в 10 раз больше. Ибо кроме того, что это все крайне неудобно использовать на практике, еще и среда разработки страшно глючит, а также при малейшем отклонении от идеального эталонного сценария приходится делать такие извраты и макароны, что появляется желание уйти в запой с горя. А если в самом начале в какой либо переменной допустил орфографическую ошибку — все, это уже практически не исправить. Средств рефакторинга нет, чтобы выделить процедуру, нужно ее рисовать с нуля. Даже переменную переименовать проблема, приходится реплейсить внутреннее представление этой схемки, никому не говоря, ибо это запрещено. В результате, учитывая то, что рефакторить крайне затруднительно, на практике код очень быстро превращается в черти какие макароны, когда на одной схеме тысячи стрелочек и блоков, налезающих друг на друга.

PS Относительно новых идей в программировании — мне понравилось вот это. Это действительно то, чтобы мне хотелось видеть. Но рисование программы визуально в виде аналогов блок схем (неважно — UML это, DFD или дракон схемы) — это очень старая идея, которая себя не оправдала, а пытались это реализовать наверно тысячи фирм.