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
Вы мне помогли, собрать мысли в кучку

Сергей, описанная вами ситуация называется "прерывание".

1. По поводу прерываний на языке программирования Java см. подробное обсуждение на языке ДРАКОН:
Java try/catch/finally в языке ДРАКОН
viewtopic.php?f=154&t=5554
Внимательно изучите

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

3. Опытный программист Муравицкий не ответил вам на вопрос про антимаркер, потому что он не знаком с термином "антимаркер". В програмировании термин "антимаркер" обычно не используется.

Алексей очень мне помог и он сейчас не может отвечать на комментарий на Хабре. У него много текущей работы.

Сергей, посмотрите в Википедии статью Прерывание

Сайт умер, да и никого там эта тема не заинтересовала, потому что на том сайте много инженеров-практиков, работающих с "железом" на низком уровне, чего Дракон не умеет.

В Драконе не увидел того, что называется POU, поэтому нет возможности делить алгоритм на потоки.
Нет блока описания переменных, поэтому нет возможности создавать переменные с синхронизируемым доступом или volatile-переменные, посему ни многопоточность, ни прерывания Дракону в нынешнем виде не по зубам.

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

Я с некоторыми упоминаемыми в постах разработчиками Дракон-редакторов пообщался в чатах. Пока только Алексей Муравицкий с товарищами прочувствовали что и как нужно сделать для превращения Дракона в полноценный язык программирования, подобный С/С++, но вот хватит ли у них ресурсов на реализацию- вопрос. Нужны люди, нужно время, нужно серьёзное финансирование.


А не понятно, для чего нужен такой ЯП как Дракон, на котором не возможно нарисовать и отладить программу примерно также, как это уже лет 50 делается во всех других ЯП. И попытка презентации на сайтах, подобных easyelectronics.ru, это чётко показала. И каждый очередной Дракон-редактор, повторяющий функционал предыдущих, обречён кануть в Лету.

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

Уважаемый tonyk!

Я с большим вниманием, огромным уважением и благодарностью изучаю Ваши сообщения. Спасибо, что не забываете.

Полностью согласен с Вами. Алексей Муравицкий заметно продвинулся вперед.

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

Не буду высказываться.
Я принципиально вышел из того чата, поскольку вопросы, обсуждаемые в нём, на мой взгляд, далеки от того пути, по которому следует идти. Но мы общаемся с Алексеем лично, поэтому у меня есть понимание чем, как, почему и для чего занимается Алексей со своими коллегами. Из этических соображений я не вправе делиться этими сведениями. Алексей сам всё расскажет, когда сочтёт нужным.
Общался ещё с двумя разработчиками, в чьих работах вижу основу для создания полноценной IDE, но они не прониклись идеями создания Дракон-IDE и продолжают ваять очередные 100500-ые Дракон-рисовалки со своими бантиками.

Вы правы. Это, конечно, самое важное.

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

Критиковать ДРАКОН как язык бизнес-процессов я не буду, но как ЯП он фактически не существует.

> Те, кто задумывался о создании IDE для Дракона и реализации нормального программирования с отладкой программы по Дракон-диаграмме, очень быстро приходили к тому, о чём я говорю.

Вот я разработал MVP системы визуального программирования (там свой язык, но она основан на ДРАКОН-е) и с тем о чём ты тут говорил я согласен процентов на 50 максимум.

Не совсем так.
Григорий, внимательно прочитайте мой текст ниже, пройдите по ссылкам и изложите Ваше мнение в чате языка Дракон++.

> пройдите по ссылкам и изложите Ваше мнение в чате языка Дракон++.

Зачем? Мне не интересны ПЛК от слова совсем, тем более мои наработки там мало применимы.

То есть я могу нарисовать программу, отладить её по диаграмме и получить на выходе исполняемый файл?

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