ganqqwerty Язык ДРАКОН можно присоединить к некоторым языкам программирования и получить так называемые гибридные языки, например: Дракон-С, Дракон-Java, Дракон-C#, Дракон-Python, Дракон-Javascript, Дракон-Tcl, Дракон-Erlang, Дракон-Lua и др.
Во всех случаях графика ДРАКОНа остается неизменной. А внутри графических фигур пишут код согласно правилам выбранного языка программировния: С, Java, C#, Python, Javascript, Tcl, Erlang и т.д.
Я описал «визуальное логическое исчисление» в журнале «Программирование» в 1995 г. («Графический синтаксис языка ДРАКОН») и в ряде книг (см. мой профиль).
Это теоретическая основа языка ДРАКОН.
Профессор А.Н. Степанов в «Курсе информатики для студентов информационно-математических специальностей» (2018) отмечает:
«Обсуждаемый подход… был развит в процессе создания отечественного графического языка программирования ДРАКОН… Чтобы получить полноценный язык программирования, необходимо было создать математически строгий метод формализации… Для решения этой задачи был разработан специальный математический аппарат — визуальное логическое исчисление иконок, который стал теоретической основой языка ДРАКОН… Язык двумерного структурного программирования ДРАКОН является полным по Тьюрингу и относится к универсальным языкам программирования… Написание программы становится более понятным и удобным для человека, повышается производительность труда программистов» [15, pp. 1017-1019].
abondarev затронул важную проблему. Существует потребность в безопасных языках. Язык ДРАКОН — попытка создать безопасный визуальный язык.
На практике используется, в частности, гибридный язык Дракон-Си, где Си служит целевым языком. При этом си-код не пишут вручную; он формируется автоматически на выходе дракон-схемы (комплекта дракон-схем). Вероятность ошибки уменьшается или сводится к нулю.
Цель языка ДРАКОН — обеспечить безопасность потока управления.
Вообще странное утверждение. Из которого следует чем сложнее алгоритм тем легче в нем ошибиться, потому что текста много. Можно подумать на драконе ничего для описания этого же алгоритма делать не надо будет. Ну будут у вас не такие ошибки как на классических языках. Будут другие. Разница то в чем?
Разница в том, что на ДРАКОНе ошибок будет меньше или не будет совсем.
Сергей Ефанов поясняет:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу! Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
Ну не записали вы их вручную. Ну автоматически будет сгенерировано. Сгенерировано будет все равно исходя из того что вы задали на входе. А если вы на входе зададите неправильно, что ветвления правильными вдруг станут?
Вероятность того, что вы на входе (т.е. в дракон-схеме) зададите неправильно, очень мала. потому что ДРАКОН срывает с ошибок «шапку-невидимку». Ошибки «сами лезут в глаза», поэтому пользователь (с большой вероятностью) их не сделает. На это есть две причины.
1) дракон-схема строится по правилам когнитивной эргономики, которая обнажает ошибки или лишает пользователя возможности сделать ошибку.
2) Графика дракон-схемы формируется программой дракон-конструктор, на основе визуального логического исчисления по правилам визуального логического вывода.
Это значит, что (во избежание ошибок) пользователю языка ДРАКОН запрещено проводить линии между иконами дракон-схемы. Все линии автоматически проводит дракон-конструктор, а пользователь лишь управляет этим процессом, указывая какую икону (или макроикону) выбрать и в какую валентную точку ее вставить. Это вкратце.
Разумеется, записывая текст внутри иконы, пользователь может ошибиться, но это будет ошибка ЛИНЕЙНОГО участка, которую сравнительно легко можно выявить и устранить.
Автор языка Оберон Николаус Вирт, вложил идею внесения ограничений, что существенно уменьшает риск написания небезопасного ПО. При этом с помощью доработки компилятора автор доклада, предлагает создавать образы, нацеленные на различные задачи и платформы. Доклад был мне очень близок, поскольку мы в Embox пришли к похожим идеям по ограничениям.
Вы правы. Продуманные ограничения уменьшают риск написания небезопасного ПО.
Вспомним. Эдсгер Дейкстра ввел ограничение, указав на опасность goto.
Затем Бертран Мейер ввел ограничение, указав на опасность break и continue.
Развивая линию Дейкстры-Мейера, можно ввести дополнительные ограничения, указав на небезопасность служебных слов, организующих поток управления: goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и их аналогов.
Исходя из этих соображений, в визуальном языке ДРАКОН (во имя безопасности потока управления) исключены опасные служебные слова, организующие поток управления: goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и т.д. Вместо них используется математически строгая графика управления, которая реализует ту же самую функцию, что и перечисленные служебные слова.
В чем идея? Наибольшую вероятность появления ошибок создают разветвления и циклы. То есть конструкции, описываемые указанными служебными словами.
При использовании языка ДРАКОН функции, реализуемые указанными служебными словами, не записываются вручную, а формируются автоматически. Поэтому вероятность ошибок, вызванных разветвлениями и циклами, уменьшается или сводится к нулю.
Таким образом, при использовании ДРАКОНа (при описании потока управления) остаются лишь опечатки и ошибки, появляющиеся на ЛИНЕЙНЫХ участках программ. Однако такие ошибки можно сравнительно легко выявить и устранить.
Паронджанов В. Д. Алгоритмы и жизнеритмы. Основы алгоритмизации. Быстрый способ изучить алгоритмы. — М.: Препринт, 2018. — 313 с. drakon.su/_media/zhizneritm.pdf
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Это вопрос инженерного «маркетинга» и стремление назвать свое творение как-то иначе, даже если оно по сути, принципиально то же самое.
Это лишь новое название для старого принципа — сведение программирования к языку, понятному предметникам. В случае Фортрана — математикам.
Вы правы и я согласен с вами. Ваша трактовка насчет Бэкуса, Фортрана и математиков изящна и обогащает содержание обсуждения.
Почему же, чем именно они отличаются? Судя по приведенным примерам (например, 4 видео про замок, рекомендованные вами) это именно блок-схемы. Не те, что гостированы, но вариация оных.
Говоря кратко блок-схемы не эргономичны, не формализованы, не структурированы, не упорядочены.
Дракон-схемы, напротив, лишены подобных недостатков и во всех отношениях превосходят их. Чтобы пояснить эти слова, нужно ввести новую систему понятий, новые критерии и новую теорию. Для этой цели я написал ряд книг:
Паронджанов В. Д. Как улучшить работу ума (новые средства для образного представления знаний, развития интеллекта и взаимопонимания). — М.: Радио и связь, 1998, 1999. — 352 с.
Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто. — М.: Дело, 2001. — 360 с.
Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. Как улучшить работу ума без лишних хлопот. — М.: ДМК-пресс, 2010, 2014, 2016. — 464 с.
Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с.
Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.
Паронджанов В. Д. Алгоритмы и жизнеритмы. Основы алгоритмизации. Быстрый способ изучить алгоритмы. — М.: ДМК Пресс, 2019. — 300 с. Это пока еще рукопись
есть ли стандарт языка, инженерное (не учебное) описание и сравнение с аналогичными решениями? Все как всегда — предлагая новое, надо делать анализ имеющегося.
Сравнение с имеющимся в моих книгах есть. Формального стандарта языка нет, но есть почти равноценное стандарту техническое задание на разработку программы «дракон-конструктор».
Несколько энтузиастов создали свои варианты дракон-конструктора.
Например, дракон-конструктор Степана Митькина имеет открытый код и позволяет преобразовывать дракон-схемы в исходный код 13 целевых языков: Java, Processing, D, C#, C/C++ (with Qt support), Python, Tcl, JavaScript, Lua, Erlang, AutoHotkey и Verilog.
John Backus said during a 1979 interview with Think, the IBM employee magazine, «Much of my work has come from being lazy. I didn't like writing programs, and so, when I was working on the IBM 701, writing programs for computing missile trajectories, I started work on a programming system to make it easier to write programs.»[12]
Спасибо за интересную цитату их Бэкуса. Но в этой цитате нет термина «программирование без программистов.
Как видите, «система трансляции математических формул для расчетов траекторий ракет» появилась в 1954 от того, что человек не хотел писать программы (в терминологии тех лет — на мнемокоде).
Вы трактуете „программирование без программистов“ расширительно, я же склонен обращаться к первоисточнику (Джеймс Мартин), где этот термин впервые появился.
Продвигаемая вами идея отличается только способом формализации алгоритма — в виде блок-схемы.
Моя идея — соединить идею алгоритма с идеей когнитивной эргономики. Полученный результат некорректно называть блок-схемами. Дракон-схемы принципиально отличаются от блок-схем.
Приведенные статьи не дают обзора принимаемых при создании языка решений, нет сравнения с другими инструментальными средами при решении тех же задач.
Принимаемые при создании языка ДРАКОН решения описаны в моих книгах.
Наиболее полно — в книге
Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК-Пресс, 2012, 2014, 2016. — 520 с. — Иллюстраций 272.
«Программирование без программистов» появилось очень давно — с появлением языка Фортран, идеей которого было дать математикам возможность общаться с машиной «без этих ваших программистов, которые бубнят об адресах и переходах». Только очень быстро оказалось, что составление инструкций на Фортране — это тоже программирование.
Это не совсем так.
История идеи «программирование без программистов» выглядит иначе.
ПРЕДЛОЖЕНИЕ ДЖЕЙМСА МАРТИНА
В 1982 году известный специалист по информатике Джеймс Мартин опубликовал книгу под названием «Прикладное программирование без программистов»:
James Martin. Application Development without Programmers, Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1982. 350 pp.
В этой книге Мартин утверждает, что с появлением непроцедурных языков появилась возможность предоставлять пользователям средства, которые позволяют им самим создавать программы.
Для справки приведу аннотацию к этой книге.
Applications development without programmers, James Martin, Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 1982. 350 pp. (ISBN 0-13438943-9).
With the development of comprehensive nonprocedural languages, many organizations have found significant benefit in providing users with the tools to meet their own information processing requirements.
The author reviews the capability of such offerings including query facilities, report generators, graphics languages, applications generators, very-high-level programming languages, and parameter-driven applications packages.
Each development methodology is illustrated with scenarios from applications created using commercially available software. The implementation of these capabilities has significant implications for the entire data processing organization. Also discussed are management considerations for the implementation, control, and operation of an Information Center.
НОВОЕ НАПРАВЛЕНИЕ ИССЛЕДОВАНИЙ
Книга Мартина дала начало новому направлению исследований, которое обычно для краткости называют «Программирование без программистов» (хотя фактически речь идет только о программировании без ПРИКЛАДНЫХ программистов»).
Чтобы оценить масштаб и разнообразие ведущихся исследований, можно задать в Гугле запрос «Программирование без программистов»
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Вы повторяете недостоверные сведения (анекдоты), которые не имеют отношения к действительности и серьезной работе. Инженеры разрабатывают на языке ДРАКОН по методу " программирование без программистов" исходный код программы (а не картинки, как вы предположили). Прочитайте статьи, на которые я дал ссылки. После этого многие вопросы отпадут.
Вы правы, получаемая модель памяти загружается в БЦВМ (и НЦВМ) Бисер.
Именно для этого и служит дракон-технология в Роскосмосе.
Если же вы хотите работать не с Бисером, а с другим компьютером или контроллером,
надо использовать технологию Степана Митькина, как это делают в Немецком космическом агентстве (см. ссылку, которую я дал). Или технологию Геннадия Тышова. Или разработайте свою собственную.
на языке ДРАКОН можно делать лишь «поделки», «что называется, упаси господи»
Это не так. На визуальном языке ДРАКОН делаются серьезные вещи.
Вот две статьи, где говорится про применение языка ДРАКОН в серьезных космических проектах:
1. Морозов В. В., Трунов Ю. В., Комиссаров А. И., Пак Е. А., Жучков А. Г., Дишель В.Д, Залихина Е. Е., Паронджанов В. Д. Система управления межорбитального космического буксира «Фрегат» \ Вестник ФГУП «НПО им. С. А. Лавочкина», 2014, № 1. — С. 16-25. bit.ly/2RtCdaU
2. Паронджанов В.Д. Визуальный алгоритмический язык ДРАКОН в ракетной технике и
медицине // Современные автоматизированные системы управления реального
времени как прикладное развитие научных достижений кибернетики» (К 100-летию со
дня рождения И.А. Полетаева). Материалы межведомственной конференции 24
марта 2016 г. — ФГБУ «3 ЦНИИ» Минобороны РФ, 2016. — 218 с. — С. 57-78. bit.ly/2BDhYCB
Вот еще одна статья, где речь идет о применении языка ДРАКОН в Немецком космическом агентстве (German Aerospace Agency).
Marc Schwarzbach, Sven Wlach, Maximilian Laiacker. Modifying a Scientific Flight Control System for Balloon Launched UAV Missions // German Aerospace Center DLR // IEEE, 2015. drakon.su/_media/ballon_ap_final.pdf
С большим интересом прочитал статью.
Рекомендую желающим сопоставить предлагаемые в статье правила с эргономическими правилами визуального языка ДРАКОН. bit.ly/1UQ4zuU
Вы обнаружите большое (хотя и не полное) сходство
С уважением,
Владимир Данилович Паронджанов, Москва, Роскосмос
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Станислав Федорович, спасибо за интересную и детальную информацию.
Я обратил внимание на слова:
Графические иллюстрации алгоритмов
В качестве графических иллюстраций алгоритмов компьютерных программ чаще всего используются блок-схемы алгоритмов.
При подготовке фигур, содержащих блок-схемы алгоритмов, целесообразно придерживаться одной из наиболее распространенных систем графических обозначений – ГОСТ 19.701-90 (ISO 5807:1985) [2] или унифицированного языка моделирования UML [3].
Альтернативные способы визуализации алгоритмов, например, визуальный язык ДРАКОН, псевдокод, диаграммы Насси-Шнейдермана и т.п., также применимы, однако они менее удобны для этой цели из-за их ограниченной известности.
Все написано правильно. Но полезно спросить: Что нас ждет в будущем?
Каковы перспективы?
По моему мнению, язык ДРАКОН обеспечивает наилучшую понятность алгоритмов для читателей патентов по сравнению с конкурирующими нотациями.
Будущее в патентном деле принадлежит ДРАКОНу.
Если Вы, Станислав Федорович, хотите приблизить будущее, я готов Вам всячески помогать.
Приведу цитату из сети:
Если нужно рисовать алгоритм, теперь только и только на Драконе.
Считаю, что он должен стать государственным стандартом для блок-схем вместо существующего.
Удивительно, что авторы книг продолжают использовать прежние схемы, на которые после Дракона без ужаса смотреть невозможно
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
0
Во всех случаях графика ДРАКОНа остается неизменной. А внутри графических фигур пишут код согласно правилам выбранного языка программировния: С, Java, C#, Python, Javascript, Tcl, Erlang и т.д.
А жаль
Я описал «визуальное логическое исчисление» в журнале «Программирование» в 1995 г. («Графический синтаксис языка ДРАКОН») и в ряде книг (см. мой профиль).
Это теоретическая основа языка ДРАКОН.
Профессор А.Н. Степанов в «Курсе информатики для студентов информационно-математических специальностей» (2018) отмечает:
Цитату Сергея Ефанова я взял из его статьи «Программирование микроконтроллеров на ДРАКОНе».
Возможно, вы измените мнение, если прочитаете статью
На практике используется, в частности, гибридный язык Дракон-Си, где Си служит целевым языком. При этом си-код не пишут вручную; он формируется автоматически на выходе дракон-схемы (комплекта дракон-схем). Вероятность ошибки уменьшается или сводится к нулю.
Цель языка ДРАКОН — обеспечить безопасность потока управления.
anatolymik писал:
Разница в том, что на ДРАКОНе ошибок будет меньше или не будет совсем.
Сергей Ефанов поясняет:
anatolymik писал:
Вероятность того, что вы на входе (т.е. в дракон-схеме) зададите неправильно, очень мала. потому что ДРАКОН срывает с ошибок «шапку-невидимку». Ошибки «сами лезут в глаза», поэтому пользователь (с большой вероятностью) их не сделает. На это есть две причины.
1) дракон-схема строится по правилам когнитивной эргономики, которая обнажает ошибки или лишает пользователя возможности сделать ошибку.
2) Графика дракон-схемы формируется программой дракон-конструктор, на основе визуального логического исчисления по правилам визуального логического вывода.
Это значит, что (во избежание ошибок) пользователю языка ДРАКОН запрещено проводить линии между иконами дракон-схемы. Все линии автоматически проводит дракон-конструктор, а пользователь лишь управляет этим процессом, указывая какую икону (или макроикону) выбрать и в какую валентную точку ее вставить. Это вкратце.
Разумеется, записывая текст внутри иконы, пользователь может ошибиться, но это будет ошибка ЛИНЕЙНОГО участка, которую сравнительно легко можно выявить и устранить.
Вы правы. Продуманные ограничения уменьшают риск написания небезопасного ПО.
Вспомним. Эдсгер Дейкстра ввел ограничение, указав на опасность goto.
Затем Бертран Мейер ввел ограничение, указав на опасность break и continue.
Развивая линию Дейкстры-Мейера, можно ввести дополнительные ограничения, указав на небезопасность служебных слов, организующих поток управления: goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и их аналогов.
Исходя из этих соображений, в визуальном языке ДРАКОН (во имя безопасности потока управления) исключены опасные служебные слова, организующие поток управления: goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и т.д. Вместо них используется математически строгая графика управления, которая реализует ту же самую функцию, что и перечисленные служебные слова.
В чем идея? Наибольшую вероятность появления ошибок создают разветвления и циклы. То есть конструкции, описываемые указанными служебными словами.
При использовании языка ДРАКОН функции, реализуемые указанными служебными словами, не записываются вручную, а формируются автоматически. Поэтому вероятность ошибок, вызванных разветвлениями и циклами, уменьшается или сводится к нулю.
Таким образом, при использовании ДРАКОНа (при описании потока управления) остаются лишь опечатки и ошибки, появляющиеся на ЛИНЕЙНЫХ участках программ. Однако такие ошибки можно сравнительно легко выявить и устранить.
bit.ly/2Mlg4Ou
bit.ly/1UQ4zuU
habr.com/ru/post/345320
drakonhub.com/files/pe_drakon_automata_mitkin_2019.pdf
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Благодарю вас.
Кое-что можно скачать бесплатно
Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто. — М.: Дело, 2001. — 360 с.
bit.ly/2AQaZV1
Паронджанов В. Д. Язык Дракон. Краткое описание.— М., 2009. — 124 с.
drakon.su/_media/biblioteka/drakondescription.pdf
Паронджанов В. Д. Алгоритмы и жизнеритмы. Основы алгоритмизации. Быстрый способ изучить алгоритмы. — М.: Препринт, 2018. — 313 с.
drakon.su/_media/zhizneritm.pdf
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Вы правы и я согласен с вами. Ваша трактовка насчет Бэкуса, Фортрана и математиков изящна и обогащает содержание обсуждения.
Говоря кратко блок-схемы не эргономичны, не формализованы, не структурированы, не упорядочены.
Дракон-схемы, напротив, лишены подобных недостатков и во всех отношениях превосходят их. Чтобы пояснить эти слова, нужно ввести новую систему понятий, новые критерии и новую теорию. Для этой цели я написал ряд книг:
Сравнение с имеющимся в моих книгах есть. Формального стандарта языка нет, но есть почти равноценное стандарту техническое задание на разработку программы «дракон-конструктор».
Несколько энтузиастов создали свои варианты дракон-конструктора.
Например, дракон-конструктор Степана Митькина имеет открытый код и позволяет преобразовывать дракон-схемы в исходный код 13 целевых языков: Java, Processing, D, C#, C/C++ (with Qt support), Python, Tcl, JavaScript, Lua, Erlang, AutoHotkey и Verilog.
Спасибо за интересную цитату их Бэкуса. Но в этой цитате нет термина «программирование без программистов.
Вы трактуете „программирование без программистов“ расширительно, я же склонен обращаться к первоисточнику (Джеймс Мартин), где этот термин впервые появился.
Моя идея — соединить идею алгоритма с идеей когнитивной эргономики. Полученный результат некорректно называть блок-схемами. Дракон-схемы принципиально отличаются от блок-схем.
Принимаемые при создании языка ДРАКОН решения описаны в моих книгах.
Наиболее полно — в книге
Это не совсем так.
История идеи «программирование без программистов» выглядит иначе.
ПРЕДЛОЖЕНИЕ ДЖЕЙМСА МАРТИНА
В 1982 году известный специалист по информатике Джеймс Мартин опубликовал книгу под названием «Прикладное программирование без программистов»:
В этой книге Мартин утверждает, что с появлением непроцедурных языков появилась возможность предоставлять пользователям средства, которые позволяют им самим создавать программы.
Для справки приведу аннотацию к этой книге.
НОВОЕ НАПРАВЛЕНИЕ ИССЛЕДОВАНИЙ
Книга Мартина дала начало новому направлению исследований, которое обычно для краткости называют «Программирование без программистов» (хотя фактически речь идет только о программировании без ПРИКЛАДНЫХ программистов»).
Чтобы оценить масштаб и разнообразие ведущихся исследований, можно задать в Гугле запрос «Программирование без программистов»
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Да, есть.
Посмотрите четыре видеоролика Сергея Ефанова (общая длительность 1 час).
Вот ссылка на 1-й видеоролик
Видео. Использование языка ДРАКОН для программирования микроконтроллеров. Часть 1. Разработка программы управления автоматическим дверным замком.
www.youtube.com/watch?v=Ua9dUUONjdk&feature=youtu.be
Если вам это интересно, я могу прислать вам книги по языку ДРАКОН
Вы повторяете недостоверные сведения (анекдоты), которые не имеют отношения к действительности и серьезной работе. Инженеры разрабатывают на языке ДРАКОН по методу " программирование без программистов" исходный код программы (а не картинки, как вы предположили). Прочитайте статьи, на которые я дал ссылки. После этого многие вопросы отпадут.
Вы правы, получаемая модель памяти загружается в БЦВМ (и НЦВМ) Бисер.
Именно для этого и служит дракон-технология в Роскосмосе.
Если же вы хотите работать не с Бисером, а с другим компьютером или контроллером,
надо использовать технологию Степана Митькина, как это делают в Немецком космическом агентстве (см. ссылку, которую я дал). Или технологию Геннадия Тышова. Или разработайте свою собственную.
Это не так. На визуальном языке ДРАКОН делаются серьезные вещи.
Вот две статьи, где говорится про применение языка ДРАКОН в серьезных космических проектах:
1. Морозов В. В., Трунов Ю. В., Комиссаров А. И., Пак Е. А., Жучков А. Г., Дишель В.Д, Залихина Е. Е., Паронджанов В. Д. Система управления межорбитального космического буксира «Фрегат» \ Вестник ФГУП «НПО им. С. А. Лавочкина», 2014, № 1. — С. 16-25.
bit.ly/2RtCdaU
2. Паронджанов В.Д. Визуальный алгоритмический язык ДРАКОН в ракетной технике и
медицине // Современные автоматизированные системы управления реального
времени как прикладное развитие научных достижений кибернетики» (К 100-летию со
дня рождения И.А. Полетаева). Материалы межведомственной конференции 24
марта 2016 г. — ФГБУ «3 ЦНИИ» Минобороны РФ, 2016. — 218 с. — С. 57-78.
bit.ly/2BDhYCB
Вот еще одна статья, где речь идет о применении языка ДРАКОН в Немецком космическом агентстве (German Aerospace Agency).
Marc Schwarzbach, Sven Wlach, Maximilian Laiacker. Modifying a Scientific Flight Control System for Balloon Launched UAV Missions // German Aerospace Center DLR // IEEE, 2015.
drakon.su/_media/ballon_ap_final.pdf
Это не так.
Степан Митькин (Норвегия, город Колсас Kolsås) разработал свой дракон-конструктор, используя язык ДРАКОН.
sourceforge.net/projects/drakon-editor/files
drakonhub.com
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Рекомендую желающим сопоставить предлагаемые в статье правила с эргономическими правилами визуального языка ДРАКОН. bit.ly/1UQ4zuU
Вы обнаружите большое (хотя и не полное) сходство
С уважением,
Владимир Данилович Паронджанов, Москва, Роскосмос
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Я обратил внимание на слова:
Все написано правильно. Но полезно спросить: Что нас ждет в будущем?
Каковы перспективы?
По моему мнению, язык ДРАКОН обеспечивает наилучшую понятность алгоритмов для читателей патентов по сравнению с конкурирующими нотациями.
Будущее в патентном деле принадлежит ДРАКОНу.
Если Вы, Станислав Федорович, хотите приблизить будущее, я готов Вам всячески помогать.
Приведу цитату из сети:
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
Жаль, что автор ограничился текстовым программированием и не рассмотрел визуальное.