DRAKON.SU

Критика современного состояния языка ДРАКОН

На Хабре в ветке обсуждения статьи https://habr.com/ru/articles/940152/
получил вот такой комментарий.


Что на это скажете товарищи?

1. По поводу try-catch-finally обсуждение см.
Java try/catch/finally в языке ДРАКОН
viewtopic.php?f=154&t=5554

2. По прерываниям много материала на форуме языка ДРАКОН. Надо смотреть в Поиске нашего форума, например "прерывание"

3. Новый формализованный для объектно-ориентированного программирования (ООП) вариант языка ДРАКОН
Муравицкий и Степанов активно разрабатывают IDE для ПЛК, добавив ООП согласно стандарту МЭК IEC 61131-3. Вот ссылки для интересующихся.
здесь и
здесь чат

4. Сергей С. обещает новые результаты в начале 2026 года.
Sergey S, автор falang.io, присоединился к обсуждению Алексея Муравицкого.
Сергей опубликовал:
— две статьи на Хабре,
— открыл две темы на форуме Наш soft сайта easyelectronics.ru,
— открыл две темы на форуме сайта drakon.su,
— открыл телеграм-канал https://t.me/falang_io
https://t.me/falang_chat.

Острая критика в адрес языка ДРАКОН была на сайте Easyelectronics на форуме "Наш soft" в теме
"Программирование микроконтроллеров на языке ДРАКОН"
https://forum.easyelectronics.ru/viewto ... 13&t=31562

Но сейчас она притихла.

В комментарии две претензии к Дракону. С одной согласен, с другой - нет.

Согласен, что в гибридных языках Дракон-Си, Дракон-Java и т.п. нет реализации параллельных потоков, хотя обозначение в схемах есть. Всё, что пишет комментатор про семафоры, мьютексы и т.д. - это программные реализации. Как их реализовать - надо подумать, это направление развития Дракона. Может в каких-то темах уже обсуждалось, как интерпретировать параллельное выполнение. У каждого языка программирования в этом плане свои возможности.

Не согласен, что Дракон не справляется с ролью понимания связей между функциями/модулями/проектами. Со своей ролью описывания алгоритмов и навигацией по проекту при помощи иконы Вставка язык Дракон справляется. Именно с помощью силуэтов и иконы Вставка Дракон позволяет произвести многоуровневую декомпозицию программного проекта. Если необходимо глобально увидеть связь составляющих, в этом могут помочь другие нотации. В этом плане Дракон - не швейцарский нож. ДРАКОНОМ не выразить диаграмму состояний (State Machine), диаграмму Исикавы (рыбный скелет), диаграмму потоков данных (DFD), но им можно выразить диаграмму активностей (activity diagram), диаграмму последовательностей (seqence diagram), ну и BPMN (хотя этот вопрос надо ещё рассмотреть).

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

Спасибо Alex
Вы мне помогли, собрать мысли в кучку