DRAKON.SU

Важная разработка и ссылка Григория Пуляева
Визуальное программирование.
https://www.linux.org.ru/gallery/screenshots/17552363
"Переделанный Дракон"


tonyk в чате языка Дракон++ под ником Anton K.

Без отладки это просто рисовалка.
Полноценная IDE позволяет создать программу, загрузить её на целевое устройство и отладить её по исходному языку, то есть на Драконе в нашем случае. И всё это не выходя из IDE. Я создаю программу на Драконе, так почему мне нужно ещё изучать какой-то промежуточный язык, через который Дракон попадает в процессор? Представляю текст вакансии: "Требуется Дракон-программист с глубоким знанием Java, Haskel, ST для отладки Дракон-программ на этих языках". Глупость, правда?
К сожалению, на сегодняшний день нет ни одной полноценной среды разработки на Дракон, в которой можно выполнить весь цикл разработки программы: рисование программы, отладка на симуляторе, загрузка в целевое устройство, отладка на целевом устройстве. Самое печальное, что понимают это и что нужно делать буквально пара человек (я не в счёт), и даже делают шаги в нужную сторону.
Я со своими ПЛК работаю на языках ГОСТ Р МЭК 61131-3. Вот и с Дракон хочу работать из подобной IDE.

Куда она делась?! Посмотрите, как она сделана в Proteus (программа для создания электронных устройств, где есть редактор электрических схем, среда моделирования схем, редактор печатных плат и среда программирования МК и ЦПУ), где программа может создаваться в виде классической блок-схемы алгоритма и отлаживаться и по шагам, и с точками останова.
Уже писал об этом, но повторюсь. Прошу извинить за прямоту, но посмотрите на примере любой IDE для ПЛК, как решена отладка в их графических языках. Посмотрите на создание программ и их отладку по точкам останова, по шагам в Proteus. Обратите внимание, что в обоих примерах реализован полный цикл разработки ПО. Сравните с вашими редакторами и не обижайтесь на меня, что я говорю о ваших редакторах как о 100500-ой рисовалке, обречённой на забвение. К сожалению, нынешнее унылое состояние дел с Драконом является иллюстрацией не правильного подхода к его реализации, и очередная рисовалка лишь подтверждает то, о чём я говорю.

> Без отладки это просто рисовалка.

Ты удивишься, но пошаговой отладкой на Haskel-е никто не занимается. Более того для декларативных языков она в принципе не возможна. Для поиска ошибок используется мощная система типов + REPL. Всё это у меня реализовано и этого более чем достаточно.

> загрузить её на целевое устройство и отладить её по исходному языку

А вот этого точно нет и не будет. Я не собираюсь заниматься поддержкой ПЛК.

> Куда она делась?! Посмотрите, как она сделана в Proteus

Разве в Proteus есть визуальное программирование?

А причём тут Хаскелл? Я говорю про отладку Дракона. И если я займусь программированием на Драконе, то мне абсолютно безразлично, каким образом нарисованная диаграмма превратилась к команды процессора. Меня интересуют удобство создания программы, скорость её работы и удобство отладки.

А причём тут ПЛК? Существует огромная масса встраиваемых компьютеров, зачастую вообще не имеющих графических контроллеров. Более того, гораздо быстрее и удобней программировать и отлаживать программы для таких компьютеров на мощных ПК, а потом просто через сеть грузить в них бинарник на исполнение.

А куда оно делось? Есть. Вы бы посмотрели, прежде чем кодить, как это сделано у других. Уже говорил, что в Proteus отладка идёт по нарисованной блок-схеме, и пошагово, и с точками останова, и наблюдением за текущими значениями переменных, короче, всё как должно быть в полноценных средах разработки ПО. Дракон вырос из тех же самых блок-схем, поэтому реализация отладки в Proteus является иллюстрацией того, что должно быть в среде программирования на Драконе.

Это всё сделано для Хаскелл, а не Дракона, и к отладке программ на Драконе не имеет отношения.

Это ваше мнение. Моё мнение, что создана очередная рисовалка со своими бантиками.

Если для вас главное это Хаскелл, а Дракон так, нахлобучка на него, то нет предмета для обсуждения, ИМХО. Как сделано, так сделано, потому что лично я не встречал в промышленности ничего, написанного на Хаскелл, поэтому ценность этого ЯП для меня нулевая. Если же была попытка сделать среду программирования на Драконе, то явный незачёт, потому что в части Дракона не сделано ничего нового, не изучены существующие решения аналогичных задач, не использованы (и, похоже, даже не известны) технологии для решения таких задач.

> Я говорю про отладку Дракона. И если я займусь программированием на Драконе

Да вот нельзя программировать на чистом ДРАКОН-е. ДРАКОН это вообще про схемы, а не про программы.

> Меня интересуют удобство создания программы, скорость её работы и удобство отладки.

А я вообще не хочу заниматься отладкой. Я хочу сделать схему и проверить что она правильно работает. Вот на это и нацелена моя работа.

> А причём тут ПЛК? Существует огромная масса встраиваемых компьютеров

Меня вообще железо не интересует

> Это всё сделано для Хаскелл, а не Дракона, и к отладке программ на Драконе не имеет отношения.

Никто и не говорил про ДРАКОН.

Значит вы просто не поняли, что такое Дракон. Впрочем, вы не одиноки в своём непонимании.

Да ну! А это кто говорил?

Странно, конечно, прийти на сайт создателя Дракона, чтобы говорить о чём угодно, но не о Драконе.

> Да ну! А это кто говорил?
> Странно, конечно, прийти на сайт создателя Дракона, чтобы говорить о чём угодно, но не о Драконе.

Что тебя смущает? В среде программирования используется собственный графический язык основанный на ДРАКОН-е, но это уже не ДРАКОН. Если ты возьмёшь к примеру falang то увидишь что там тоже не совсем ДРАКОН. И это очень положительная тенденция которая говорит о том что ВП не остановилось в своём развитии.

Прям как китайцы, которые утверждают, что их самолёт разработан с нуля и лишь отдалёно напоминает российский.

То, что очередной карапуз осилил таблицу умножения, совершенно не говорит о развитии математики в стране. Появление 100500-ой Дракон-рисовалки не_говорит о развитии визуального программирования.

Тоник давно следит за состоянием Дракона, и его позиция вполне понятна. На текущий момент никто кроме Алексея Муравицкого не занимается редактором Дракона для ПЛК. Поэтому требования к редактору от Тоника будут реализованы в версии редактора Алексея Муравицкого Дракон++.

Моя аспирантская работа посвящена методике работы в дракон-редакторе, я делаю редактор и интегрирую его в LMS Moodle через xAPI. В редакторе можно будет создавать учебные задания и пошагово либо вольно их решать. Вопрос отладки и преобразования из кода в схему тоже будет исследоваться в моей работе. Назвать это всё "бантиком" мне кажется неправильным.

Современное состояние Дракона пока никак не оценить. Идут какие-то работы, и как только появятся какие-то весомые результаты, сами энтузиасты сообщат на форуме.

Мои интересы сосредоточены в сфере промышленной автоматизации и разработки электроники для неё. Для решения моих задач мной разработан ПЛК, среда исполнения которого совместима со средами программирования ПЛК фирмы Мицубиси, что позволяет программировать их на языках стандарта ГОСТ Р МЭК 61131-3, три из которых являются графическими (визуальными). На фото ниже показаны мои ПЛК, дооснащённый моими ПЛК существующий шкаф. На скриншотах показаны экраны с фрагментами рантайма ПЛК, написанный на С/С++, фрагмент программы работы ПЛК на визуальном языке FBD, смешанном с LD, плюс фрагмент электрического проекта. Это всё сделано в рамках проекта мониторинга чистых помещений одного из цехов фармацевтического завода.

Мои ПЛК выполняют программы, созданные в первую очередь на графических языках. Поскольку в процессе создания перелопачен большой объём информации, в том числе в части реверс-инжиниринга, то есть знания и практический опыт в сфере реализации подобных сред исполнения. Хотелось бы программировать свои ПЛК на визуальном Драконе, тем более, что подход к посадке Дракона на "железо" я показал в чате. К сожалению, людей, понимающих что и как делать, очень мало, зато все норовят наследить в теме с Драконом очередной рисовалкой с беЗполезным выхлопом.

Уважаемый Григорий!

Меня заинтересовала Ваша доработка языка ДРАКОН для функционального программирования (ФП) и Ваша ссылка на
LINUX.ORG.RU
ссылка

Есть.
Посмотрите в Википедии.
Proteus

Преобразование диаграммы в листинг программы умеют многие рисовалки, потому что это относительно не сложно, хотя есть некоторые нюансы. В некоторых редакторах появился блок создания переменных. Без этого невозможна полноценная генерация кода. Это основа для IDE.
Видимо, вы не поняли меня. Отладка это не бантик, а ключевое отличие полноценной среды разработки от рисовалки. Я не понимаю, почему Дракон низводят до рисовалки алгоритмов, хотя это полноценный графический ЯП, на котором можно и нужно программировать.

Если уж вы так серьёзно подходите к вопросу, то рискну предложить вам план работ по Дракону как он видится мне.

1. Создать текстовый формат для диаграмм с тремя секциями данных: список икон, список связей между иконами, список координат расположения икон на экране. Две первые секции обязательны, третья- опция. Логика должна быть строго отделена от визуального представления. Такая структура нужна для переносимости, кодогенерации и архивирования проекта.

2. Проработать вопрос о многопоточном и многопроцессорном исполнении алгоритмов. Должна быть возможность явного указания того, какая часть алгоритма в каком потоке и на каком процессоре исполняется. Сейчас даже в МК есть 2 и больше как симметричных, так и несимметричных процессоров.

3. Дизайн диаграмм. Эргономикой тут не пахнет совсем: или цветовая гамма вырви глаз, или дизайн икон вызывает недоумение. Должна быть возможность выбора тем, как минимум между художественной и монохромной как на чертежах.

4. Печать диаграмм и сопроводительной информации. Без этого в промышленности Драконом пользоваться не будут. В идеале на выходе один или несколько PDF-файлов в зависимости от форматов листов. В каждом файле обязательны гиперактивные ссылки между листами и между файлами.

5. Отладка. Как минимум отображение на диаграмме текущих значений переменных, в идеале- пошаговая отладки и точки останова.

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


Уже неоднократно говорил, что без текстового формата диаграмм не будет движения вперёд, а будут сонные перебирания черепашьими лапами. Текстовый формат позволит сразу отделить вопросы кодогенерации и документирования от работы с самой диаграммой, то есть работать над проектом смогут уже 3 человека, а не один.
Кодогенерацию делать в С++. Работать со связкой g++ и gdb. Отладчик gdb построен по клиент-серверной архитектуре. Клиентом выступает Дракон, а сервер работает с/на целевом устройстве.
Вкратце как-то так.

Уважаемый tonyk!

В чате языка Дракон++ участник Alex chest опубликовал сообщение (с помощью GigaChat):
ссылка


Tonyk, прошу Вас высказать замечания по этому тексту.

Чушь полная. Желаемое выдаётся за действительное.

Покажите хоть одну реализацию, в которой это сделано. Покажите хоть одну реализацию, в которой есть система типов и встроенный синтаксический анализатор, выявляющий ошибки.

Создатели рисовалок вообще не задавались вопросом, что дальше делать с выдачей их кодогенераторов (за редким исключением), поэтому не знают о том, что в том же gcc/g++ есть режим семантического анализа программы, который как раз и нужен для семантической проверки программы без создания исполняемого кода. Как вариант использования этой функции, можно делать фоновую кодогенерацию и в фоне проверять семантику, чтобы на диаграмме в процессе рисования сразу показывать проблемные места. Суть того, что я показывал в чате, заключается в установлении связи между иконой на диаграмме со строкой на С/С++, что нужно не только для отладки, но и для ошибок в диаграмме. Теоретически, ошибок при компиляции в построенном по диаграмме коде быть не должно, но они всё равно будут на этапе отладки самой IDE, поэтому нужен механизм для проверки порождаемого кода.

Уважаемый tonyk, спасибо.

Алексей Муравицкий ознакомился с Вашим мнением и в чате языка Дракон++ написал:
ссылка

Алексей инженер-практик, поэтому хорошо понимает что надо делать и к чему стремиться. Я знаю об их целях и подходах к решению задач, поэтому демонстрировал подход к отладке с оглядкой на них. По-моему, Алексей с товарищами единственные, кто нацелен на получение полноценного продукта. Автор Фаланга, по-моему, задумался о корректировке цели своей работы в части создания не просто очередной рисовалки с генератором после нашего общения с ним.
То, что я показывал в чате, требует определённых знаний и умений. Можно сделать проще, но вполне достаточно для практического применения, а именно реализовать загрузку программы на выполнение в целевое устройство и получение текущих значений переменных с их отображением на диаграмме. Часть инструментов для этого идёт в комплекте с gcc, но часть придётся реализовать самим, в первую очередь протокол обмена между IDE и средой исполнения на целевом устройстве. Думаю, что такое немного упрощённое решение вполне по силам даже программистам-одиночкам.

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


Спасибо. Вы расписали план работ в своих интересах, но у меня другие интересы. Вы смотрите контекст технологии, мне необходим контекст методологии, причём методологии образования, в чём у меня есть хорошие авторы, навыки системного анализа и научный руководитель.
Текстовый формат диаграмм есть, просто вы, tonik, говорили о том, что он должен быть универсальным, а это уже вопросы не ко мне. В рамках моей работы универсальность не требуется. Если вспомнить недавнюю историю, то low-code/no-code платформы развивались каждой корпорацией по-своему: у Сименса была своя, у Майкрософта своя, и low-code/no-code остаётся нерегламентированным, но эффективным средством визуального программирования. Можете посмотреть, что Gartner об LCNC писали.

tonyk конечно уважаемый человек и эксперт в своей области, но взаимодействовать с Муравицким ему удаётся лучше.

Потому что она никому не нужна. Например, IDE для ПЛК просто загружают в контроллер помимо исполняемого кода сжатый исходный проект- и всё. Подключаешься к ПЛК и при выгрузке проекта получаешь его исходный текст/графику.

Он должен быть единым. Я ведь формат тоже не от балды описал. Такой формат в том или ином виде используется большим числом САПР для схем разных видов. Без единства формата не будет переносимости диаграмм из одной среды в другую, что существенно замедлит развитие Дракона как ЯП. Почему С популярен? Одна из причин в простоте переноса программ на разные процессорные архитектуры.

Вот и приходится нам, инженерам-практикам, заниматься реверс-инжинирингом японских ПЛК, писать рантаймы, чтобы пользоваться графическими языками стандарта ГОСТ Р МЭК 61131-3, реализованными японцами, пока учёный люд толчёт воду в ступе и занимается любомудствованием.