Поскольку в статье никакие образцы не приводятся...
Это не так. В статье приводятся два примера:
Рис. 3. Клинический алгоритм «Реанимационные действия при наличии у новорожденного аномалий глотки
Рис. 4. Клинический алгоритм силуэт «Реанимация беременной женщины»
Оба примера я взял из литовских медицинских учебников на русском языке:
1. Специализированная реанимация новорожденного. Учебник. / Под ред. Р. Й. Надишаускене. – Литва: Центр исследования кризисов, Университет наук здоровья Литвы, 2012. – 396 с.
2. Начальная неотложная акушерская помощь. Учебник. / Под ред.
Р. Й. Надишаускене. – Литва: Центр исследования кризисов, Университет наук здоровья Литвы, 2012. – 204 с.
С вашими профессиональными медицинскими замечаниями я безоговорочно соглашаюсь, так как я не врач.
Но у меня есть комментарии.
Автором обеих схем указан автор статьи.
Да, но ниже написано:
Данный алгоритм построен на основе текстового описания, изложенного в книге: «Практическое руководство для врачей общей (семейной) практики / Под ред. академика РАМН И. Н. Денисова. — М.: ГЭОТАР-МЕД, 2001. — 720 с. — ISBN 5-9231-0050-9», в разделе «Ожоги органов зрения» на стр. 501-504.
Вы пишете:
В первом примере не соблюдаются критерии алгоритмичности (действия «10-15 минут»)
С тех пор этот недостаток исправлен, язык ДРАКОН доработан. В язык дРАКОН введены две новые иконы:
1. Начало контрольного срока. В иконе Начало пишут контрольное время критической процедуры, например, «30 сек».
2. Конец контрольного срока. В иконе Конец указывают окончание контрольного времени, например, «Прошло 30 сек».
Исправленный рисунок см. в книге на стр. 215 рис. 132.
Про вторую схему отвечу отдельно позднее.
Самое главное. Рисовать клинические алгоритмы на языке ДРАКОН должны профессиональные врачи, как это активно делают врачи в Литве и как это делают в единичных случаях врачи в России.
Клинические алгоритмы на языке ДРАКОН должны критически обсуждаться врачами, дорабатываться врачами и публиковаться на основании консенсуса.
В версии клинического протокола по акушерским кровотечениям 2014 года в приложении была блок-схема, хотя и довольно примитивная. В варианте 2018 года ее утеряли.
Похоже, что вы профессиональный врач. Ваш ник SQLap я прочитал как «эскулап». Я не ошибся?
Но сейчас положение изменилось. Появилась возможность создавать алгоритмы дествий, которые облегчают труд врачей, ускоряют приобретение процедурных медицинских знаний, сокращают врачебные ошибки и повышают безопасность пациентов благодаря языку ДРАКОН.
Смотрите: в статье я рассказал, как русские врачи смостоятельно нашли мою книгу по медицинскому языку ДРАКОН, изучили ее и успешно использовали ДРАКОН для решения задач в области респираторной терапии при осложненных формах COVID-19.
Вот отзывы литовских врачей о языке ДРАКОН: Доктор мед. наук A. Кудрявичене, неонатолог:
«Язык ДРАКОН – отличный инструмент для обучения практическим навыкам и их стандартизации. Он позволяет выявить все, даже мельчайшие, но очень важные действия».
Доктор мед. наук, проф. M. Ключинскас, акушер-гинеколог:
«Язык ДРАКОН позволяет систематизировать процессы с минимальным применением текста – как при организации работы, так и при выполнении медицинских процедур. Он помогает всем одинаково понимать и выполнять конкретные действия… Позволяет ускорить запоминание действий».
Доктор мед. наук, проф. Ж. Дамбраускас, абдоминальный хирург:
«Огромным преимуществом языка ДРАКОН является то, что он позволяет конкретно выявить все этапы процедуры или процесса… Мысленно можешь повторить процесс этап за этапом, а затем каждый этап разделить на шаги… Процедуру или процесс можно выполнить мысленно, а затем и в реальности. ДРАКОН является инструментом мысленной тренировки».
Врач Б. Кумпайтене, анестезиолог-реаниматолог:
«Польза языка ДРАКОН для разрабатывающего алгоритм автора состоит в том, что проявляется, кристаллизуется и стандартизируется каждый навык, каждая процедура. Польза для обучающегося – это ясный путь выполнения действий. ДРАКОН дает ответ на вопросы “что делать, если”».
А. Вилейките, координатор медицинского учебного Центра исследования кризисов:
«Применение языка ДРАКОН позволяет стандартизировать и эргономично представить самую сложную процедуру… Если всё правильно описано на ДРАКОНе, значит, всё будет отлично выполнено».
Доктор мед. наук, проф. Динас Вайткайтис, зав. кафедрой экстремальной медицины:
«Язык ДРАКОН даёт ясность и чёткость процессам, применяемым в медицине. Он позволяет “автоматизировать” обучение студентов практическим навыкам. Может стать основой для технологии принятия клинических решений».
Доктор мед. наук П. Добожинскас, исполнительный директор медицинского учебного Центра исследования кризисов:
«Применение языка ДРАКОН действенно помогает в создании и описании сложных, динамичных решений медицинских проблем. Тем самым значительно облегчается проведение стандартизированного симуляционного обучения, внедряя культуру безопасности пациентов и принципы качественного оказания медицинских услуг в масштабах медицинского учреждения, региона или государства».
Доктор мед. наук, проф. Р.Й. Надишаускене, зав. клиники акушерства и гинекологии, главный специалист по акушерству и гинекологии Литовской республики:
«Алгоритмизация медицины подразумевает значительную перестройку системы медицинского образования и перевод ее на алгоритмический путь… Накопленный в Литве практический положительный опыт использования языка ДРАКОН для представления сложных и разнообразных медицинских алгоритмов может послужить серьезной основой для принятия крупных структурных решений руководителями здравоохранения и системы медицинского образования в области алгоритмизации медицины».
Врачи клинической медицины (у которых мы лечимся) не знают, что такое if then else.
Такие слова знают лишь программисты и специалисты по медицинской кибернетике.
Но о специальности 30.05.03 “Медицинская кибернетика” в статье речь не идет.
Речь идет только о группе профессий и специальностей 31.00.00 “Клиническая медицина”
Это не метрика. Это экспертная оценка автора программы предпринимателя Алексея Муравицкого. Она опирается на практический опыт автора и хорошо осмыслена.
Это, кстати, неправда. Я считаю, что ошибки во время выполнения программы — это плохо, и поэтому пользуюсь различными инструментами, которые уменьшают вероятность таких ошибок.
Вы (как и все остальные программисты на земном шаре), пользуетесь только теми инструментами, которые придумало человечество, других просто нет.
Но все эти замечательные инструменты, (прекрасные сами по себе) не могут решить проблему ошибок. Именно поэтому произошла парная катастрофа Боинга 737 МАХ, унесшая сотни жизней.
Разве это хорошо? Разве это нормально?
Нет, это плохо. Это ненормально.
Поэтому нужны новые инструменты для подавления ошибок. ДРАКОН — именно такой инструмент.
Мне важно, что при разработке на используемом мной языке я веду всю разработку и отладку в одной среде.
Так работают многие или даже все программисты в мире. А что получается? Несмотря на наличие замечательных IDE и других средств (для борьбы с ошибками) проблема ошибок как была, так и осталась нерешенной.
На тестирование, отладку, моделирование и др. человечество вынуждено тратить значительные ресурсы. И тем не менее на этапе эксплуатации выявляются новые ошибки, которые не удалось выявить ранее.
Все (и вы в том числе) считают такое положение нормальным. А я считаю, что это ненормально, что нужны новые средства для противодействия ошибкам.
Язык ДРАКОН — новое средство подавления ошибок.
То, что ДРАКОН такой возможности не предоставляет, я считаю недостатком ДРАКОНа.
Я отношусь к вашему мнению с уважением, но согласиться с вами не могу.
Отладку схемы осуществляют в среде CODESYS [другой язык]
Тут у вас неточность. CoDeSys — это не другой язык. Это вообще не язык. CoDeSys — это IDE промышленной автоматики.
А где же язык программирования?
В CODESYS для программирования доступны все пять определяемых стандартом IEC 61131-3 (МЭК 61131-3) языков:
— IL (Instruction List) — ассемблер-подобный язык
— ST (Structured Text) — Pascal-подобный язык
— LD (Ladder Diagram) — язык релейных схем
— FBD (Function Block Diagram) — язык функциональных блоков
— SFC (Sequential Function Chart) — язык диаграмм состояний
В дополнение к FBD поддержан язык программирования CFC (Continuous Function Chart) с произвольным размещением блоков и расстановкой порядка их выполнения.
Вы пишете:
Важно не то, что отладка ведется в родной среде разработки целевого языка. Важно то, что отладка ведется в среде разработки языка разработки.
А что говорит Алексей Муравицкий? Он не согласен с вами. Для него язык разработки — ДРАКОН, а отладку он ведет не в среде языка разработки, а в среде целевого языка ST — одного из пяти языков, определяемых стандартом IEC 61131-3 (МЭК 61131-3) языков.
Мы с вами знаем, что Алексей стремится устранить лишнее звено, сократить издержки и избавиться от ST и CoDeSys:
моя компания второй год занимается разработкой более совершенного ДРАКОН-конструктора с возможностью эмулятора схемы, и непосредственной загрузкой программы из ДРАКОН-схемы в ПЛК, без промежуточного ПО.
Но это не значит, что метод Алексея Муравицкого удастся легко распространить на другие целевые языки.
я уже больше 15 лет пишу на языке, на котором я сейчас пишу (название не важно), специалисты компании, в которой я работаю, пишут программы непосредственно на этом языке, отладку осуществляют в его же родной среде разработки (это, заметим, лучше, чем у ДРАКОНа).
Это недоразумение. На ДРАКОНе можно делать точно так же. Обозначим язык, про который вы говорите, XYZ.
ДРАКОН-технология работает так (в случае гибридного языка Дракон-XYZ). Шаг 1. Дракон-схема транслируется в исходный код на языке XYZ. Шаг 2. Исходный код на языке XYZ стандартным образом с помощью стандартных IDE языка XYZ обрабатывается и преобразуется в исполняемый (executable) код. Или, говоря вашими словами, «специалисты осуществляют отладку в его же (XYZ) родной среде разработки».
Разница лишь в том, что отладка в родной среде XYZ будет проще и быстрее, так как ДРАКОН уже выявил и устранил значительную часть ошибок.
Таким образом, отладка в родной среде языка XYZ входит в состав ДРАКОН-технологии. Но в некоторых случаях по желанию пользователя ее можно опустить. Например, предприниматель Алексей Муравицкий, пытаясь оптимизировать свою работу и сократить издержки, стремится исключить из ДРАКОН-технологии работу с языком программирования ST стандарта IEC61131-3. и IDE промышленной автоматики CoDeSys 3.5 (2.3).
Так что ваша фраза «это, заметим, лучше, чем у ДРАКОНа» основана на недоразумении и неверна.
Сообщаю дополнительные сведения о предпринимателе Алексее Муравицком, который давно работает на языке ДРАКОН и использует его в сфере промышленной автоматики.
Вот что пишет сам Алексей (ПЛК — программируемый логический контроллер):
Моя компания ОКБ АМУР №3 okbamur3.ru уже 5 лет работает на языке ДРАКОН для программирования ПЛК на промышленных объектах с помощью ДРАКОН-конструктора.
Специалисты моей компании пишут программу непосредственно в языке ДРАКОН, и затем генерируют код ST для CODESYS 3.5 (2.3). Отладку схемы осуществляют в среде CODESYS, в связи с отсутствием на сегодняшний день МЭК-версии ДРАКОН-конструктора.
Существующий ДРАКОН-конструктор имеет ряд недостатков, снижающих производительность труда.
По этой причине моя компания второй год занимается разработкой более совершенного ДРАКОН-конструктора с возможностью эмулятора схемы, и непосредственной загрузкой программы из ДРАКОН-схемы в ПЛК, без промежуточного ПО.
ДРАКОН-технология упрощенно работает так (в случае гибридного языка Дракон-Си). Шаг 1. Дракон-схема транслируется в исходный код на языке Си. Здесь же добавляется кусочек на чистом Си. Шаг 2. Исходный код на языке Си
стандартным образом с помощью стандартных IDE обрабатывается и преобразуется в исполняемый (executable) код.
__________
Шаг 2 может быть и иным (это отдельный разговор).
Генератор, о котором вы говорите, входит в состав ДРАКОН-конструктора, например, программы ИС Дракон Генадия Тышова.
Именно с ним работает предприниматель Алексей Муравицкий. Так что Алексей пока что имел дело только с одним генератором. Экспериментальная статистика о двух (или трех и более) генераторах отсутствует. Возможно, вы и правы.
Как вы меряете соотношение между картинками (ДРАКОН — это картинки) и текстом?
Очень просто. Предположим, что мы работаем на гибридном языке Дракон-Си.
В этом случае, говоря вашими словами, «картинка (ДРАКОН — это картинка)» автоматически транслируется (конвертируется) в исходный код на языке Си. А «текст» тоже написан на чистом Си.
Таким образом, согласно ДРАКОН-технологии обе части программы (дракон-схема и текст) приводятся к одному знаменателю. И предстают перед нами в виде исходного кода на языке Си.
Две части кода на Си сравнить нетрудно. Если первая часть содержит, например, 800 строк, а вторая 200 строк, значит, получим 80% и 20%.
меня интересует очень простая вещь: что такое «программа на Х процентов написанная на ДРАКОНе».
Предположим, что программа состоит из двух частей. Первая часть в виде дракон-схемы на гибридном языке Дракон-Си (это 80%). Эта часть автоматически конвертируется в исходный код на Си. Оставшаяся часть дописывается на чистом Си (20%).
Я не держу алгоритм в голове. Я его пишу. Точно так же, как разработчик на ДРАКОНе свой алгоритм рисует, я этот алгоритм пишу.
Это не так. Вы пишете программу, но не алгоритм. Это принципиальное отличие. Все (и вы в том числе) привыкли называть программу алгоритмом.
Академик АН СССР А.А. Дородницын (и я вслед за ним) строго различаем эти понятия.
Повторяю: вы держите алгоритм в голове, что чревато ошибками. В прошлой статье на Хабре
Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН
на примере Боинга 737 МАХ я показал, что человечество не умеет писать алгоритмы без ошибок.
Язык ДРАКОН — это шаг к безошибочным алгоритмам. ДРАКОН позволяет заметно сократить число ошибок.
Насчет IDE вы частично правы, но это дело наивное. Со временем появятся и качественные ДраконIDE.
Почему частично?
У ДРАКОНа нет средств работы с состоянием.
Отвечаю. Силуэт можно использовать как конечный автомат. Ветка силуэта — это состояние автомата. Подробнее см. статью Степана Митькина Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019.
я и сделаю «каркас» из одной «иконы», где будет весь текст программы на целевом языке. Получится программа, на 100% написанная на ДРАКОНе, по вашему определению.
Чем ближе к крайностям, тем дальше от истины.
Объясняю. При программировании на ДРАКОНЕ вы всегда программируете на гибридном языке Дракон-Х, где Х — целевой язык. Для краткости, можно условно сказать: программа написана на ДРАКОНе (при этом подразумевая гибридный язык Дракон-Х).
Ваш пример не имеет смысла, так как на ДРАКОНе в первую очередь идет проработка алгоритма. В вашем примере проработка алгоритма полностью отсутствует. Вы держите алгоритм в голове, что чревато ошибками.
Сергей Ефанов программирует на ДРАКОНе с 2010 года. Вот что он пишет в своей статье в 2012 году:
Попытаюсь сказать несколько слов о том, что это мне дало, и как выглядит процесс.
Написание программы распалось на два этапа — проработка алгоритма, и собственно программирование.
Главное в любой программе — алгоритм. В ДРАКОНе он рисуется, точнее — составляется из графических элементов. Очень похожих на элементы блок-схем.
Но есть несколько строгих правил, которые не позволяют схеме превратиться в запутанный клубок линий, квадратов и ромбиков.
Правила, на первый взгляд, простые. Но эффект от их применения — колоссальный!
На ДРАКОНЕ запутанный и непонятный алгоритм нарисовать просто нельзя. И наоборот, любой сложный алгоритм, нарисованный согласно этим правилам, становится очень понятным.
При разработке алгоритма теперь его не надо держать в голове при написании текста программы. Работа сводится к визуальному конструированию алгоритма. Это гораздо легче. Не требуется такое сосредоточение, как обычно. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент, потом легко вернутся к её продолжению.
И только когда весь алгоритм «отлизан» — переходим к собственно программированию. В чём оно теперь заключается? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка. На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.
я знаю, как написать программу на 100% на ДРАКОНе: рисуем один квадратик с названием «програма», весь текст помещаем внутрь.
Нет, не так. ДРАКОН создает графический каркас (графический чертеж) и имеет свои правила для текста (их очень немного).
99% текста внутри икон пишут на целевом языке (target language).
Здесь все на ДРАКОНе, т.е. на гибридном языке.
Уточню. При программировании ДРАКОН всегда работает в паре с целевым языком.
Например, Дракон в паре с языком Си — это называется гибридный язык Дракон-Си.
Иногда, надо дописать какую-то часть на Си (или другом целевом языке).
Это, простите, как посчитали?
Так мне сказал автор программы Алексей Муравицкий. Ему виднее. Значит, Муравицкий 20-30% написал на чистом Си или на чем-то еще.
Язык ДРАКОН на Южно-Балыкском газоперерабатывающем заводе (ГПЗ) компании «Сургутнефтегаз».
Шкаф управления установки глубокой переработки
широкой фракции легких углеводородов (ШФЛУ)
На видео показана установка глубокой переработки
широкой фракции легких углеводородов (ШФЛУ).
Во второй половине видео показан шкаф управления установки.
В шкафу управления используется программа управления, 70%-80% которой написано на языке ДРАКОН.
Программа управления загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Разработчик шкафа управления и программы управления Алексей Муравицкий.
Шкаф управления осуществляет управление
Установкой глубокой переработки широкой фракции легких углеводородов (ШФЛУ) на Южно-Балыкском газоперерабатывающем заводе (ГПЗ) компании «Сургутнефтегаз».
Фракция ШФЛУ — продукт переработки попутного нефтяного газа (ПНГ) и газового конденсата.
«Сургутнефтегаз» (СНГ) — одна из крупнейших российских нефтяных и газодобывающих компаний.
ДРАКОН-программа в шкафу управления создана с помощью инструментальной программы «ИС Дракон» Геннадия Тышова.
Не могу согласиться. Взаимодействия алгоритмов всегда можно описать в виде алгоритмов. Я не вижу тут проблемы.
Конечно, иногда возможны случаи, что в языке ДРАКОН чего-то не хватает, тогда приходится вводить в язык ДРАКОН дополнительные иконы. Но пока я такой необходимости не вижу.
У меня вот тут есть сервис, который сам по себе продукт, который состоит из нескольких десятков взаимодействующих компонентов, как вы предлагаете эти взаимосвязи описать на ДРАКОНе?
Ваши взаимосвязи носят алгоритмический характер. Значит, их можно описать на ДРАКОНе.
по мере увеличения сложности алгоритма его читаемость на ДРАКОНе падает (см пример с quick search).
Нет, не падает. поясню.
Программа quick search — это вовсе не сложный, наоборот, это простейший, элементарный алгоритм. Его не надо придумывать, он давным-давно придуман.
Есть классические алгоритмы, например, quick search. Не надо их писать на ДРАКОНе, смысла нет.
Зачем нужен ДРАКОН?
В программировании — для разработки новых продуктов (а не для копирования старых, давно известных).
Программа quick search будет малой, тысячной или миллионной долей создаваемого нового сложного продукта.
Новый сложный продукт будет на ДРАКОНе, а входящие в него мелкие, классические, давно известные частицы типа quick search не обязательно переводить на ДРАКОН.
Чем сложнее продукт, тем больше выигрыш от использования ДРАКОНа.
Это не так. В статье приводятся два примера:
Рис. 3. Клинический алгоритм «Реанимационные действия при наличии у новорожденного аномалий глотки
Рис. 4. Клинический алгоритм силуэт «Реанимация беременной женщины»
Оба примера я взял из литовских медицинских учебников на русском языке:
С вашими профессиональными медицинскими замечаниями я безоговорочно соглашаюсь, так как я не врач.
Но у меня есть комментарии.
Да, но ниже написано:
Вы пишете: С тех пор этот недостаток исправлен, язык ДРАКОН доработан. В язык дРАКОН введены две новые иконы:
1. Начало контрольного срока. В иконе Начало пишут контрольное время критической процедуры, например, «30 сек».
2. Конец контрольного срока. В иконе Конец указывают окончание контрольного времени, например, «Прошло 30 сек».
Исправленный рисунок см. в книге на стр. 215 рис. 132.
Про вторую схему отвечу отдельно позднее.
Самое главное. Рисовать клинические алгоритмы на языке ДРАКОН должны профессиональные врачи, как это активно делают врачи в Литве и как это делают в единичных случаях врачи в России.
Клинические алгоритмы на языке ДРАКОН должны критически обсуждаться врачами, дорабатываться врачами и публиковаться на основании консенсуса.
Похоже, что вы профессиональный врач. Ваш ник SQLap я прочитал как «эскулап». Я не ошибся?
Примитивные блок-схемы не представляют интереса. Речь идет о сложных клинических алгоритмах, примером которых является документ «Профилактика, алгоритм ведения, анестезия и интенсивная терапия при послеродовых кровотечениях. Клинические рекомендации».
Такие клинические алгоритмы создавались в условиях, когда клиническая медицина была плохо формализованной областью знания.
Но сейчас положение изменилось. Появилась возможность создавать алгоритмы дествий, которые облегчают труд врачей, ускоряют приобретение процедурных медицинских знаний, сокращают врачебные ошибки и повышают безопасность пациентов благодаря языку ДРАКОН.
Смотрите: в статье я рассказал, как русские врачи смостоятельно нашли мою книгу по медицинскому языку ДРАКОН, изучили ее и успешно использовали ДРАКОН для решения задач в области респираторной терапии при осложненных формах COVID-19.
Вот отзывы литовских врачей о языке ДРАКОН:
Доктор мед. наук A. Кудрявичене, неонатолог:
Доктор мед. наук, проф. M. Ключинскас, акушер-гинеколог:
Доктор мед. наук, проф. Ж. Дамбраускас, абдоминальный хирург:
Врач Б. Кумпайтене, анестезиолог-реаниматолог:
А. Вилейките, координатор медицинского учебного Центра исследования кризисов:
Доктор мед. наук, проф. Динас Вайткайтис, зав. кафедрой экстремальной медицины:
Доктор мед. наук П. Добожинскас, исполнительный директор медицинского учебного Центра исследования кризисов:
Доктор мед. наук, проф. Р.Й. Надишаускене, зав. клиники акушерства и гинекологии, главный специалист по акушерству и гинекологии Литовской республики:
Такие слова знают лишь программисты и специалисты по медицинской кибернетике.
Но о специальности 30.05.03 “Медицинская кибернетика” в статье речь не идет.
Речь идет только о группе профессий и специальностей 31.00.00 “Клиническая медицина”
Нет, не финал. Как только у меня кончится форс-мажор, я собираюсь ответить.
Но все эти замечательные инструменты, (прекрасные сами по себе) не могут решить проблему ошибок. Именно поэтому произошла парная катастрофа Боинга 737 МАХ, унесшая сотни жизней.
Разве это хорошо? Разве это нормально?
Нет, это плохо. Это ненормально.
Поэтому нужны новые инструменты для подавления ошибок. ДРАКОН — именно такой инструмент.
На тестирование, отладку, моделирование и др. человечество вынуждено тратить значительные ресурсы. И тем не менее на этапе эксплуатации выявляются новые ошибки, которые не удалось выявить ранее.
Все (и вы в том числе) считают такое положение нормальным. А я считаю, что это ненормально, что нужны новые средства для противодействия ошибкам.
Язык ДРАКОН — новое средство подавления ошибок. Я отношусь к вашему мнению с уважением, но согласиться с вами не могу.
CoDeSys — это IDE промышленной автоматики.
А где же язык программирования?
Вы пишете: А что говорит Алексей Муравицкий? Он не согласен с вами. Для него язык разработки — ДРАКОН, а отладку он ведет не в среде языка разработки, а в среде целевого языка ST — одного из пяти языков, определяемых стандартом IEC 61131-3 (МЭК 61131-3) языков.
Мы с вами знаем, что Алексей стремится устранить лишнее звено, сократить издержки и избавиться от ST и CoDeSys: Но это не значит, что метод Алексея Муравицкого удастся легко распространить на другие целевые языки.
ДРАКОН-технология работает так (в случае гибридного языка Дракон-XYZ).
Шаг 1. Дракон-схема транслируется в исходный код на языке XYZ.
Шаг 2. Исходный код на языке XYZ стандартным образом с помощью стандартных IDE языка XYZ обрабатывается и преобразуется в исполняемый (executable) код. Или, говоря вашими словами, «специалисты осуществляют отладку в его же (XYZ) родной среде разработки».
Разница лишь в том, что отладка в родной среде XYZ будет проще и быстрее, так как ДРАКОН уже выявил и устранил значительную часть ошибок.
Таким образом, отладка в родной среде языка XYZ входит в состав ДРАКОН-технологии. Но в некоторых случаях по желанию пользователя ее можно опустить. Например, предприниматель Алексей Муравицкий, пытаясь оптимизировать свою работу и сократить издержки, стремится исключить из ДРАКОН-технологии работу с языком программирования ST стандарта IEC61131-3. и IDE промышленной автоматики CoDeSys 3.5 (2.3).
Так что ваша фраза «это, заметим, лучше, чем у ДРАКОНа» основана на недоразумении и неверна.
Вот что пишет сам Алексей (ПЛК — программируемый логический контроллер):
Шаг 1. Дракон-схема транслируется в исходный код на языке Си. Здесь же добавляется кусочек на чистом Си.
Шаг 2. Исходный код на языке Си
стандартным образом с помощью стандартных IDE обрабатывается и преобразуется в исполняемый (executable) код.
__________
Шаг 2 может быть и иным (это отдельный разговор).
Генератор, о котором вы говорите, входит в состав ДРАКОН-конструктора, например, программы ИС Дракон Генадия Тышова.
Именно с ним работает предприниматель Алексей Муравицкий. Так что Алексей пока что имел дело только с одним генератором. Экспериментальная статистика о двух (или трех и более) генераторах отсутствует. Возможно, вы и правы.
В этом случае, говоря вашими словами, «картинка (ДРАКОН — это картинка)» автоматически транслируется (конвертируется) в исходный код на языке Си. А «текст» тоже написан на чистом Си.
Таким образом, согласно ДРАКОН-технологии обе части программы (дракон-схема и текст) приводятся к одному знаменателю. И предстают перед нами в виде исходного кода на языке Си.
Две части кода на Си сравнить нетрудно. Если первая часть содержит, например, 800 строк, а вторая 200 строк, значит, получим 80% и 20%.
Это не так. Вы пишете программу, но не алгоритм.
Это принципиальное отличие. Все (и вы в том числе) привыкли называть программу алгоритмом.
Академик АН СССР А.А. Дородницын (и я вслед за ним) строго различаем эти понятия.
Повторяю: вы держите алгоритм в голове, что чревато ошибками. В прошлой статье на Хабре
на примере Боинга 737 МАХ я показал, что человечество не умеет писать алгоритмы без ошибок.
Язык ДРАКОН — это шаг к безошибочным алгоритмам. ДРАКОН позволяет заметно сократить число ошибок.
Насчет IDE вы частично правы, но это дело наивное. Со временем появятся и качественные ДраконIDE.
Почему частично? Отвечаю. Силуэт можно использовать как конечный автомат. Ветка силуэта — это состояние автомата. Подробнее см. статью Степана Митькина Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019.
Чем ближе к крайностям, тем дальше от истины.
Объясняю. При программировании на ДРАКОНЕ вы всегда программируете на гибридном языке Дракон-Х, где Х — целевой язык. Для краткости, можно условно сказать: программа написана на ДРАКОНе (при этом подразумевая гибридный язык Дракон-Х).
Ваш пример не имеет смысла, так как на ДРАКОНе в первую очередь идет проработка алгоритма. В вашем примере проработка алгоритма полностью отсутствует. Вы держите алгоритм в голове, что чревато ошибками.
Сергей Ефанов программирует на ДРАКОНе с 2010 года. Вот что он пишет в своей статье в 2012 году:
Нет, не так. ДРАКОН создает графический каркас (графический чертеж) и имеет свои правила для текста (их очень немного).
99% текста внутри икон пишут на целевом языке (target language).
Уточню. При программировании ДРАКОН всегда работает в паре с целевым языком.
Например, Дракон в паре с языком Си — это называется гибридный язык Дракон-Си.
Иногда, надо дописать какую-то часть на Си (или другом целевом языке).
Так мне сказал автор программы Алексей Муравицкий. Ему виднее. Значит, Муравицкий 20-30% написал на чистом Си или на чем-то еще.
Конкретный пример
youtu.be/_XOuhV_8N_I
Язык ДРАКОН на Южно-Балыкском газоперерабатывающем заводе (ГПЗ) компании «Сургутнефтегаз».
Шкаф управления установки глубокой переработки
широкой фракции легких углеводородов (ШФЛУ)
На видео показана установка глубокой переработки
широкой фракции легких углеводородов (ШФЛУ).
Во второй половине видео показан шкаф управления установки.
В шкафу управления используется программа управления, 70%-80% которой написано на языке ДРАКОН.
Программа управления загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Разработчик шкафа управления и программы управления Алексей Муравицкий.
Шкаф управления осуществляет управление
Установкой глубокой переработки широкой фракции легких углеводородов (ШФЛУ) на Южно-Балыкском газоперерабатывающем заводе (ГПЗ) компании «Сургутнефтегаз».
Фракция ШФЛУ — продукт переработки попутного нефтяного газа (ПНГ) и газового конденсата.
«Сургутнефтегаз» (СНГ) — одна из крупнейших российских нефтяных и газодобывающих компаний.
ДРАКОН-программа в шкафу управления создана с помощью инструментальной программы «ИС Дракон» Геннадия Тышова.
Конечно, иногда возможны случаи, что в языке ДРАКОН чего-то не хватает, тогда приходится вводить в язык ДРАКОН дополнительные иконы. Но пока я такой необходимости не вижу.
Нет, не падает. поясню.
Программа quick search — это вовсе не сложный, наоборот, это простейший, элементарный алгоритм. Его не надо придумывать, он давным-давно придуман.
Есть классические алгоритмы, например, quick search. Не надо их писать на ДРАКОНе, смысла нет.
Зачем нужен ДРАКОН?
В программировании — для разработки новых продуктов (а не для копирования старых, давно известных).
Программа quick search будет малой, тысячной или миллионной долей создаваемого нового сложного продукта.
Новый сложный продукт будет на ДРАКОНе, а входящие в него мелкие, классические, давно известные частицы типа quick search не обязательно переводить на ДРАКОН.
Чем сложнее продукт, тем больше выигрыш от использования ДРАКОНа.