DRAKON.SU

Язык Дракон++ Алексея Муравицкого

Мне кажется, нужно ввести новое понятие «язык Дракон++», автор этого языка Алексей Муравицкий.

В телеграм-канале Муравицкий писал: ООП — объектно-ориентированное программирование.

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

Я считаю это дополнение важным, правильнее всего считать, что Алексей Муравицкий создал новый язык, и этому новому языку следует присвоить имя «язык Дракон++».
По аналогии с языками С и С++.

Конечно, Дракон++ намного проще, чем С++, тем не менее, он обладает некоторыми свойствами ООП, достаточными для практического программирования ПЛК (программируемых логических контроллеров).

Муравицкий вряд ли будет описывать новый язык, но это не беда. Алексей показывает примеры программ, написанных на языке Дракон++ и дает подробные комментарии.

Подробнее см. https://t.me/Dracon_Lang

Я писал в соответствующем чате Telegram своё мнение. Разверну сюда свою мысль об идее сделать Дракон объектно-ориентированным.

Мы пытаемся смешать всё воедино, сделать из Дракона швейцарский нож, что не совсем правильно, если совсем не правильно. Пытаемся сделать Дракон-схемы и диаграммами состояний, и диаграммами потоков данных, и диаграммами бизнес-процессов, хотя самая близкая по концепции ниша - это диаграммы деятельности и диаграммы последовательностей (activity diagram, sequence diagram).
Теперь об ООП. Алексей Муравицкий не описал подробно концепцию ООП в Драконе в нашем чате. Это преувеличение. Не написано, как в Драконе реализуется описание свойств, методов, принципов ООП (абстракция, инкапсуляция, наследование, полиморфизм). Поэтому концепцию пока нельзя считать полной, на мой взгляд. По крайней мере подождём ответа и дальнейших сообщений от самого Алексея, либо увидим сами эти принципы в его демонстрации нового редактора дракон-схем.

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

С точки зрения самого языка, цельная логическая конструкция - это примитив либо силуэт. Для гибридного языка ДРАКОН-Си, ДРАКОН-Python и т.д. эта конструкция интерпретируется никак иначе как функция.
Класс в объектно-ориентированном программировании - это тоже цельная логическая конструкция. Но для её обозначения у ДРАКОНа нет иных средств кроме тех же примитива и силуэта. Стало быть возникает конфликт (даже не столько для программиста, сколько для пользователя этим редактором) - как отличить класс от функции в ДРАКОНе, если вдруг и то, и другое станет реализуемо в редакторах? Это задача и проблема, которая затрагивается предложением языка Дракон++.

Из принципа "критикуешь-предлагай" могу сказать, что понятия "класса" и "функции" нужно разграничивать. То есть для описания классов использовать другой метод, другую нотацию, связанную с ДРАКОНом. И такая нотация есть. Из недавнего экскурса по книге "Почему мудрец похож на обезьяну..." Владимира Паронджанова я вычитал такой язык как ГРАФ. Язык дефиниций. Он не описывает последовательности, он именно даёт определения. Он - тот самый словарь, который не нужно выдавать за роман.
Применительно к классам ГРАФ-схема представляет собой шаблонную конструкцию - имя класса с всегда тремя ветвями - свойства, методы, события. Следующий уровень детализации уже зависит от самого описания класса. Какая-то ветвь может и вовсе оказаться пустой.

Например, сейчас Алексей Муравицкий постепенно презентует работу своего редактора дракон-схем для ПЛК на примере светофора. Светофор можно описать как класс при помощи языка ГРАФ. Причём этот язык может описать не только класс, но и структуру - тоже важную часть в ООП. Например, светофор обладает свойством "свет". Это структура, состоящая из двух ключей - цвет (красный, жёлтый, зелёный) и длительность (1 секунда, 2 секунды, 4 секунды).

Каждый метод и событие класса уже можно описать в виде дракон-схемы, так как они по природе своей функции.
Таким образом, при помощи языка ГРАФ можно обособленно описать классы (а то и целое пространство имён).

Из сегодняшней дискуссии в чате Telegram было сделано несколько выводов, важных замечаний.

Первое замечание: Дракон++ не имеет ничего общего с ЯП С++. Плюсы в его названии означают доработку методологии таким образом, чтобы с помощью дракон-схем описывать не только функции, но и функциональные блоки (ФБ)
Второе замечание: Дракон++ используется для проектирования работы ПЛК и микроконтроллеров. Основным языком для интерпретации схемы является ST. В третьей редакции языка ST были введены элементы объектно-ориентированного программирования, выраженные как раз-таки в функциональных блоках. Мнение об ООП в ST разное . Но важно утверждать одно - ООП в языке ST не такое же как ООП в популярных языках программирования (С++, Python, Java). За особенностями реализации лучше обратиться к учебным пособиям, таким как книга Сергея Романова "Изучаем Structured Text стандарта МЭК 61131-3".
Из этого можно сделать поправки к моему сообщению выше. Описанный способ представления класса на языке ГРАФ не применим к языку ST, да и в общем-то говоря, к другим языкам тоже, ведь с помощью ГРАФа не продемонстрировать принципы наследования и полиморфизма.
Поэтому, решая вопрос создания системы по поддержке гибридного языка Дракон-ST, нужно учесть особенности языка ST, сколь бы очевидным этот вывод ни казался.
Касательно поддержки ООП в языках Дракон-Python, Дракон-Java, у меня появилась мысль симбиоза языка Дракон и диаграммы классов UML. Идею можно будет развить и доработать в будущих исследованиях. На сегодняшний день приступать к ним у меня нет причин, да и ход этих исследований не будет соответствовать текущей теме форума.