DRAKON.SU

Текущее время: Вторник, 19 Март, 2024 10:17

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 11 Апрель, 2022 11:07 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
Критические замечания участника tonyk о реализации языка ДРАКОН для ПЛК

tonyk писал(а):
Дракон — штука хорошая, правильная. Я сравниваю её с позиций ПЛК. Но есть одно "но", которое обнуляет ценность сегодняшней реализации Дракона.

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

Естественно, что в процессе отладки значения всех переменных должны отображаться прямо на схеме программы. Даже не говорю о том, что необходимо иметь возможность отладки и на "железном" контроллере, наблюдая значения переменных и имея возможность их изменять.

Как это выглядит и работает, можно посмотреть в любой среде разработки для ПЛК на примере графических языков FBD, LD, SFC.

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

Будь симулятор и графическая отладка, Дракон можно было бы встраивать в МК, получая полноценный ПЛК.

tonyk писал(а):
За питьём кофе полистал сайт. Ребята, вы в тупике. И будете в нём до тех пор, пока не появится текстовый формат языка Дракона.

Создание эргономичной среды программирования для Дракона- это весьма непростая задача. Сейчас и программирование, и кодогенерация под целевую платформу собраны в одном месте.
Зачем? Среда программирования на Драконе должна выдавать программу на Драконе.

Во-первых, так получится передавать программу между разными среда программирования.

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

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

Обязательно нужен формат обмена отладочной информацией между средой программирования и исполнения.

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

Пока сделайте главное, дайте описание текстового формата Дракона в БНФ.

tonyk писал(а):
Наличие текстового синтаксиса позволит выгружать схему в виде текстового описания алгоритма, который можно обратно загрузить в редактор.

Если в синтаксисе текстового языка предусмотреть команды позиционирования блоков, то можно более эргономично размещать графические блоки.

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

А самое главное- это отделение мух от котлет. В редакторе рисуется схема алгоритма, которая выгружается в виде текста, который уже можно транслировать в любой прикладной язык.

Даёшь Дракон в БНФ!


tonyk писал(а):
У меня есть свой проект по созданию ПЛК по стандарту ГОСТ Р МЭК 61131.

Свои мысли я тут высказываю с позиций разработчика ПЛК, по мнению которого проект "Дракон" уходит далеко от того, что нужно инженерам-практикам.

Более того, исходя из своего скромного опыта, я сильно сомневаюсь, что с нынешним подходом к разработке Дракон будет доведён до состояния, когда он будет массово использоваться, например, в ПЛК.

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

Повторюсь, я смотрю на Дракон с позиций разработчика ПЛК. Мне нравится концепция Дракона, будь у Дракона то, о чём я написал (текстовый формат, протокол обмена с рантаймом и т.п.), с удовольствием занялся бы переносом его на ПЛК.

Дракон и МЭК для меня- не конкуренты, это разные способы решения практических задач, поэтому я и делюсь своими мыслями и опытом.

tonyk писал(а):
Чему меня может научить Алексей Муравицкий, как ковылять на костылях с шильдиком "Дракон"? Я знаком со способом, который использует Алексей в работе с ПЛК.

Дабы прибить все споры на корню, просто ответьте на вопрос, почему кроме Алексея никто не использует Дракон на ПЛК?

почему тогда языки, созданные по такому "отсталому" стандарту, как ГОСТ Р МЭК 61131-3 существуют, развиваются и кормят их создателей, а чудо по названием "Дракон" за столько лет так и не доросло до уровня стандарта и остаётся игрушкой горстки энтузиастов?

tonyk писал(а):
Дракон ооочень коммерческий проект. Без открытой IDE, генерирующей на выходе что-то, пригодное для переваривания в МК, ИМХО, Дракон нафиг не нужен.

Не буду спорить с вашими маркетологами, которые выбрали такую стратегию продвижения Дракона, просто предложу обдумать, почему так популярны C, Codesys, Altium Designer и далее по списку.

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

Одним из преимуществ любого ПЛК является его массовость, которая позволяет всесторонне протестировать, в первую очередь, компиляторы и среду выполнения программ пользователя на целевом контроллере.

Ну, и по технике оказалось, что на Дракон вообще не предусмотрена работа с периферией контроллеров.

Нет даже упоминаний о низкоуровневой работе с регистрами периферии целевого контроллера, нет понятия "функциональный блок".

Не заметил возможности написания фрагментов программы на языках низкого уровня, например, С/С++ или ассемблер. Да много чего нет, без чего эффективное использование Дракона вряд ли возможно.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Дискуссия
СообщениеДобавлено: Среда, 15 Июнь, 2022 14:37 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 63
Владимир Паронджанов, вот иллюстрация того, о чём я говорил: отсутствие текстового формата диаграммы языка Дракон приводит к тому, что идёт распыление сил и времени разработчиков. Alex_st_Tomsk с товарищем сделали очередной редактор и генератор программы. Заметьте, очередной и непригодный для практического использования (Alex_st_Tomsk, без обид, дело не в тебе). Сколько ещё нужно вот таких игрушечных редакторов, чтобы осознать необходимость разделения редактора языка Дракон и кодогенератора в целевой язык? Сколько ещё нужно времени, чтобы создать формат обмена отладочной информацией между исполняемым кодом и редактором,а, по-сути, отладчиком для Дракона? Без этого Дракон так и будет игрой разума энтузиастов и темой студенческих работ.

Люди, которые создают редакторы, как показывает моё общение с ними, не работали в промышленности, не готовили документацию серьёзным заказчикам, поэтому не представляют, что нужно получить. У них просто нет такого опыта, хотя знаний достаточно для создания хорошего продукта. Грустно наблюдать, как хорошая задумка деградирует из-за, ИМХО, не правильного подхода к реализации.

Зайдя на этот форум через год, вряд ли найду здесь инструмент, пригодный для практической работы. А жаль...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Июнь, 2022 18:15 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
tonyk писал(а):
Владимир Паронджанов: отсутствие текстового формата диаграммы языка Дракон приводит к тому, что идёт распыление сил и времени разработчиков.
Тоник, спасибо за замечание.
Вы хорошо знаете, что проблема отчасти решена с помощью концепции гибридных языков:
Дракон-Си
Дракон-Си#
Дракон-Java
Дракон-JavaScript
и т. д.

Я понимаю так. Разработать текстовый формат диаграммы языка Дракон — значит разработать новый язык программирования.
Это очень сложная задача. Я за нее не берусь.

Я не отрицаю такую постановку вопроса, вовсе нет.
Если найдется человек, который возьмется за такую разработку, я буду его поддерживать.

Насчет практической работы. Алексей Муравицкий получил новый редактор (пробную версию), сделанный по его требованиям. Сейчас идет тестирование. Через месяц-другой он, надеюсь, об этом объявит. Посмотрим.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Июнь, 2022 07:56 

Зарегистрирован: Вторник, 27 Апрель, 2021 05:25
Сообщения: 100
Откуда: Томск
Позволю себе вмешаться в дискуссию, потому что последнее сообщение критиковало экзистенциальную природу нашей созданной среды. Согласен с Владимиром Паронджановым, что tonyk требует создания целого нового языка программирования. И не простого, а золотого. Обращаюсь к его цитате:
tonyk писал(а):
Среда программирования на Драконе должна выдавать программу на Драконе.

Во-первых, так получится передавать программу между разными среда программирования.
<...>
Обязательно нужен формат обмена отладочной информацией между средой программирования и исполнения.
Обязательно нужны расширения языка для взаимодействия с оборудованием целевой платформы, например, обработчики прерываний, запись-чтение в регистры управления периферийными устройствами и т.п.

Я не совсем понимаю возможность передачи текста условного "Дракон-формата" в разные среды программирования. То есть одна программа "Дракон-формата" должна быть "хамелеоном" и запускаться и как Сишный файл в условном CodeBlocks, и как файл ".java" в Apache NetBeans? Возможно ли это теоретически? Разные языки искали решения именно этой проблемы "кроссплатформенности". И решение в виде гибридного языка программирования не уникально для ДРАКОНа (вспомните Jython).

tonyk писал(а):
Не заметил возможности написания фрагментов программы на языках низкого уровня, например, С/С++ или ассемблер. Да много чего нет, без чего эффективное использование Дракона вряд ли возможно.

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

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

может я неправильно понял тему, если что, прошу прощения


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 15:47 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 63
Alex_st_Tomsk писал(а):
Я не совсем понимаю возможность передачи текста условного "Дракон-формата" в разные среды программирования. То есть одна программа "Дракон-формата" должна быть "хамелеоном" и запускаться и как Сишный файл в условном CodeBlocks, и как файл ".java" в Apache NetBeans?

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

Насчёт исполнения тоже интересная ситуация. Как проверить правильность работы нарисованной Дракон-схемы? Сейчас- никак. Сравните со средами разработки для ПЛК, в которых всегда есть симулятор, поэтому даже без загрузки программы в реальный ПЛК можно проверить работу алгоритма. Я уже не говорю о том, что в симуляторе обязательно есть отладка, чем даже не пахнет в Драконе. Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 17:13 

Зарегистрирован: Вторник, 27 Апрель, 2021 05:25
Сообщения: 100
Откуда: Томск
tonyk писал(а):
Каждый новый редактор Дракона хранит файлы в своём формате, поэтому для каждого нового редактора его автор создаёт свой формат. В итоге всё, что было создано ранее в других редакторах невозможно открыть в новом.

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

Я знал об ИС Дракон и "Фабуле", позже познакомился с DrakonHub и DrakonTech. Но мне изначально было дано задание: создать собственную "автономную" графическую среду программирования. Варианта совершенствования существующих даже не рассматривал. Может появится желание у случайных читателей этого форума. Но чтобы оно появилось, надо:
1. Признать недостатки среды, перечислить эти минусы
2. Выложить открытый код с внятным пояснением
3. При желании оставить свои контактные данные

Таким образом рано или поздно получится хорошая среда, соблюдающая все правила языка ДРАКОН, интерпретирующая схему в код на почти любом ЯП. Думаю, что в этом вопросе не будет кровавой погони за деньгами и славой, поэтому почему бы не сделать это (многоточие)

tonyk писал(а):
Насчёт исполнения тоже интересная ситуация. Как проверить правильность работы нарисованной Дракон-схемы? Сейчас- никак. Сравните со средами разработки для ПЛК, в которых всегда есть симулятор, поэтому даже без загрузки программы в реальный ПЛК можно проверить работу алгоритма. Я уже не говорю о том, что в симуляторе обязательно есть отладка, чем даже не пахнет в Драконе. Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.


Смотрел недавно вот это видео: https://www.youtube.com/watch?v=MFPqCqc ... rgeySmolov , в котором Владимира Даниловича спрашивают тоже самое. Как проверить правильность Дракон-схемы? Был ответ, что дракон-схема - это слепыш. Он не гарантирует правильность написания слов, не отслеживает контекст и прочее. А отладка дракон-схемы действительно относится к области фантастики и искусственного интеллекта. Тем не менее по этому поводу у нашего дуэта разработчиков была пара мыслей.
Возникала мысль встроить компилятор прямо в среду, а порядок исполнения отражать на подсветке ячеек дракон-схемы. Если в исполнении программы возникала ошибка, проводился анализ отчёта компилятора и относительно строки с ошибкой подсвечивалась проблемная икона. Из-за сроков и незначительного опыта разработки приложений мы даже не рассматривали внедрение компилятора. Всё осталось мыслями.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 18:10 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
Владимир Паронджанов писал(а):
Я понимаю так. Разработать текстовый формат диаграммы языка Дракон — значит разработать новый язык программирования.
Это очень сложная задача. Я за нее не берусь.
Нет, создание текстового формата диаграмм не означает автоматического создания полного языка программирования. Язык может, и это даже желательно, задаваться модульно - язык выражений, язык операторов, язык типов, язык подпрограмм и т.д. ДРАКОН - это язык операторов и подпрограмм, и плоско-текстовое, как и любое другое представление программы на ДРАКОН будет задавать только эту часть. Как это может выглядеть, можно посмотреть в PlantUML (но нежелательно, чтобы он выглядел именно так).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 18:22 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
tonyk писал(а):
Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.
С одной стороны ДРАКОН только декларируется таким, но решает лишь частные подзадачи вопроса, да и то не всегда лучшим образом. С другой стороны инструменты для создания надёжных программ не полагаются на интерактивную отладку, так как она показывает лишь частные случаи использования, а для надёжности необходимо размышления для всех случаев, что возможно лишь в формальном доказательстве, пусть и неполном или хотя бы в многочисленных тестах. Если свой собственный код нужно исследовать в пошаговом отладчике(что я такое сделал?), то ни о какой надёжности речи быть не может. Как-то заставить работать, конечно, помогает(~90% индустрии).

tonyk писал(а):
Посмотрите на clang, именуемый в народе "шлангом". Программы на любых языках транслируются в промежуточное представление, которое хоть интерпретируй, хоть транслируй в машинный код целевого процессора.
И обратите внимание, что это просто очередной собственный внутренний формат


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 18:32 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 63
Alex_st_Tomsk писал(а):
Насчёт формата, в таком случае, могу ответить, что это легко решить обыкновенной договорённостью между разработчиками.

Это должно быть явно прописано. Отсутствие текстового формата диаграммы- это слабое место Дракона.
Alex_st_Tomsk писал(а):
А отладка дракон-схемы действительно относится к области фантастики и искусственного интеллекта

Нет тут никакой фантастики и ИИ. Просто нужно кое-что немного детерминировать перед рисованием, и тогда Дракон можно будет транслировать в свой Дракон-код, который хоть интерпретируй, хоть транслируй в Си, Ява или иврит :))). В Инете есть несколько проектов рисования программ в виде блок-схем, которые транслируются в исполняемый код, а тут имеется супер-логичный графический язык, который невозможно перевести в исполняемый код? Парни, вы чё-то не догоняете... ;)

Толку от красивой Дракон-схемы, которую нельзя проверить без загрузки на исполнение на реальном "железе", будет чуть больше нуля, поэтому, ИМХО, нужна проверка правильности её работы. Ну, посмотрите, поработайте чуток с ПЛК, полистайте учебники по построению трансляторов- и магия уйдёт, освободив место среде исполнения Дракона.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Июнь, 2022 09:51 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
Уважаемые коллеги!

Благодарю всех, кто принял участие в дискуссии.
Моя позиция такова.

1. Массовое применение языка программирования ДРАКОН возможно (в качестве гибридного языка).

2. Массовое применение языка программирования ДРАКОН произойдет в следующей области:
Цитата:
программируемые логические контроллеры;
— сенсорные программируемые контроллеры;
— сенсорные панельные контроллеры;
микроконтроллеры; см.
программируемые (интеллектуальные) реле;
робототехника; см.

3. Опытными специалистами по программированию ПЛК (программируемых логических контроллеров) являются:
— Алексей Муравицкий,
— tonyk.

4. Муравицкий и tonyk имеют разные точки зрения. Кто из них окажется прав, покажет время.

5. Муравицкий работает над созданием нового ДРАКОН-редактора, пригодного для эффективного программирования ПЛК.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Июль, 2022 09:19 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
Скопировано отсюда https://bit.ly/3oBVauE
Alex_st_Tomsk писал(а):
Но вы ведь сами поднимали вопрос наглядности. У нас - редактор, у пользователя - компилятор. А мы хотели бы, чтобы всё было у нас и пользователь не жонглировал своими средствами.

tonyk писал(а):
Посмотрите, как это сделано в Экслипсе в свете концепции перспектив. Впрочем, скорей всего, пример консольного gdb будет понятней и проще реализуем. Окно приложения одно, но в нём отображается или редактор, или отладчик.

Если Дракон-редактор отделён от Дракон-компилятора, то нет разницы в какой язык транслировать Дракон, и на каком языке его отлаживать. Тут, по-моему, сложнее будет придумать, как настроить взаимодействие Дракона и целевой платформы. В идеале модуль привязки к целевой платформе должен быть отделён от редактора. На выходе модуля привязки make-файл для GCC. Кстати, я не увидел в Дракон-редактора явно функции создания модулей программы и многолистовых схем. Про отсутствие нормальной печати с разбивкой на листы, на которых автоматически расставлены межлистовые ссылки, уже писал тут: https://forum.drakon.su/viewtopic.php?f=62&t=6996&start=160.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Июль, 2022 19:54 

Зарегистрирован: Среда, 27 Июль, 2022 16:21
Сообщения: 26
Считаю критику Tonyk не релевантной.
С таким же успехом можно предъявлять его критику к языку моделирования UML.
Дракон - это способ мышления и понимания потока данных, идущих с начало алгоритма до конца.
Под потоком данных можно понимать и поток объектов:
- Движение денег от одного счета дебета на другой счет кредита и на следующий счет и т.д.
- Движение автомобилей.
- Движение мыслей.
- Движение любого объекта.
Да мало ли каких движений можно алгоритмизировать.

Дракон это тот же UML и предъявлять к нему требования IDE и чтоб дебагер был и чтоб проверка переменных была, это мягко говоря требовать от мужика чтоб он рожал как женщина.
Это язык моделирования, который позволяет писать код с коротким главным маршрутом и короткими побочными маршрутами.
Другими словами позволяет избавится от говнокода и спаггети кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Июль, 2022 15:12 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 63
tur55 писал(а):
С таким же успехом можно предъявлять его критику к языку моделирования UML.

UML никогда не позиционировался как язык программирования, поэтому к нему моя критика никакого отношения не имеет. Как язык описания- да, так он для этого и был создан. Но он не был создан для программирования!
tur55 писал(а):
Дракон это тот же UML и предъявлять к нему требования IDE и чтоб дебагер был и чтоб проверка переменных была, это мягко говоря требовать от мужика чтоб он рожал как женщина.

Да ну! А tur55 имеет опыт работы с графическими языками программирования? Похоже, что нет, раз воспринимает графические языки лишь как инструмент моделирования, а не языки программирования.

tur55 писал(а):
Дракон это тот же UML

А вот на этот вопрос пусть ответят адепты Дракона. Если Дракон нужен только для описания, а не для программирования, то я не правильно понял концепцию Дракона и мне тут делать нечего.
Вопрос: Дракон- это язык описания или язык программирования?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Июль, 2022 15:27 

Зарегистрирован: Среда, 27 Июль, 2022 16:21
Сообщения: 26
Дракон язык описания и алгоритмирования в первую очередь, он предназначен для инженеров которые не знают языки программирования.
Смотрите Видео в котором сам Паронджанов говорил.
Это не язык программирования.
Он описывает алгоритмы для языков программирования.
Впрочем не только для языков программирования,
Для медицины, для бизнеса, да мало ли для чего.
Все прочее в нем это кодогенерации на основе эргономичного алгоритма.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Июль, 2022 16:10 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 63
tur55 писал(а):
Он описывает алгоритмы

Вот именно. Алгоритм для того и описывают, чтобы исполнять, а не измышлять о релевантности нахождения сферического коня в вакууме. Сравните с UML, который определяет сущности и способы их взаимодействия, но не даёт ответа на вопрос о том как реализовать этот способ взаимодействия.
tur55 писал(а):
Смотрите Видео

Мне незачем смотреть Видео, я читать умею. "Видео" умышленно написано с заглавной буквы? Это что-то родственное Библии?
tur55 писал(а):
Это не язык программирования.

Подожду ответ самого Паронджанова.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Июль, 2022 19:01 

Зарегистрирован: Среда, 27 Июль, 2022 16:21
Сообщения: 26
Вот ответ самого Паронджанова
на видео с маленькой буквы.
https://youtu.be/MFPqCqcv7kY?t=1649
27 минута 29 секунда.

Цитата из видео: "Инженеры делают исходный код, а остальное дорабатывают программисты."
И ссылка вам в помощь https://drakon.su/_media/video_i_prezen ... _rana_.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Июль, 2022 21:41 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
tur55 писал(а):
Это не язык программирования.

tonyk писал(а):
Подожду ответ самого Паронджанова.

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

Ответ дан, например, в моей книге "Алгоритмы и жизнеритмы" глава 31 стр. 295. https://drakon.su/_media/23_zhizneritm22.pdf
Цитата:
СЕМЕЙСТВО ДРАКОН-ЯЗЫКОВ

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

Императивную (процедурную) часть языка ДРАКОН можно присоединить к некоторым языкам программирования и получить гибридные языки, например:

язык Дракон + язык С = гибридный язык Дракон-С

язык Дракон + язык Java = гибридный язык Дракон-Java

язык Дракон + язык С# = гибридный язык Дракон-С#

язык Дракон + язык Python = гибридный язык Дракон-Python

язык Дракон + язык JavaScript = гибридный язык Дракон JavaScript

язык Дракон + язык Lua = гибридный язык Дракон-Lua

язык Дракон + язык Erlang = гибридный язык Дракон-Erlang

язык Дракон + язык Ada = гибридный язык Дракон-Аdа

язык Дракон + язык Оberon = гибридный язык Дракон-Оberon

язык Дракон + язык Tcl = гибридный язык Дракон-Tcl
и т. д.

КАК ПОСТРОИТЬ ГИБРИДНЫЙ ЯЗЫК ДРАКОН-СИ

Чтобы построить язык Дракон-Си, надо по определенным правилам соединить графический синтаксис ДРАКОНа с текстовым синтаксисом языка Си. При этом Си рассматривается как целевой язык (target language). Нужно сделать следующее:

 использовать синтаксис целевого языка (синтаксис языка Си) в качестве текстового синтаксиса гибридного языка Дракон-Си;

 удалить из текстового синтаксиса гибридного языка Дракон-Си все элементы, которые заменяются управляющей графикой ДРАКОНа;

 создать транслятор из дракон-схемы в исходный код языка Си.

Читать дальше


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Июль, 2022 06:52 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 63
То есть визуальный язык описания действий, приводящий к решению задачи, низвели до уровня банальной рисовалки. Н-да... Что ж, рисуйте, а покину, как и обещал, сей форум.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Июль, 2022 09:37 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
tonyk писал(а):
визуальный язык описания действий, приводящий к решению задачи, низвели до уровня банальной рисовалки.
Это не так. Язык ДРАКОН позволяет программировать.
Приведу два примера

1 пример.

2 пример.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Июль, 2022 13:16 

Зарегистрирован: Среда, 27 Июль, 2022 16:21
Сообщения: 26
Похоже что с терминалогией у Дракон-Технологии есть проблемы.
Если используется три уровня абстракции
Алгоритм
Алгоритм + программа
Программа

В данном случае от Общего к Частному.

Человеку который работал на уровне КОДА (программы) перейти на описательный язык высшего уровня (Алгоритм) трудно, он и будет использовать парадигму кода в парадигме Алгоритма. Проблема Багажа опыта. К новому явлению походить используя опыт прошлого.
И в свою очередь наоборот.
Человек который привык работать на уровне Алгоритма (Управленцы, бизнесмены, менеджеры, инженеры) сложно перейти в парадигму КОДА (программирования). Будет использоваться описательный язык алгоритма для кода.
(нельзя использовать в коде операторы & (И), ! (НЕ), | (ИЛИ), ^ (исключающее ИЛИ))

Хочу сказать что проблемы гибридизации приводят к тому, что смыслы и понятия для низшего уровня (программа) нельзя использовать на высшем уровне. И наоборот смыслы и понятия высшего уровня (алгоритм) нельзя использовать на низшем уровне.
Инженеры не понимают программистов, программисты не понимают инженеров, хотя говорят на одном языке. Инженеры и программисты по разному понимают одни и те же термины.
Это техническое и психологическое противоречие.
Которое и должна решить гибридизация.

А это значить что терминология программистов-кодеров не должна совпадать с терминологией эргономичных алгоритмов Дракона.
И замена программисткого "IF" на драконовское "Вопрос" правильный ход.
Тогда и "Цикл" надо менять на "Повтор"
"Повтор с пред условием", "Повтор с пост условием", Повтор со счетчиком.
"Таймер" - "Отсчет"
Вообще всю терминологию в Драконе заменить на русские аналоги.
А вообще в качестве Действий (Внутри Икон) должны быть написаны ГЛАГОЛЫ, а не Существительные.
Повтор - Повторить
Таймер - Отсчет - Отсчитать


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB