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
leotom Спасибо. Нет ли у Вас E-mail Леонида Борисовича Наумова? Мне нужно ему написать. Я смог узнать, что он в Израиле. Вот цитата:
Наумов Л.Б. Нажмите кнопку, коллега!
В 1970 году в Новосибирском государственном медицинском университете при Факультете Повышения Квалификации Преподавателей медицинских вузов была создана первая в СССР кафедра педагогики и оптимизации высшего медицинского образования. Основателем кафедры и первым ее заведующим (1970-1985) был профессор Леонид Борисович Наумов. За эти 15 лет свыше 3000 преподавателей почти всех медицинских институтов СССР — ассистенты, доценты и профессора – заведующие кафедрами, овладевали на этой кафедре наиболее эффективными оригинальными принципами и методами профессиональной подготовки врачей. Разработал 15 научно-методических направлений и 70 различных путей, методов и средств оптимизации профессионального обучения специалистов. Они перечислены в его книге «Учебные игры в медицине». Автор и соавтор более 150 научных работ, в том числе 25 книг, учебных пособий, учебника для студентов, руководств для врачей и преподавателей, монографий, ряда сборников научных работ по оптимизации высшего медицинского образования. Единственные в мировой медицинской литературе: программированный учебник с алгоритмами и программированное руководство для врачей награждены Дипломами за Лучшую Медицинскую книгу. Книга с первыми в мире алгоритмами дифференциальной диагностики в рентгенологии награждена Серебряной медалью ВДНХ СССР. В настоящее время профессор Л.Б. Наумов: почетный член Израильской Ассоциации Альтернативной Медицины за инновативные достижения в медицинских интеллектуальных технологиях, докладчик на Всемирных и Европейских международных конгрессах в Женеве, Иерусалиме, Копенгагене, Флоренции; член Редколлегии Журнала по кардиологии, Турция. Книга посвящена итогам и перспективам внедрения кибернетических методов в практику среднего и высшего медицинского образования, клинической медицины и здравоохранения. Книга охватывает широкий круг вопросов.
Наумов Л. Б. Медицина и кибернетика.—Душанбе: Ирфон, 1968.
Наумов Л. Б. Диагностические алгоритмы и обучающие программы. Учебное пособие для студентов. НГМИ.—Новосибирск, 1972.
Наумов Л. Б. Система оптимизации высшего медицинского образования. —В кн.: Оптимизация высшего медицинского образования. Научные труды НГМИ, т. 85. Новосибирск, 1976, с. 240—249.
Наумов Л. Б. Оптимизация обучения в медицинском институте. НГМИ.— Новосибирск, 1978.
Наумов Л Б. Профессиональному образованию — революционные перемены.—ЭКО, 1979, № 5, с. 92—106.
Наумов Л. Б. Игра «Больной с жалобами на боль в груди».— В кн.: Активные методы обучения и деловые игры. Тез. докл. на Ш межведомственной школе-семинаре 21—25 сент. 1981 г. Новосибирск, 1981, с. 52—56.
Наумов Л. Б. Деловые игры в высшем медицинском образовании.— В кн.: Использование деловых игр в совершенствовании систем управления. ЦЭМИ АН СССР, М., 1982, с. 63—86.
Наумов Л. Б. Легко ли стать врачом?—Ташкент: Медицина, УзССР, 1983.
Наумов Л. Б., Гаевский Ю. Г., Бессонов А. М., Меркушев В. В. Распознавание болезней сердечно-сосудистой системы. Диагностические и тактические алгоритмы. Программированное руководство.— Ташкент: Медицина, УзССР, 1979.
Н а у м о в Л. Б., Г а е в с к и й Ю. Г., Бессонов А. М., Меркушев В. В. Болезни сердечно-сосудистой системы. Алгоритмы дифференциальной диагностики, лечения, врачебно-трудовой экспертизы.—Ташкент: Медицина, УзССР, 1985.
sairus777 Спасибо за замечания. Моя книга предназначена для профессиональных врачей.
Книга написана на основании практического опыта литовских врачей, которые используют язык ДРАКОН для описания последовательности действий и решений врачей при диагностике и лечении. Приведу цитату:
Альгирдас Каралюс (Литва) был первым, кто обратил внимание на возможность крупномасштабного использования языка ДРАКОН в медицине… в качестве графического средства для удобного описания последовательности действий врачей. То есть в качестве медицинского алгоритмического языка.
Инициативу Каралюса активно поддержали литовские врачи. За последнее время в Литве изданы четыре медицинских учебника на русском языке, в которых используется ДРАКОН [126].
Учебники апробированы в ряде стран (Литва, Казахстан, Азербайджан, Таджикистан, Туркменистан, Киргизия) в рамках курсов повышения квалификации врачей. Курсы проводили высококвалифицированные специалисты из Литовского университета медицинских наук (Lietuvos sveikatos mokslų universitetas) для местных врачей. Проведенная апробация дала положительные результаты [131].
См. стр. 97, 98.
Почему в ДРАКОНе не используется цвет? Ведь цвет значительно облегчает ориентироваться в мире.
Вы правы, цвет очень помогает. В ДРАКОНе цвет используется, например, для заливки фона. Это помогает отделить фигуру от фона и направить внимание читателя на фигуру, то есть на дракон-схему.
В остальных случаях с цветом нужно быть осторожным. Неумелое использование цвета может вызвать раздражение у читателя. Тут необходимо пробовать и советоваться с художниками, специалистами по цвету.
В моём «шампуре» Yes — это всегда направо, т.к. любой положительное можно инвертировать: А < Б на А > Б, «дождь идёт?» на «дождь не идёт»…
Вы правы, любое положительное высказывание теоретически можно инвертировать.
Но здесь есть трудность, если учесть необходимость соблюдения норм профессиональной терминологии в терминах предметной области.
Отрицание может внести затруднение в понимание сути вопроса (если учитывать требование когнитивной эргономики).
Уместно привести слова Эдварда Йодана:
Если это возможно, то избегайте отрицаний в булевских выражениях; представляется, что их понимание составляет трудность для многих программистов.
Источник: Эдвард Э. Структурное проектирование и конструирование программ. — М.: Мир, 1979. — 415 с. — С. 252.
По этой причине в языке ДРАКОН предусмотрены оба случая:
1) Да вниз, Нет вправо
2) Нет вниз, Да вправо.
Такой подход создает наибольшую удобочитаемость и облегчает чтение сложных программных текстов.
На практике используется, в частности, гибридный язык Дракон-Си, где Си служит целевым языком. При этом си-код не пишут вручную; он формируется автоматически на выходе дракон-схемы (комплекта дракон-схем). Вероятность ошибки уменьшается или сводится к нулю.
Цель языка ДРАКОН — обеспечить безопасность потока управления.
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
Жаль, что автор ограничился текстовым программированием и не рассмотрел визуальное.
leotom Спасибо. Нет ли у Вас E-mail Леонида Борисовича Наумова? Мне нужно ему написать. Я смог узнать, что он в Израиле. Вот цитата:
Источник: http://www.alib.ru/au-naumov/nm-nazhmite_knopku_kollega/
leotom Спасибо за сведения о Л.Б. Наумове.
Я посмотрел отрывок здесь http://sohmet.ru/medicina/item/f00/s00/e0000262/index.shtml
Вот труды Наумова:
Источник: https://medinfo.social/uchebniki_885/literatura-49140.html
sairus777 Спасибо за замечания. Моя книга предназначена для профессиональных врачей.
Книга написана на основании практического опыта литовских врачей, которые используют язык ДРАКОН для описания последовательности действий и решений врачей при диагностике и лечении. Приведу цитату:
Уважаемые коллеги!
Желающие ознакомиться с моей книгой могут пройти по ссылке http://drakon.su/_media/biblioteka/2_udobnyj_jazyk_dlja_vrachej.pdf
С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: http://drakon.su/
Webforum: http://forum.drakon.su/
Вы правы, цвет очень помогает. В ДРАКОНе цвет используется, например, для заливки фона. Это помогает отделить фигуру от фона и направить внимание читателя на фигуру, то есть на дракон-схему.
В остальных случаях с цветом нужно быть осторожным. Неумелое использование цвета может вызвать раздражение у читателя. Тут необходимо пробовать и советоваться с художниками, специалистами по цвету.
С уважением,
Владимир Паронджанов
Вы правы, любое положительное высказывание теоретически можно инвертировать.
Но здесь есть трудность, если учесть необходимость соблюдения норм профессиональной терминологии в терминах предметной области.
Отрицание может внести затруднение в понимание сути вопроса (если учитывать требование когнитивной эргономики).
Уместно привести слова Эдварда Йодана:
Источник: Эдвард Э. Структурное проектирование и конструирование программ. — М.: Мир, 1979. — 415 с. — С. 252.
По этой причине в языке ДРАКОН предусмотрены оба случая:
1) Да вниз, Нет вправо
2) Нет вниз, Да вправо.
Такой подход создает наибольшую удобочитаемость и облегчает чтение сложных программных текстов.
С уважением,
Владимир Паронджанов