Комментарии 176
— Так мы ещё и не доехали.
Такие слова знают лишь программисты и специалисты по медицинской кибернетике.
Но о специальности 30.05.03 “Медицинская кибернетика” в статье речь не идет.
Речь идет только о группе профессий и специальностей 31.00.00 “Клиническая медицина”
в целом современная медицина уже сведена к этому. От врача не требуется думать, у него есть четкое if орви then арбидол, и за этот then он никогда не получит по шапке. А вот если он начнет думать и порекомендует не то, за что башляет фарма, а то что нужно конкретно этому человеку, у которого помимо орви ещё есть особенности организма, то отвечать за это будет он сам. А в условиях когда козлами отпущения всегда делают исполнителей и ни один главврач не встанет на его защиту, то и ответственность такую брать на себя никто не хочет особо. Думающий врач вымирающий вид.
И подобная цифровизация\алгоритмизация только закрепляет такое поведение, причем уже на уровне образования. Выучил схемку - получил диплом.
Врачи клинической медицины (у которых мы лечимся) не знают, что такое if then else.
А элементы блок-схемы они знают? Там сходу не все из них очевидны из начертания. Ну и можно же if заменить на ЕСЛИ.
Все что я вижу - это простые блок-схемы, которые изучались еще в средней школе. Громкая аббревиатура ДРАКОН, а по сложности - даже до UML ему как до неба.
Врачам клинической медицины, которые закончили среднюю школу, а потом еще 5-6 лет мединститут, должно быть несложно просто взять и читать блок-схемы без какого-либо специального обучения какому-то там языку.
Тем, кто рисует такие блок-схемы - еще ладно. Но по-хорошему это не язык, это примитивный стандарт. Такой перечень источников и людей, которые как бы работали - я бы сказал ОК, если это все относится к визуальному редактору, в котором можно создавать такие схемы, и чтобы этот визуальный редактор умел не только их создавать, но и автоматически предлагать варианты печати на различные носители ( от банальных А4, до многометровых баннеров или цифровых интерактивных gif/видео/js). В этом случае и статья и реклама оправдана.
Но я посыл всей статьи вижу как "только алгоритм ДРАКОН в принципе является алгоритмом, и без него никак", а это совершенно не так. Алгоритмы писать и визуализировать можно не только множеством других способов, но это еще и уже давным давно делается.
Я о том и говорю, что тому, что я увидел в статье, вообще учить не нужно. Это просто читается интуитивно, и зачем вокруг дракона столько суеты - непонятно. Это ОБЫЧНЫЕ блок-схемы.
А зачем тогда изобретать такую сложную вещь, что для простого следования инструкциям по этим схемам нужно оказывается отдельно читать специальные книги и проходить обучение?
Обычная блок-схема может сработать также, но при этом ее может интуитивно прочитать и понять даже сам пациент, без мед.образования.
Чтобы устранить недочеты, в России разработан медицинский алгоритмический язык высокой точности ДРАКОН,
Ммм. "ДРАКОН как часть космической программы «Буран» разрабатывался начиная с 1986 года" (wiki), так что утверждение, что он является медицинским и/или разработан, чтобы устранить недочеты клинических рекомендаций, кажется мне несколько... натянутым, скажем мягко.
Для построения алгоритмической клинической медицины необходим эргономичный медицинский алгоритмический язык высокой точности.
Критерий "эргономичный ... высокой точности" нуждается в формализации, прежде чем на основании этого утверждения можно будет построить какую-либо реформу.
Я в этом вижу плюсы: снижается риск принятия врачом неверного решения самостоятельно.
И минусы: повышается риск выбора неверного алгоритма, или несоответствия алгоритма индивидуальным особенностям пациента.
Вообще, если врачу требуется мануал уровня работника автосервиса, или повара в макдональдсе — наверное, это не очень хорошо. Средний уровень квалификации врачей явно упадет.
Но я считаю этот процесс в любом случае неизбежным. Медицина будущего — это линейные исполнители, снимающие все параметры пациента, забирающие анализы и проводящие медицинские процедуры, и центральный супермозг в виде нейросети, которая ставит диагноз и назначает лечение.
Не скажу за другие страны, но в Японии и в Ирландии врачи общей практики примерно так и работают: у них есть определённые чек-листы, по которым прогоняется пациент. Эти чек-листы вполне стандартизированы как бы не на всю страну, но на клинику уж точно. Результатом являются диагноз и далее - алгоритм лечения (какие и когда анализы делать, какие лекарства и как принимать).
Основной бонус в том, что все инновации в этот процесс прогоняются через сито "доказательности". То есть ты можешь быть сколько угодно умным врачом, но твоё дело не экспериментировать на людях, а лечить их наилучшим из доказанных способов.
При этом квалификация врачей не страдает, а наоборот держится на очень высоком уровне. Потому что таких операций и случаев очень много, и нужно как можно более эффективно использовать весь имеющийся инструмент. Я бы сказал, что тут полная аналогия с пилотами пассажирских самолётов - есть инструменты-инструкции. Квалификация есть как можно более точное им следование с пониманием что происходит. А всё что вне этого - уже к исследователям. В том числе очень редкие случаи.
Странно читать о не страдающей квалификации, если диагноз по чек листу может поставить условно медсестра.
Я бы сказал, что тут полная аналогия с пилотами пассажирских самолётов
Любая аналоги лжива, а такая в особенности. Пилоты самолетов по инструкциям и на тренажерах оттачивают в первую очередь рефлексы, потому что в критической ситуации будет не до справочников.
Точное следование алгоритму не дает понимание происходящего и цель производимых действий. Это очень опасно для пациента, если он где-то не впишется в существующий алгоритм. А алгоритмы 100% будут неполными. Или же их количество будет неуклонно расти, они будут накладываться и противоречить друг другу.
Вы забываете о роли врачей и ответственности сторон. В Ирландии (и в Японии - но там своя специфика) врач - это специально обученный человек, который советует лечение и, если пациент согласен, имеет право выписать лекарства не доступные просто так из соображений безопасности.
Соответственно ответственность врача - правильно поставить диагноз и назначить лечение. На Хабре была статья с подробным описанием того, как это делается в применении к стоматологии - https://habr.com/ru/company/belayaraduga/blog/534782/
Естественно никто не гарантирует 100% результат - такого не бывает в природе. Гарантируется применение наилучшего известного лечения по результатам наилучшей возможной диагностики из доказанных.
Пример с пилотами отличный. Алгоритмы страхуют от катастрофы, начинающейся с предложений вроде "Андрюха, ща эту грозу сверху проскочим..."
У вас есть доказательства? Iris там, или coq? Ну или prusti на худший случай. Если нет, прочь из медицины со своими кривыми ручками.
А вот что ваши ручки не кривые вы можете попытаться доказать с помощью систем доказательств. Если осилите.
Так в медицине же доказательства другие. Coq это про дедуткивные доказательства. А в медицине принято доказывать по другому - от частного к общему.
Если в выборке из 100000 человек от препарата никто не умер, то обобщаем,на что он безвреден для всех людей. В математике с такого доказательства только поглумятся.
Если вы говорите про гёделевы ординалы, то будьте любезны уважать и принцип эквивалентности Тьюринг машин. Пишите алгоритмы для тьюринг-полного вычислителя (которым может быть и человек, собственно, в работах Тьюринга других и не было), следуйте правилам индустрии.
Пока кто-то развлекается фриковатым языком НАПИСАННЫМ РУССКИМ КАПСОМ в безопасных областях, мне всё равно.
Кто кто-то приходит с фриковатым языком в медицину, мне перестаёт быть всё равно, потому что если это извращение пролезет в Минздрав, то пострадают люди.
Беда в том, что это чисто текстовый документ, предлагающий алгоритмы действий врача в текстовом виде. Графические алгоритмы в документе полностью отсутствуют, что заметно снижает его эргономическое качество.
В версии клинического протокола по акушерским кровотечениям 2014 года в приложении была блок-схема, хотя и довольно примитивная. В варианте 2018 года ее утеряли.
А так, оформление клинических рекомендаций ни разу не является основной проблемой медицины в РФ. Куда как важней наполнение этих алгоритмов заказухой от фармкомпаний (к примеру вездесущий арбидол) и низкий уровень медицинского образования в целом.
В версии клинического протокола по акушерским кровотечениям 2014 года в приложении была блок-схема, хотя и довольно примитивная. В варианте 2018 года ее утеряли.Похоже, что вы профессиональный врач. Ваш ник SQLap я прочитал как «эскулап». Я не ошибся?
Примитивные блок-схемы не представляют интереса. Речь идет о сложных клинических алгоритмах, примером которых является документ «Профилактика, алгоритм ведения, анестезия и интенсивная терапия при послеродовых кровотечениях. Клинические рекомендации».
Такие клинические алгоритмы создавались в условиях, когда клиническая медицина была плохо формализованной областью знания.
Но сейчас положение изменилось. Появилась возможность создавать алгоритмы дествий, которые облегчают труд врачей, ускоряют приобретение процедурных медицинских знаний, сокращают врачебные ошибки и повышают безопасность пациентов благодаря языку ДРАКОН.
Смотрите: в статье я рассказал, как русские врачи смостоятельно нашли мою книгу по медицинскому языку ДРАКОН, изучили ее и успешно использовали ДРАКОН для решения задач в области респираторной терапии при осложненных формах COVID-19.
Вот отзывы литовских врачей о языке ДРАКОН:
Доктор мед. наук A. Кудрявичене, неонатолог:
«Язык ДРАКОН – отличный инструмент для обучения практическим навыкам и их стандартизации. Он позволяет выявить все, даже мельчайшие, но очень важные действия».
Доктор мед. наук, проф. M. Ключинскас, акушер-гинеколог:
«Язык ДРАКОН позволяет систематизировать процессы с минимальным применением текста – как при организации работы, так и при выполнении медицинских процедур. Он помогает всем одинаково понимать и выполнять конкретные действия… Позволяет ускорить запоминание действий».
Доктор мед. наук, проф. Ж. Дамбраускас, абдоминальный хирург:
«Огромным преимуществом языка ДРАКОН является то, что он позволяет конкретно выявить все этапы процедуры или процесса… Мысленно можешь повторить процесс этап за этапом, а затем каждый этап разделить на шаги… Процедуру или процесс можно выполнить мысленно, а затем и в реальности. ДРАКОН является инструментом мысленной тренировки».
Врач Б. Кумпайтене, анестезиолог-реаниматолог:
«Польза языка ДРАКОН для разрабатывающего алгоритм автора состоит в том, что проявляется, кристаллизуется и стандартизируется каждый навык, каждая процедура. Польза для обучающегося – это ясный путь выполнения действий. ДРАКОН дает ответ на вопросы “что делать, если”».
А. Вилейките, координатор медицинского учебного Центра исследования кризисов:
«Применение языка ДРАКОН позволяет стандартизировать и эргономично представить самую сложную процедуру… Если всё правильно описано на ДРАКОНе, значит, всё будет отлично выполнено».
Доктор мед. наук, проф. Динас Вайткайтис, зав. кафедрой экстремальной медицины:
«Язык ДРАКОН даёт ясность и чёткость процессам, применяемым в медицине. Он позволяет “автоматизировать” обучение студентов практическим навыкам. Может стать основой для технологии принятия клинических решений».
Доктор мед. наук П. Добожинскас, исполнительный директор медицинского учебного Центра исследования кризисов:
«Применение языка ДРАКОН действенно помогает в создании и описании сложных, динамичных решений медицинских проблем. Тем самым значительно облегчается проведение стандартизированного симуляционного обучения, внедряя культуру безопасности пациентов и принципы качественного оказания медицинских услуг в масштабах медицинского учреждения, региона или государства».
Доктор мед. наук, проф. Р.Й. Надишаускене, зав. клиники акушерства и гинекологии, главный специалист по акушерству и гинекологии Литовской республики:
«Алгоритмизация медицины подразумевает значительную перестройку системы медицинского образования и перевод ее на алгоритмический путь… Накопленный в Литве практический положительный опыт использования языка ДРАКОН для представления сложных и разнообразных медицинских алгоритмов может послужить серьезной основой для принятия крупных структурных решений руководителями здравоохранения и системы медицинского образования в области алгоритмизации медицины».
Похоже, что вы профессиональный врач. Ваш ник SQLap я прочитал как «эскулап». Я не ошибся?
Да, я работаю врачом акушером-гинекологом, правда в гинекологии, а не в роддоме.
Примитивные блок-схемы не представляют интереса. Речь идет о сложных клинических алгоритмах, примером которых является документ «Профилактика, алгоритм ведения, анестезия и интенсивная терапия при послеродовых кровотечениях. Клинические рекомендации».
Такие клинические алгоритмы создавались в условиях, когда клиническая медицина была плохо формализованной областью знания.
Это абсолютно не сложный алгоритм. Там какое-то ветвление идет на первом этапе (выбрать причину кровотечения между разрывами родовых путей, остатками плаценты, атонией матки или коагулопатией), а дальше идет поэтапный набор диагностических и лечебных манипуляций. Не помог текущий этап - переходим к следующему. Последним этапом является удаление матки и перевязка подвздошных сосудов, питающих органы малого таза. Проблема не в сложности алгоритма. Проблема в том, что алгоритм должен быть реализован быстро и непреклонно. Те редкие случаи, когда я бегом бежал по своей больнице вслед за каталкой с пациенткой были связаны с реализацией именно этого алгоритма. А так там без проблем можно пошаговую инструкцию на одной странице разместить.
«Язык ДРАКОН даёт ясность и чёткость процессам, применяемым в медицине. Он позволяет “автоматизировать” обучение студентов практическим навыкам
Вы вообще понимаете, какой бред тут несется?
Какое обучение практическим навыкам? Как взять анализ крови из вены по вашим схемам? Если попал в вену - набирай, если не попал - коли заново? А где тут помощь в обучении ПРАКТИЧЕСКИХ НАВЫКОВ?
«Язык ДРАКОН даёт ясность и чёткость процессам, применяемым в медицине. Он позволяет “автоматизировать” обучение студентов практическим навыкамВы привели цитату. Я напомню, кто это сказал. Это сказал
Вы вообще понимаете, какой бред тут несется?
доктор медицинских наук, профессор Динас Вайткайтис, зав. кафедрой экстремальной медицины Литовского университета наук здравоохранения:
«Язык ДРАКОН даёт ясность и чёткость процессам, применяемым в медицине. Он позволяет “автоматизировать” обучение студентов практическим навыкам. Может стать основой для технологии принятия клинических решений».Если вы с ним не согласны, значит, вы разбираетесь в медицине, лучше, чем он.
От себя добавлю, что он прислал мне в подарок от имени 15 авторов книгу «Неотложная медицинская помощь» (2012, 264 с.).
В Предисловии сказано:
В этой книге детально описаны основные навыки, которым вы будете обучаться во время практических занятий. Последовательность сложных или более важных действий написана в алгоритмах, подготовленных по методике В. Паронджанова. Цель алгоритмов — помочь вам как можно лучше запомнить последовательность действий при оказании помощи. Надеемся, что эти алгоритмы станут отличным средством, которое вы всегда сможете использовать в своей работе
Чек-лист кмк лучше оформлять не в виде блок схемы, а в виде комикса. Это же не для ALU инструкция, а для человека.
Проблема в том, что автор пытается доказать что форма может улучшить содержание. Никакая блок-схема не в силах заменить, например, отсутствие четких критериев при принятии решения. Или собственно знаний у того, кто схему составляет. Поскольку в статье никакие образцы не приводятся, приходится взять два примера из Википедии: Первая помощь при химическом ожоге глаз жидкостью и Терапевтическая тактика при фибрилляции предсердий. Автором обеих схем указан автор статьи. В первом примере не соблюдаются критерии алгоритмичности (действия "10-15 минут", "1500-3000 МЕ противостолбнячной сыворотки", "Введи внутримышечно или дай внутрь") и сомнительная рекомендация обработать ожег век спиртом (каким спиртом?), который вызовет еще большее повреждение. А вот вторая схема - пример как раз отсутствия понимания, что и как делать, а не как это изобразить. Схема опубликована в книге 2013 года, основные взгляды на лечение фибрилляции предсердий тогда уже не отличались от современных. Но что делать по этой схеме понять тяжело. Давно известно, что дигоксин не купирует фибрилляцию предсердий, зачем он в схеме? Очень интересная ветка "Использование кардиоверсии" -> "Синусовый ритм восстановлен?" -> "Нет" -> "Постоянная фибрилляция предсердий", если к ней привела, например, нестабильная гемодинамика. Это больной должен постоянно с нестабильной гемодинамикой жить? Антиагрегантная терапия не влияет на риск инсульта, это уже было известно в 2013 году, поэтому "Проведи антиагрегантную или антикоагулянтную терапию" - рекомендация неправильная. И не "провЕди", а "провОди", потому что терапия постоянная пожизненная. В то же время уже была шкала CHADS2 (2007), по которой принимается решение назначать антикоагулянты или нет. И много других глупостей. Кто желает проверить - читайте рекомендации AHA/ACC и ECS за то время (рекомендации по фибрилляции предсердий довольно часто обновляются). В общем схема красивая, но вредная. И ДРАКОН к этому отношения не имеет.
Но ведь форма действительно может оказывать существенное влияние! Сравните программы на BASIC'е и Pascal'е (например, goto). Или на C и Rust (например, безопасность работы с памятью). Всё это - полные по Тьюрингу языки программирования, но разница в лёгкости сделать ошибку и/или получить сложно воспринимаемый код есть.
И вспомните высказывание Дейкстры о BASIC'е.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
(Перевод по ru.wikiquote.org: Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.)
ДРАКОН-диаграммы - это по сути дела структурированные диаграммы. И, кстати, тоже вдохновлённые тем же самым Дейкстрой, его постулатами о том, каким требованиям должны удовлетворять блок-схемы. Использование ДРАКОН'а позволяет уменьшать количество некоторых типичных ошибок и увеличивает удобство восприятия. Но, пожалуй, и не более того. Если у составителя схемы недостаточно знаний в предметной области, то разве можно рассчитывать на то, что язык программирования/стандарт составления блок-схем, каким бы он мощным ни был, скомпенсирует эту нехватку знаний?
Использование ДРАКОН'а позволяет уменьшать количество некоторых типичных ошибок
Может быть, вы можете привести примеры типичных ошибок, число которых позволяет уменьшить использование ДРАКОНа?
Пожалуй, смогу. Но прежде чем я попытаюсь это сделать, соглашусь с тем, что, на мой взглад, коллега Паронджанов действительно упустил крайне важный момент - доказательства того, что использование ДРАКОН'а существенно улучшают проблемы с ошибками и простотой восприятия. Структуральщики типа Дейкстры и Вирта достаточно убедительно показали проблемы с goto и доказали эффективность их решения при помощи структурного программирования, а "растообразные", соответвенно, проблемы при работы с памятью и решение их при помощи концепций владения и времени жизни.
Итак, к типичным ошибкам. Когда я читал книгу "Алгоритмы и жизнеритмы на языке Дракон", мне запомнились два таких примера. Первый - это распространённые ошибки при программировании на C, связанные с отрицаниями в условиях выхода из цикла (говоря о распространённости таких ошибок, Паронджанов ссылается на классические труды по структурному программированию). Нотации, принятые в ДРАКОН'е, уменьшают вероятность таких ошибок.
Второе - это отсутствие неразрывного "шампура" в блок-схемах. Например, стандарт ANSI рекомендует разрывать вертикальную линию при ветвлениях, рисуя одну ветвь влево, другую вправо. При наличии нескольких ветвлений и циклов это может приводить к потере понимания контроля управления, и связанным с этим ошибками. "Шампур" же действительно позволяет достаточно легко отслеживать логику управления.
В целом, я поигрался для себя немного, попытавшись порисать сначала наивные блок-схемы, а потом драконьи. И действительно, драконьи мне показались существенно более читабельными. Но так-то, дяденька, я не настоящий сварщик, только книжку про ДРАКОН на стройке нашёл, которую пролистал из интереса :)
На самом деле, мне немного обидно, что достаточно интересный инструмент из-за некоторых, с моей точки зрения, недочётов в подаче автором материала, из-за которых кажется, будто ДРАКОН должен быть панацеей от всех компьютерных бед. Да и капс в длинном названии многих раздражает, хотя, казалось бы, от BASIC'а такое название недалеко ушло.
Структуральщики типа Дейкстры и Вирта достаточно убедительно показали проблемы с goto и доказали эффективность их решения при помощи структурного программирования
… это те самые проблемы, которые в полный рост есть в ДРАКОНе благодаря переходу из ветки в ветку?
Первый — это распространённые ошибки при программировании на C, связанные с отрицаниями в условиях выхода из цикла (говоря о распространённости таких ошибок, Паронджанов ссылается на классические труды по структурному программированию). Нотации, принятые в ДРАКОН'е, уменьшают вероятность таких ошибок.
Покажите пример.
При наличии нескольких ветвлений и циклов это может приводить к потере понимания контроля управления, и связанным с этим ошибками
Я не знаю, что такое "понимание контроля управления". Какие ошибки с этим связаны?
В целом, я поигрался для себя немного, попытавшись порисать сначала наивные блок-схемы, а потом драконьи. И действительно, драконьи мне показались существенно более читабельными.
Я совершенно не спорю с тем, что драконьи схемы могут быть более читабельными, нежели "наивные блок-схемы". Могут. А могут и не быть (примеров уже достаточно).
Мне кажется бездоказательным повторяющееся утверждение, что ДРАКОН уменьшает число ошибок.
Да и капс в длинном названии многих раздражает, хотя, казалось бы, от BASIC'а такое название недалеко ушло.
Меня не раздражает капс. Меня раздражают назойливые попытки выдать ДРАКОН за средство решения проблем, которые он, на самом деле, не решает.
Нотации, принятые в ДРАКОН'е, уменьшают вероятность таких ошибок.тогда простое неиспользование оператора безусловного перехода сводит количество таких ошибок к нулю, не так ли? а «не использовать goto» в современных языках нормальному человеку очень легко (и, повторюсь, этому успешно учат детей без задержки умственного развития в средних общеобразовательных школах. Видимо, ДУРАКОН нужен тем, кого из средней школы отчислили).
Да, кстати, «Нотации, принятые в ДУРАКОН'е» вполне позволяют допустить эти ошибки просто потому, что ДУРАКОН при переводе картинок в код генерит кучу этих самых goto — следовательно (как выяснили в комментах к прошлому опусу Паронджанова), позволяет невольно или умышленно…
Что же касается Дейкстры — скорее всего, Паронджанов понял Дейкстру, хм, в силу своих особеностей, т.е. слишком буквально. Но тем не менее, наличие goto/jmp/br в коде совершенно не означает, что код не отвечает требованиям структурного программирования.
На самом деле, мне немного обидно, что достаточно интересный инструментэто инструмент для тех, кого Паронджанов мягко описал как имеющих «трудности с пониманием логического отрицания в условиях»… Т.е. для тех, кого к программированию подпускать, в общем, нельзя.
будто ДРАКОН должен быть панацеей от всех компьютерных бед.эх, если б только «компьютерных»… амбиции Паронджанова куда больше… тут и «мудрецы, похожие на обезъян», и «врачи, калечащие пациентов» — а противостоит им великий Паронджанов в белом пальто… Вы книжки его-то почитайте, почитайте…
И вспомните высказывание Дейкстры о BASIC'е.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
Ну вот я в детстве имел несколько лет опыта с бейсиком, мне это никак не помешало стать ни разработчиком, ни впоследствии архитектором. Может, не надо дословно воспринимать на веру все, что Дийкстра когда-либо говорил?
Наверно, тогда вам понравится цитата Кэя, теперь уже о Дейкстре: "you probably know that arrogance in computer science is measured in nano-Dijkstras". :)
Мой вольный перевод
"вы, вероятно, знаете, что в информатике высокомерие измеряется в нанодейкстрах".
Вообще-то, я не предлагал "дословно воспринимать на веру" высказывание Дейкстры, я предлагал его вспомнить. И, соответственно, весь контекст, в котором оно сделано. (А именно, про становление парадигмы структурного программирования.)
Что касается вас, то вряд ли вы программировали на оригинальном Бейсике (называемом сейчас "дартмутским"), который использовали в образовании во времена, когда Дейкстра писал своё эссе ("How do we tell truths that might hurt?", 1975 год). А уж если вы на Визуальном Бейсике программировали, то он в смысле структуры мало похож на прародителя.
Впрочем, и это не важно - во-первых, как вы понимаете, единичный пример не опровергает заявление, содержащее "practically impossible", а во-вторых, что важнее, цитата Дейкстры - это, разумеется, афористическая сатирическая гипербола. Осмелюсь порекомендовать прочитать эссе целиком, если не читали - оно любопытное: https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html
Я вот не понимаю, собственно, зачем вспоминать "афористическую сатирическую гиперболу", затрагивающую язык, на котором сейчас вряд ли кто-то пишет? Может быть, стоит, наоборот, задуматься, что если языки и все окружение программиста так сдвинулись, то и проблемы могли поменяться?
PS Если мне память не изменяет, я изучал бейсик по документации от GW-Basic. Это точно не мог быть QBasic, потому что номера строк все еще были обязательны.
Простите, отвечу вам в одном посте, и, наверное, больше уже здесь отвечать не буду - я и так потратил на обсуждение данной статьи больше времени, чем следовало. Пожалуйста, не сочтите за неуважение к вам!
Может быть, стоит, наоборот, задуматься, что если языки и все окружение программиста так сдвинулись, то и проблемы могли поменяться?
Увы, проблема хорошо сформулирована уже почти пару тысяч лет тому назад, и не особо меняется: errare humanum est. И переход от Бейска к Паскалю, и от Си к Расту, и от блок-схем к драконьим - это одна и та же схема: уменьшение свободы творца, чтобы 1. не провоцировать его на ошибки и 2. упростить читателю понимание. Можно обсуждать, насколько эффективны ограничения и предписания ДРАКОН'а - но для этого надо проводить исследования. На мой взгляд, предпосылки для того, чтобы драконий подход мог оказаться удачным, вполне есть.
я изучал бейсик по документации от GW-Basic
GW-Basic - это уже куда более современный язык, чем дартмутский, в котором названия переменной были в формате одна буква+число. Возможно, это даже самый современный из тех, которые ещё требуют номера строки.
есть в ДРАКОНе благодаря переходу из ветки в ветку?
Нет, переходы в рамках "силуэта" не обладают проблемами goto. "Силуэт" - это достаточно интересная попытка структуризации. На простых примерах, с которыми я игрался, работало неплохо, но что на больших программах, сказать затрудняюсь. Но судя по использованию пилюгинцами при создании системы Энергия-Буран, которая полетела с первого раза (единственная неудача - неправильно выполненный "перевертон" на Полюсе - как раз создавали по старинке), и на сложных систем он может быть применим. Насколько я могу догадываться, идея с "силуэтом" выросла из реализаций конечных автоматов, и они на неё очень хорошо ложатся.
Покажите пример.
Простите, не буду тратить время. Раз вы архитектор, то о проблемах, когда в цикле в условии забывают поставить "!" или наоборот ставят лишний, наверняка слышали. В ДРАКОНе такую ошибку из-за графической наглядности ветвления с пометками yes/no и из-за специфики расположения "икон" слева-направо (по принципу "чем проблемней, тем правее" и т.п.) такую ошибку сделать сложнее - уж извините, вот это мне кажется абсолютно очевидным.
Я не знаю, что такое "понимание контроля управления".
Когда не сразу видно, куда какие переходы происходят, где циклы, а где какие-то ветвления. Мне кажется, наглядный пример есть здесь: https://habr.com/ru/post/345320/#comment_10581640
Я совершенно не спорю с тем, что драконьи схемы могут быть более читабельными, нежели "наивные блок-схемы". Могут. А могут и не быть (примеров уже достаточно).
А можно дать ссылки на эти примеры? Буду признателен, потому что интересно. Точнее, примеры, когда читабельность одинаковая не очень интересны, а есть ли примеры, когда читабельность ухудшается (при условии, что читатель знает базовые идеи ДРАКОН'а типа "шампура" и "силуэта")?
Мне кажется бездоказательным повторяющееся утверждение, что ДРАКОН уменьшает число ошибок.
В каких-то ситуациях - разумеется, уменьшает. Он же ограничивает свободу. Другой вопрос, что, возможно, в других ситуациях он напротив провоцирует ошибки. Ну, а так, я вроде бы примерно о том же и написал - что в отличие от идеологов структурного программирования и концепций владения и времени жизни, Паранджанов упустил необходимость серьёзных доказательств.
Засим откланиваюсь - всю интересную информацию по теме, которая у меня была, я, пожалуй сообщил, дальнейший диалог наш уже мало кто прочитает. Если ДРАКОН станет популярным, то не благодаря тому, что мы с вами придём к консенсусу, а благодаря тому, что кто-нибудь, наконец, убедительно покажет реальную степень эффективности его эргономичности и т.п., и она окажется действительно высокой.
Можно обсуждать, насколько эффективны ограничения и предписания ДРАКОН'а — но для этого надо проводить исследования.
Так вот, основная претензия к автору поста в том, что он делает свои заявления об уменьшении ошибок без каких-либо формальных исследований.
Простите, не буду тратить время.
Не, не прощу. Либо пример есть, либо его нет.
Раз вы архитектор, то о проблемах, когда в цикле в условии забывают поставить "!" или наоборот ставят лишний, наверняка слышали.
Слышал. И именно поэтому уверен, что ДРАКОН эти проблемы не решает.
из-за специфики расположения "икон" слева-направо (по принципу "чем проблемней, тем правее" и т.п.)
А выход из цикла — это более проблемное или менее? Оно должно быть правее или "центрее"? Почему?
уж извините, вот это мне кажется абсолютно очевидным.
Мне как раз "кажется очевидным", что это не работает.
Когда не сразу видно, куда какие переходы происходят, где циклы, а где какие-то ветвления.
А, так в ДРАКОНе этого тоже не видно, пример ниже.
А можно дать ссылки на эти примеры?
(ну то есть когда я у вас прошу примеры, так "не буду тратить время"?)
Прямо вот ниже по странице пример с "первой помощью при химическом ожоге глаз". Совершенно очевидно, что будучи изложенным в одну вертикальную конструкцию эта последовательность станет более читаемой.
В каких-то ситуациях — разумеется, уменьшает. Он же ограничивает свободу. Другой вопрос, что, возможно, в других ситуациях он напротив провоцирует ошибки.
… и это означает, что невозможно утверждать, что в общем он уменьшает число ошибок, и его внедрение имеет какую-то доказанную пользу. О чем и речь.
Засим откланиваюсь
… тогда зачем вам ссылки на примеры?
Примеры мне нужны в первую очередь для того, чтобы прочитать и обдумать, а не для того, чтобы оспорить. Я вас о них вежливо попросил - но нет так нет.
Совершенно очевидно, что будучи изложенным в одну вертикальную конструкцию эта последовательность станет более читаемой.
Спасибо. Поскольку по вашему ответу мне кажется, что вы всё же обиделись, прокомментирую: в рамках "разгоризонталивания" в "силуэт" происходит декомпозиция большего куска алгоритма на более-менее изолированные компоненты (часто для этого пришлось делают именованные функции, которым приходится передавать параметры), разбиение там не случайно. Это вполне сознательное и аргументированное решение в дизайне ДРАКОН'а, и выглядит оно в принципе интересно: декомпозиция линейного кода на компоненты - в целом подход популярный и работающий. Насколько он реально эффективен в обсуждаемом гуманитарном примере, дискутировать не готов, но очевидно неэффективным он мне не кажется.
Спасибо за дискуссию! Что ж, интересно будет посмотреть, учтёт ли Паронджанов с коллегами прозвучавшую в нашем диалоге критику и идеи в последующих публикациях или нет.
декомпозиция большего куска алгоритма на более-менее изолированные компоненты
Но они не изолированные, как хорошо видно на примере "продолжай промывать" (и общего таймера). Декомпозиция здесь не приносит пользы, а наоборот, ухудшает читаемость.
Насколько он реально эффективен в обсуждаемом гуманитарном примере, дискутировать не готов, но очевидно неэффективным он мне не кажется.
Я говорю про конкретный пример, в котором это очевидно неэффективно (медицина - не гуманитарная область, кстати).
"использование дракона в Буране/Энергии", по словам того же Паронджанова, заключалось в том, что "нарисовали на бумаге, отдали программистам на кодирование". Т.е. ровно как обычные блок-схемы. Ну и высказывание в посте, годе человек явно из пилюгинцев рассказывает, что дуракон-схемы остались лишь как придурковатые требования начальства, рисуются задним числом, и никакой роли не играют, ибо начальство их прочитать не может, а разработчики все разработали без них.
"Дракон" никогда не станет популярным, ибо это инструмент для алгоритмических инвалидов. Он родился уже при смерти, и в таком состоянии находится последние 25 лет...
Нет, тот человек не из НПЦАП им. Пилюгина. Там, возможно, относятся к системе несколько получше. :)
Ну, да, как я пониманию, при проектировании системы Энергия-Буран предтеча ДРАКОН'а использовалась в духе блок-схем, для последующего программирования на ассемблере, Прологе/ПРОЛ2 и Диполе (которые тоже не были высокоуровневыми - тот Пролог не имеет отношения к Prolog'у). Но это всё же не просто блок-схемы, а формализованные. И, вероятно, в тех условиях, когда с одной стороны была сложная предметная область, с другой неудобные языки программирования, так что мало кто хорошо владел и тем, и другим, создание ФЛОКС'а было полезным шагом.
Я тоже думаю, что на существенную популярность у него шансов крайне мало (особенно среди программистов). Но некоторые узкие ниши для ДРАКОН'а найтись могут. Идея с адаптированным под предметную область "медицинским Драконом" (или, там, с "юридическим Драконом", про который я встречал упоминания) имеет какие-то шансы сработать.
я прекрасно знаю, чем "тот Пролог" отличался от "этого Пролога". Даже приводил в предыдущей ветке пример кода на Прол2. Lа, "в тех условиях" работающая система перевода блок-схемы в код была бы пару лет полезной. Но нюанс в том, что "в тех условиях" работающей создать не смогли (как по объективным причинам - отсутствие доступности графики, так и по субъективным - качество авторов методики. Они за 30 лет не смогли написать ни нормальной среды разработки, ни компилятора, ни эмулятора - хотя инструменты давно общедоступны. "лучший инструмент" написан на дельфях прошлого века и хранит данные в csv. Ну вот серьезно, вы примете медицинские советы от врача, покрытого язвами, с качающимися зубами, и истекающего поносом?).
Поэтому вместо "программирования инженерами" (что получилось чуть позже автоматически из-за введения программирования в курс обучения инженеров) или "создания интерфейсов инженер/программист" (чем занимались америкосы лет на 20 раньше) сделали прокладку: дураконщики, которые выслушали инженеров, нарисовали блок-схемы на своем дураконе, и "отдали программистам на кодирование"(ц)...
Р-технологии, выросшие примерно из тех же предпосылок, хотя бы заработали. На алфавитно-цифровых терминалах, со всеми ограничениями, но хоть как-то... Но и они закономерно померли, когда появились интерактивные IDE. Зато не смердели.
А "узкие ниши"... у этих "не просто блок-схем, а формализованных" нет никаких преимуществ для конечного пользователя (исполнителя), зато есть для него недостаток - объемность (низкая плотность) и неудобство в использовании. Есть некоторые преимущества для составителя-идиота (совсем "наговноалгоритмить" у него не получится), но нет никаких преимуществ для составителя - нормально мыслящего человека.
Но, на мой взгляд, если человек не может внятно написать алгоритм на бумаге простым текстом/таблицей - то у него в голове бардак, и либо ему надо давать консультанта/помощника, либо гнать в шею. И для юриспруденции и медицины хватит (более чем достаточно) как "школьных блок-схем", так и любой BPMN (ибо сложных циклических алгоритмов там практически нет. Данные проверять не надо). А если учесть, что в BPMN - системах реализованы и рисование по правилам, и проверка, и симуляция, и документирование, и разделение по исполнителям и по процессам - то и в этих "узких нишах" у дуракона шансов уже нет. Он родился мертвым. Сразу.
Поскольку в статье никакие образцы не приводятся, приходится взять два примера из Википедии: Первая помощь при химическом ожоге глаз жидкостью
Прекрасный, кстати, пример "читаемости". При первом взгляде кажется, что в действии есть какой-то цикл (потому что есть стрелка, ведущая из концов первой и второй ветки в начало), но в реальности никакого цикла там нет, алгоритм строго последовательный: "промывание глаз водой" — "промывание глаз нейтрализующим раствором" — "лекарственная обработка".
Что занятнее, на самом деле, цикл там есть, потому что во второй ветке написано "продолжай промывать водой", что должно обозначать возврат в первую ветку, но средствами языка это никак не выражено, это надо просто понять головой, что действия те же самые. О какой однозначности можно говорить при такой нотации?
Если такие запутанные схемы — это преимущество использования дракона, то имхо, и даром такого не нужно.
Картинка из Википедии устарела. В ней есть ошибка, связанная с ограничением 10-15 минут.
С тех пор недостаток исправлен, медицинский язык ДРАКОН доработан. В медицинский язык ДРАКОН введены две новые иконы:
1. Начало контрольного срока. В иконе Начало пишут контрольное время критической процедуры, например, «30 сек».
2. Конец контрольного срока. В иконе Конец указывают окончание контрольного времени, например, «Прошло 30 сек».
Исправленный рисунок см. в книге на стр. 215 рис. 132.
Сергей, советую вам почитать эту книгу. Она написана в 2019 году. Многие ваши вопросы отпадут. В ней 200 дракон-схем.
Две новые иконы входят в состав медицинского варианта языка ДРАКОН.
В основном варианте языка ДРАКОН (для программирования) они не нужны и не используются.
В ней есть ошибка, связанная с ограничением 10-15 минут.
… и это единственная ошибка, которую вы там видите?
Исправленный рисунок см. в книге на стр. 215 рис. 132.
Ошибки, на которые я указывал, не изменились, а начало/конец контрольного срока сделало хуже, а не лучше.
Сергей, советую вам почитать эту книгу. Она написана в 2019 году. Многие ваши вопросы отпадут.
Пробовал. Не помогает.
Поскольку в статье никакие образцы не приводятся...Это не так. В статье приводятся два примера:
Рис. 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.
Про вторую схему отвечу отдельно позднее.
Самое главное. Рисовать клинические алгоритмы на языке ДРАКОН должны профессиональные врачи, как это активно делают врачи в Литве и как это делают в единичных случаях врачи в России.
Клинические алгоритмы на языке ДРАКОН должны критически обсуждаться врачами, дорабатываться врачами и публиковаться на основании консенсуса.
Кстати, подскажите по поводу Рис. 4. Клинический алгоритм силуэт «Реанимация беременной женщины».
Там на одном из "шампуров" есть ветвление "есть функция автоматической внешней дефибрилляции". Отрицательная ветка этого ветвления возвращает нас к шампуру и без каких-то действий (и ожидания реанимационной команды) ведёт к дальнейшей помощи.
Объясните мне, как не медику, что это значит? Если в клинике дефибриллятор без автоматики, то мы забиваем на какие-либо реанимационные действия? Или пытаемся выполнить специализированную реанимацию, которую в норме должна выполнять специально обученная команда (т.е., выполняем действия за пределами своей квалификации)? Или дефибрилляторов без автоматики не бывает? Если последнее, то зачем вообще нужна эта проверка?
Оставлю заодно своё мнение: любая блок-схема (а ДРАКОН - это разновидность блок-схемы, пусть и со своими жесткими правилами) полезна для придания наглядности представлению алгоритма при следующих условиях: 1. алгоритм не слишком сложный; 2. алгоритм необходимо понятно представить большому количеству человек; 3. алгоритм не меняется. Боюсь, применение в медицине очень ограничено оправдано по всем трём пунктам (далее мой взгляд со стороны, который не обязательно правильный, т.к. я не медик): 1. есть довольно сложные алгоритмы + массовые пересечения (алгоритм какой-нибудь потенциально рисковой манипуляции может быть в какой-то момент прерван для выполнения алгоритма реанимационных действий, при успехе необходимо правильно вернуться на предыдущий алгоритм, либо отказаться от выполнения манипуляции, подобных переключений может быть довольно много); 2. на этапе начала обучения применение может упростить понимание, но не заменяет нормальный текст, плюс, есть риск приучить будущих специалистов к т.н. клиповому мышлению (привычка получать наглядный материал приводит к тому, что мозг не хочет воспринимать более сложные представления информации и самостоятельно строить наглядную картинку, хотя последнее позволяет лучше освоить материал), впрочем в случае covid-19, когда необходимо срочно обучить кучу человек правильной последовательности действий, применение блок-схем вполне оправдано; 3. вот тут проблема достаточно явная: медицина - достаточно быстро развивающаяся область и очень высокий риски того, что пока вы печатаете учебник, содержащий блок-схемы, часть из этих блок-схем уже устареет, студенты запомнят неправильную картинку, а описание с обновлённым алгоритмом могут и проигнорировать.
В области computer science большинство алгоритмов описано текстом, для наглядности в основном демонстрируются вспомогательные вещи: структуры данных, графические представления графов, этапы обработки на разных стадиях алгоритма. Блок-схемы тоже встречаются, но в большинстве случаев их не рисуют, т.к. по сравнению с хорошо формализованным (и удобно отформатированным) текстом, они не привносят наглядности, а набирать (и править) текст гораздо проще. Хотя в каких-то книжках пытались всё рисовать блок-схемами, но, как мне кажется, особой распространённости они, вроде, не получили, по сравнению с книжками, где алгоритмы описаны текстом.
Или дефибрилляторов без автоматики не бывает? Если последнее, то зачем вообще нужна эта проверка?Я скопировал схему из литовского учебника на русском языке. Ваши вопросы законны. Это вопросы не ко мне, а к авторам из Литвы.
любая блок-схема (а ДРАКОН — это разновидность блок-схемы, пусть и со своими жесткими правилами) полезна для придания наглядности представлению алгоритма при следующих условиях: 1. алгоритм не слишком сложный; 2. алгоритм необходимо понятно представить большому количеству человек; 3. алгоритм не меняется.Не могу согласиться. ДРАКОН — не разновидность блок-схем (хотя и похожи на них). Алгоритмическую макроконструкцию силуэт нельзя изобразить в виде блок-схемы.
В блок-схемах формализованы только фигуры, но не связи между фигурами. В ДРАКОНе проведена полная математически строгая формализация графики: формализованы и фигуры, и соединительные линии. Методом визуального логического исчисления (визуальная математическая логика), который встроен в правильно построенный ДРАКОН-конструктор.
Ваши три пункта к ДРАКОНу не относятся. Чем сложнее алгоритм, тем больше выигрыш от использования ДРАКОНа.
Некоторые люди программируют на ДРАКОНе (например на гибридном языке Дракон-Си).
Индивидуальный предприниматель Сергей Ефанов сообщает:
Использую ДРАКОН уже десять лет (с 2010 года) при программировании микроконтроллеров: PIC (Microchip), MSP430 (Texas Instruments), STM32 (STMicroelectronics).
За это время с помощью программы ИС Дракон я сделал несколько десятков проектов: торговые автоматы, блоки защиты электродвигателей, GPS-трекеры, GSM-устройства и др.
Когда пришлось столкнуться с незнакомой ранее темой торговли, управления контрольно-кассовыми машинами — ДРАКОН просто спас. Без него я бы, наверное, не смог быстро привести сеть торговых автоматов в соответствие с новым федеральным законом «54-Ф3».
Прекращать, или сокращать каким-либо образом применение ДРАКОНа не планирую.
Чем сложнее алгоритм, тем больше выигрыш от использования ДРАКОНа.
К сожалению, вы ни разу не смогли никак доказать это утверждение.
Использую ДРАКОН уже десять лет
Я читал про художника, который
нарисовал портрет Гитлера собственным калом
О чём это говорит? Так тоже можно, но остальные художники почему то используют другие материалы.
Вот такая вот аналогия, сорри. Пока остальные придумывают разные методики работы с кодом (статистические анализаторы, VCS, автотесты..), драконисты просто утверждают, что их стюардесса живее всех живых, и волосы у нее самые красивые by design.
Медицинский язык ДРАКОН создан в космической отрасли для записи алгоритмов действий врача (клинических алгоритмов)
принесен богами из параллельной вселенной, ага-ага
А удивляет меня вот что. Десятилетия назад были уже алгоритмические блок-схемы в ходу, чтобы никто не изобретал велосипед и не проходил один и тот же квест заново. Но когда мы смотрим на наше IT, то тут, кругом в лучшем случае «заметки на полях», вместо недвусмысленных инструкций по диагностике типичных проблем. Описания багов, в среднем — полный мрак, люди как будто слово алгоритм не слышали. Какой-то парадокс. Продиагностировать и исправить человека проще чем компьютерную систему.
Это компьютерные системы такие сложные, или пласт методологических наработок из недалекого прошлого куда-то пропал?
Это люди такие ленивые, что им неохота (а) писать скучные инструкции и (б) следовать скучным инструкциям. Я видел много разработчиков (включая того, который в зеркале), которым интереснее пойти решать следующую задачу, нежели написать инструкцию на только что сделанную работу.
или пласт методологических наработок из недалекого прошлого куда-то пропал?
Ох уж эти "великие, но утраченные советские технологии" и страдальцы по ним.
Думающему человеку легко понять, что причина "утраты" в том, что чёткие блок-схемы неприменимы к нашему миру с нечёткой логикой.
Не все инженеры могут это чётко сформулировать, но все они знают, что чёткие схемы работы - неприменимая в реальной жизни ерунда.
Тот же ДРАКОН из статьи - это же шаг назад, вернее, это десять шагов назад в медицине для постановки диагноза и лечения. Десятилетия назад для медицины были изобретены экспертные системы, основанные на нечёткой логике. И успешно применяются.
Например, по блок-схеме всё стабильно идёт по какой-то ветке. Но в конце ветки надо проверить, болит ли у человека голова. И если болит, то назначить такое-то лечение. А в реальности у него голова болит, но лишь чуть-чуть. Но зато очень сильно болит жoпа. И это должна быть уже совсем другая ветка лечения и другие препараты. Ваши великие советские блок-схемы бы просто угробили человека.
Получается, делать четкие инструкции - трудозатратно (читай -дорого) и неэффективно, особенно в сфере где все быстро меняется. И на смену пришли wiki-подобные системы, и прочие контекстные базы знаний и экспертные системы. Поскольку позволяют децентрализованно и сравнительно легко обновлять информацию.
Кстати, в Германии я первый раз увидел у юристов и бухгалтеров, сборники законов которые были в папках-скоросшивателях. Пришли новые листы с обновленными статьями по подписке, вставил - готово.
Ох уж эти "великие, но утраченные советские технологии" и страдальцы по ним. Думающему человеку ..
Ох уж эти комментаторы, которые не могут обойтись без колкостей. У меня нет ностальгии по советскому времени. И мой вопрос вообще не связян с применением блок схем в медицине и Дракона в частности. Он более общего плана, но я "человек думающий", и смог сделать нужные мне выводы. Спасибо.
Ох уж эти комментаторы, которые не могут обойтись без колкостей.
Прочитал своё сообщение - действительно, грубовато получилось, извините!
С другой стороны, вы своё тоже очень провокационно составили. Мол, "раньше были технологии ого-ого, а сейчас одни дебилы, почему так?". По крайней мере так можно было вас понять.
Так как я причисляю себя к тем, кто двигает разработку прямо сейчас (ну свою каплю в океане мировой разработки), то мне крайне неприятно читать подобные высокомерные высказывания. Не конкретно ваши, их просто очень много подобных в сети.
Получается, делать четкие инструкции - трудозатратно (читай -дорого) и неэффективно, особенно в сфере где все быстро меняется.
В медицине всё небыстро меняется. Я так-то как раз разработчик программ для медицины. И там самое главное - проверка проверок на проверки. И куча документации с подписями. Любое изменение - переработка ещё и тонн документации. На такое идут крайне редко.
Но если можно было бы сделать супер-гигантскую блок-схему в стиле ДРАКОНа, её бы сделали. Акцент тут именно на том, что это не работает на человеках.
Он более общего плана, но я "человек думающий", и смог сделать нужные мне выводы. Спасибо.
Ахахах, пожалуйста) Как я уже говорил - извините. Но у меня это когнитивное искажение из-за тимлидской работы. Может и грубовато сказал, зато сразу дошло :)
Сравнительно недавно вы писали про Дракон в области описания блок-схем и замены ГОСТ 19.701-90.
Теперь вы решили расширить область его применения?
Теперь вы решили расширить область его применения?Это решил не я. Это решили врачи. Врачи решили использовать язык ДРАКОН в медицине. Первым высказал эту идею Альгирдас Каралюс из Литвы. Он прочел мою книгу 1998-1999 года и рассказал своему другу Паулюсу Добожинскасу. С тех пор ДРАКОН живет в Литве, в литовской медицине.
Стало любопытно, захотел потыкаться. Едва нашел. Скачал. С облака Мэйл.Ру - официальная ссылка. Первое, что у меня попросили - активацию (в демо режиме работаем, да). Инструкция по активации - создать файл запроса, отправить автору. В инструкции на виду нет информации об авторе, в процессе активации контакт автора в глаза не бросается.
В текстовой инструкции - платить автору на сбербанк, реквизитов нет.
Текста лицензии нет. Цитата:
У автора нет документа - лицензии к программе. Разбираться в вопросах связанных с лицензией нет желания, т.к. вероятно это сложная и специфичная область.
Дружелюбие и открытость зашкаливает:
Для связи с автором, возможно, использовать электронную почту, оперативно Скайп.
При этом в файле "Активация.txt" нет ни одной "@" и 2 гиперссылки - на форум про получение учебной лицензии и на сайт конкурентов. На сайте конкурентов "1 октября 2021 года совсем закроемся".
По медицине Вы не туда обратились. Вы обратились к ДРАКОН-конструктору Геннадия Тышова. Его программа позволяет программировать на ДРАКОНе.
По медицине надо обратиться на DrakonHub. Насчет закроемся с 1 октября — это не так. Не обращайте внимания
Так и случилось, но не у нас, а в Литве, где с помощью алгоритмов действия врачей, написанных на языке ДРАКОН, обучают 9 000 медицинских работников и студентов в год.
Доказательства, пожалуйста, предъявите.
Моя статья называется:
Медицинский алгоритмический язык ДРАКОН против пандемии и не только. Статья для профессиональных врачейМеня очень интересует мнение врачей.
В комментариях я нашел только двух профессиональных врачей Knkplua и SQLap.
SQLap любезно сообщил, что работает «врачом акушером-гинекологом, правда в гинекологии, а не в роддоме».
Есть ли еще врачи? Если есть, просьба сообщить.
(del)
Я профессиональный врач (инфекции и организация здравоохранения). По сабжу - как описание ургентных процедур все выгдядит хорошо, но:
если я профессионал, то в своей специальности я знаю стандарты лечения наизусть, а алгоритм меня ограничивает, а за отступления от него (если его введут в нормативку) меня посадят.
если это не моя специальность, то я до пациента даже не дотронусь - т.к. в случае его смерти никому в суде не интересно будет что читал инфекционист угробивший человека с травмой спины например.
Так что оставьте игры разума для любителей....
(автонумерация в мобильной версии хобра - ад, простите меня духи предков за неттключенные п. 3 и 4)
Приветствую вас как профессионального врача. Спасибо, что заглянули. Вы уже третий профессиональный врач на этом обсуждении.
так что оставьте игры разума для любителейЗря вы так. Как я понимаю, статью вы не читали? Я поясню.
О чем говорится в основном разделе статьи?
habr.com/ru/post/539786/#%D0%A7%D0%B0%D1%81%D1%82%D1%8C3
О том, что четыре опытных профессиональных врача по своей инициативе прочитали мою книгу по клиническим алгоритмам на языке ДРАКОН и внимательно ее изучили.
Затем они разработали Программу дополнительного обучения врачей реаниматологов-анестезиологов по курсу «Интенсивная терапия осложнённых форм коронавирусной инфекции».
Для этой программы они разработали 17 клинических алгоритмов на языке ДРАКОН и обучили 30 врачей реаниматологов-анестезиологов в реальных условиях COVID-больницы за неделю до приема первых COVID-пациентов.
Благодаря наглядности и высокой точности языка ДРАКОН обучение прошло быстро.
А без ДРАКОНа можно? Конечно, можно. Но будет медленнее. А в условиях COVID-19 время не ждет.
если я профессионал, то в своей специальности я знаю стандарты лечения наизустьОбучаемые были профессиональными реаниматологами-анестезиологами, но они не были знакомы с протективной респираторной терапией в условиях осложненных форм новой корнавирусной инфекции.
Входной контроль знаний перед обучением прошли лишь три участника из 30.
алгоритм меня ограничиваетВы говорите о плохих алгоритмах, который не отражает полной картины. Хороший алгоритм не ограничивает, а помогает.
На этапе отработки алгоритма, врач в случае необходимости может и должен отступать от алгоритма. Алгоритм всегда создается для определенной модели пациента. А больной может отличаться от модели.
Все эти вопросы подробно рассмотрел много лет назад главный врач туберкулезной больницы пионер клинической алгоритмизации в России Владимир Тавровский.
за отступления от него (если его введут в нормативку) меня посадят.Ну, до нормативки еще очень далеко.
Зря вы так. Как я понимаю, статью вы не читали? Я поясню.
вы живете в мире своих убеждений и проецируете его на объективную реальность: статью я читал очень внимательно, медицинские экспертные системы это мое хобби уже лет 15, про язык «ДРАКОН» я знаю давно и слежу за развитием, мало того, одно время использовал его в работе.
Благодаря наглядности и высокой точности языка ДРАКОН обучение прошло быстро. А без ДРАКОНа можно? Конечно, можно. Но будет медленнее. А в условиях COVID-19 время не ждет.
с этим я не спорю, методически ДРАКОН весьма хорошая штука, я вообще с института все пытался загонять в схемы и таблицы (жуткое наследие математического класса :)
и даже по МР ковидным для себя схемы рисовал. но это я. моя коллега (бОльший профессионал) переваривает только текст и делает это быстрее, чем я диаграммы, у каждого своя особенность восприятия.
Вы говорите о плохих алгоритмах, который не отражает полной картины. Хороший алгоритм не ограничивает, а помогает.
хороший алгоритм учит думать, не более. в практике он не особо применим, кроме очень узкого круга простых последовательностей.
Алгоритм всегда создается для определенной модели пациента. А больной может отличаться от модели.
т. о. каждый больной — новый алгоритм (я утрирую, но чисто математически это так, любой новый вектор в алгоритме — новый алгоритм, новый весА в критерии — новый алгоритм, наличие ОДНОГО противопоказания в критической точке — новый алгоритм)
поэтому я и говорю, что алгоритмизация полезна для размышлений, разработки порядков, приведения в порядок своих мыслей, но не для повседневки.
Ну, до нормативки еще очень далеко.
наши ограны госвласти непредсказуемы: фуфломицины в стандартах лечения, диагностика по фолю в критериях приема людей в мвд… да тыщи их внезапных решений по распилу внезапно пролобированого бабла…
статью я читал очень внимательноСпасибо. Я рад слышать мнение и критические замечания профессионального врача.
про язык «ДРАКОН» я знаю давно и слежу за развитием, мало того, одно время использовал его в работеСкажите, а как вы его использовали? Вы рисовали дракон-схемы карандашом на бумаге?
Или использовали универсальный графический редактор типа Visio или CorelDRAW?
Или использовали ДРАКОН-конструктор DrakonHub? Сегодня это наилучший инструмент для изображения клинических алгоритмов.
с этим я не спорю, методически ДРАКОН весьма хорошая штука, я вообще с института все пытался загонять в схемы и таблицыПонимаю.
даже по МР ковидным для себя схемы рисовалЧто такое MP? Как расшифровать?
хороший алгоритм учит думать, не более. в практике он не особо применимЯ имею в виду вот что. Ко мне обратился Павел врач невролог, рефлексотерапевт, стаж 13 лет из Самарской области,
Он попытался самостоятельно освоить программу «ИС Дракон» Геннадия Тышова, но у него возникли трудности.
Павел попросил меня провести с ним занятие по ДРАКОН-алгоритмам.
Я провел занятие по скайпу, научив его пользоваться программой DrakonHub в режиме Скайпа Демонстрация экрана. Под моим руководством на сайте DrakonHub он нарисовал дракон-схему силуэт — простейший диагностический алгоритм по неврологии. Он освоил идею за час времени, а затем (уже после занятия) стал доводить алгоритм до кондиции. Мы договорились, что он пришлет алгоритм мне на проверку.
В моем представлении желательно сделать единый обширный алгоритм, разбитый с помощью иконы Вставка на множество обозримых взаимосвязанных частей. А в элетронном виде при нажатии на Вставку мы автоматически переходим в нужный алгоритм-процедуру. Программа DrakonHub всё это обеспечивает.
наличие ОДНОГО противопоказания в критической точке — новый алгоритмЯ бы эту мысль выразил чуть иначе. Наличие ОДНОГО противопоказания в критической точке означает, что надо добавить развилку (икону Вопрос), и к правому выходу прицепить икону Вставка (подразумевающую уход в новый алгоритм).
Приглашаю вас на форум ДРАКОНа forum.drakon.su
Достаточно наглядными примерами сверхценных идей являются, например, идеи изобретательства, которым автор какого-либо изобретения придает неоправданно большое значение, считая свое изобретение исключительным по важности и самым ценным для науки. Такие люди чрезвычайно активно настаивают на немедленном внедрении своих новаций в практику, причем требуют проводить такое внедрение в самых широких масштабах, что, в действительности не соответствует их реальной значимости. Сами же больные глубоко убеждены, что их работа — самая важная и значимая, они подчеркивают свои заслуги и возможности использования внедряемых проектов. Несправедливое, как считают подобные люди, отношение к их творчеству, что заключается в «недостаточном» внимании, вызывает у них ответную реакцию, которая также становится доминирующей в сознании. Внутренняя переработка больными подобной ситуации резко усиливает остроту и эмоциональный заряд самого переживания.
я не врач, если что.
Эта статья для профессиональных врачей.
Возможно, вам будет интересно прочитать на Хабре статью профессионального программиста о языке ДРАКОН:
Митькин С.Б. Визуальное программирование на языке ДРАКОН. — Хабр, 2017 ( rykkinn )
Непонятна экзальтация автора по поводу еще одного языка описания алгоритмов. Вся статья написана в стиле "Магазинов на диване", без передышки убеждающих перейти на ДРАКОН, ибо "Язык ДРАКОН несопоставимо превосходит все конкурирующие предложения". Статья рассчитана на врачей - хорошо, но Хабр больше технический ресурс, и думаю, что именно врачей здесь как раз не так много. Чего же хочет автор?
Вероятно разработка хорошая и полезная, но здорово облегчить труд врачей может тот, кто избавит их от необходимости заниматься изнурительной ПИСАНИНОЙ.
В капстранах считается, что врач это высоквалифицированный специалист время которого стоит дорого, они там в доинтернетную эпоху додумались до связки "наговаривать в диктофон и потом машинистка расшифровывает и вбивает текст".
У нас же административные необходимости и бумажные дела перекидываются на плечи и без того замученных врачей.
Почему они должны диаграммы рисовать, вы точно верно поняли что я говорил?
Почему они должны диаграммы рисовать
Мне тоже кажется, что вроде как не должны. Но кто же тогда должен рисовать диаграммы? Потому что программисты, рисующие диаграммы для врачей — это как-то ещё хуже.
Какие врачи? Опытные и знающие специалисты, которые обладают глубокими знаниями, ученые, преподаватели. Или под руководством ученого, его помощники, молодые врачи, владеющие графическим редактором.
Изобретать велосипед иногда полезно, если при этом появляется совсем другой результат. Т.е. методом даже того-же ТРИЗ можно всегда в что-то новое добавить что-то и получить совсем другое. Или лучшее или специализированое для опревделённых задач итд.
С языком Дракон происходит совсем другое. Изобрели тоже самое, что уже до этого существовало. Но то - вдруг описывается как что-то плохое и Дракон здесь вроде-бы как лучше. Хотя на самом деле блок-схемы уже используются всё реже и реже (так у неспециалистов в MS Office набростать плоские и несложные схемы), а многое новое описывается языком BPMN. Потому что это удовлетворяет современным требованиям намного лучше, чем какие-нибудь блок-схемы типа EPK или как в этой статье - языка дракона.
И использование кричащих названий (как в желтой прессе) только усугубляет всё с этим языком связаным. Он не создавался как медицинский, здесь-же он показан как медицинский. В других статьях он может стать языком архитекторов, композиторов или специально для мясо-комбината. Плюс - указание на "Русский Алгоритмический язык". Русским может быть человеческий язык, культура, но ни как не язык программирования.
Даже немного смешно, когда заходишь на их сайт drakon.su, а там стоит "Дружелюбный Русский Алгоритмический язык", а гиф(ка) показывает развития алгоритма и все тексты там на ангклиском. Короче - какой-то оксюморон.
И авторам не понять, почему нет того восприятия, как они его ожидают. Им невдомёк, что создали то, что уже давно существовало до них. И маленькие рюшечки в виде тонкой или толстой линии, или кружочки в циклах - просто мелочи, которые ничего конкретного не улучшают. И для более обширных задач есть современные подходы.
Это больше на плагиат похоже, чем на создание чего-то нового.
_это_ возникло из суровой советской действительности конца 70-х. Когда ЭВМ были большими, программистов было мало, инженеры программировать не умели (и учиться этому не желали), а инструментарий был не самый дружелюбный (языки типа ПРОЛ-2). Организовывать взаимодействие между инженерами и программистами (примерно то, что делали американцы в своей программе Аполлон) получалось скверно, в том числе и потому, что было принято решение копировать S/360 и «тырить» софт. Поэтому был нужен инструмент для «программирования непрограммистами». Но пока его создавали — компьютеры сильно уменьшились в размерах, стали гораздо более быстрыми и доступными (даже в СССР обладать компьютером смогли уже не только ВЦ НИИ и ВУЗов, но и отдельные кафедры и лаборатории, а затем и частные лица), а изучение программирования с 83-85 стало обязательным для студентов ВУЗов всех технических специальностей (не только ПРИМА/ЭВМ) для расчетных применений, а для студентов ВУЗов специальностей связанных с управлением (САУ/АиТ/ИнИТ/ЦРТС) — и для целей моделирования и построения этих систем на цифровых вычислителях. А в 1987-89 такой предмет, как ОИВТ, появился и в средних школах (кое-где «номинально-бумажно», а кое-где вполне серьезно). И после недолгого царствования бэйсика в школах укоренился паскаль, который как раз «без goto». Ну а в профессиональном программировании столько всего сменилось и далеко ушло от ПРОЛ-2 и программирования на бумаге, что даже простое перечисление тянет на хорошую статью. а ДУРАКОН не сдвинулся за эти 40 лет с места. Он там и торчит, в 1980-х — там, где ПРОЛ-2, 8-символьные идентификаторы, «страшные логические отрицания», верификация «пальцем по бумаге», архивирование с помощью подшивки распечатаных на бумаге «икон на шампурах» в бумажные же папки…
Разработчики этого ДУРАКОНа не видели современных IDE (в лучшем случае — дельфи середины 90-х), и давно не занимались программированием. Они вместо этого пишут книги и выступают на конференциях…
- Всё визуальное — это только для здоровых и спортивных людей. Как будут программировать люди, например, с ограничениями зрения или подвижности?
- Как с визуальным кодом будут работать утилиты автоматизации, например, для рефакторинга?
- Усложнение алгоритма приводит к нелинейному росту «площади» программы, появляются горизонтальные и вертикальные полосы прокрутки, постоянные изменения масштаба холста.
- Как вы будете делать визуальную разницу между двумя коммитами в системе контроля версий?
2. нужно написать эти самые утилиты ;)
3. декомпозиция на небольшие по площади подпрограммы должна помочь. Кстати, функции в 100500 строк в традиционных языках тоже не приветствуются ;)
4. нужно всего лишь написать diff.dracon и patch.dracon ;) diff для текста ведь тоже не с неба свалился.
Самое печальное — пункты 2 и 4. Евангелисты Дракона асилили только редактор, да и тот c непонятной лицензией. С таким настроем слона не продать ;)
и, конечно, хабр не для профессиональных докторов, поэтому здесь интереснее технологичность решения: было бы интересно отдельно видеть ui для конструктруирования блок-схем как отдельный проект, который можно встроить в другие продукты
в целом, по статье и по подходу — лютая академичность и совковость. Вы все инструменты переизобретаете на свои «не имеющие аналогов на западе».
хотя вполне вероятно все эти схемы Дракона близки к диаграммам UML. Где вы отчасти решили некоторые проблемы типа лейаута элементов.
свой формат drn — это sqlite с кодом внутри? зачем так?
прикольно, как можно 20 с лишним лет выезжать на визуализации Бейсика )))
Язык ДРАКОН существенно отличается от блок-схем и других средств, которые здесь упоминали. Я написал по ДРАКОНу около десятка книг, большая часть которых доступна в сети. Тем не менее, у многих коллег остаются вопросы.
Ближайшим аналогом языка ДРАКОН являются не блок-схемы, а Р-схемы и Р-технология, созданная доктором физико-математических наук из института Кибернетики в Киеве.
В этом сообщении я расскажу о подавлении ошибок с помощью языка ДРАКОН.
БЕЗОШИБОЧНОСТЬ ПРИ ОПИСАНИИ ПОТОКА УПРАВЛЕНИЯ
Важную роль играет замена служебных слов потока управления на управляющую графику.
Потенциально опасные текстовые средства потока управления можно заменить на безопасные визуальные средства управления.
Начну с истории. В 1968 году Эдсгер Дейкстра в журнале «Communications of the ACM» указал, что оператор goto, используемый во многих языках программирования высокого уровня, является основным источником ошибок и потому должен быть запрещен [54].
Затем Бертран Мейер выявил еще два опасных элемента — операторы break и continue, который также следует запретить как замаскированные goto. По словам Мейера, это те же старые «goto в овечьей шкуре» [55, p. 210].
Еще дальше идет И. В. Вельбицкий, который считает, что из программирования следует исключить
«ключевые слова-паразиты и соответствующие им конструкции языков типа: goto, if, for, while, break, begin-end, {-} и т.д…Эти конструкции являются основным источником ошибок и проблем в современном программировании» [56].Язык ДРАКОН продолжает и развивает традицию, начатую Дейкстрой и продолженную Мейером и Вельбицким. Традицию, направленную на выявление и изгнание потенциально опасных операторов управления, которые могут послужить причиной ошибок.
В ЧЕМ ИДЕЯ
Идея проста и сводится к двум положениям:
- надо выявить опасные служебные слова и знаки, используемые в операторах управления, и запретить их;
- вместо них следует использовать безопасную графику.
Все они подлежат замене на математически строгую графику управления.
Графика реализует ту же самую функцию, что и забракованные операторы и служебные слова.
Замена текстовых операторов на их точные графические эквиваленты означает, что язык ДРАКОН использует двумерное (2d) структурное программирование [39, pp. 425-472].
Последнее можно рассматривать как дальнейшее развитие одномерного (1d) структурного программирования, которое создали Эдсгер Дейкстра, Тони Хоар, Оле-Йохан Дал [57] и др.
Участник lair пишет:
Может быть, вы можете привести примеры типичных ошибок, число которых позволяет уменьшить использование ДРАКОНа?Отвечаю: это ошибки, связанные с использованием перечисленнных опасных операторов и служебных слов.
Подробно об этом можно прочитать в моей книге на стр. 296-232.
Потенциально опасные текстовые средства потока управления можно заменить на безопасные визуальные средства управления.
Средства управления в ДРАКОНе не являются безопасными.
Идея проста и сводится к двум положениям:
Эту "идею" уже обсуждали, и ее состоятельность так и не доказана.
Графика реализует ту же самую функцию, что и забракованные операторы и служебные слова.
Если графика реализует ту же функцию, то она содержит и те же ошибки. Вероятно, все-таки функция не та. Но как можно реализовать "не ту" функцию в операторе if?
Отвечаю: это ошибки, связанные с использованием перечисленнных опасных операторов и служебных слов.
Конкретные примеры в студию, "или ничего не было".
Подробно об этом можно прочитать в моей книге на стр. 296-232.
Приведу один пример (с. 297):
Автор считает слово while, имеющее простой и понятный смысл, "паразитным элементом" и "неоправданным усложнением", хотя это всего лишь слово "пока". Иными словами, запись while (n < 50) читается как пока n < 50. Наибольшую проблему в этом примере представляют не "паразитные элементы", а постфиксный оператор — который автор проблемой не вовсе не считает. Вот что предлагает автор:
Как видим, постфиксный оператор на месте. Так от какой же ошибки нас защитила эта запись?
Автор, вероятно, не в курсе, что для борьбы с циклами давно придуманы последовательности (иными словами, вместо n = 0; while (n++ < 50) пишут repeat(50), что намного понятнее приводимой автором схемы), а для борьбы с излишним ветвлением — полиморфизм. Ничто из этого не выразимо в ДРАКОНе.
for each n in [0..50]:
x = z + n
w = z - nЯ утверждаю, что эта запись менее склонна к ошибкам и более читаема, чем предлагаемая автором запись с постфиксным оператором и петлей на графике.
Ммм... дочитать со страницы 296 до страницы 232? И это шесть страниц? Какая занимательная арифметика.
Дочитал (не первый раз уже), ничего не поменялось.
Из той же книги:
Автор утверждает, что он избавился от логического отрицания, тем самым облегчив чтение. Так вот, нет. Потому что когда выходы из условия означают разное (т.е. выход "вниз" означает как "да", так и "нет"), чтение схемы замедляется, потому что необходимо читать слова у веток. Иными словами, чтение слова "нет" перед условием мы заменили на чтение слова "нет" у ветки. Лучше не стало.
И вот почему.
Да и Нет — простые слова, понятные даже ребенку, даже дошкольнику.
А логические связки — вещь сложная. Они под силу только студенту, после изучения логики.
Нельзя сравнивать простые слова с логическими операциями. Это несопоставимые по сложности вещи.
Да и Нет — простые слова, понятные даже ребенку, даже дошкольнику.
А логические связки — вещь сложная.
То есть вы хотите сказать, что дошкольнику понятно условие "красный — нет", но не понятно условие "не красный"?
Я не вижу оснований вам верить.
То есть вы хотите сказать, что дошкольнику понятно условие «красный — нет», но не понятно условие «не красный»?Я этого не говорил.
Логические связки обозначаются специальными знаками, которые надо изучать и запоминать.
Многим людям это не под силу, они ошибаются. Они боятся формул и избегают их.
Надо помочь таким людям, что я и делаю.
Особенно это важно для врачей.
Логические операции спрятаны в графическом чертеже и становятся невидимыми. Графика языка ДРАКОН хороша тем, что позволяет полностью отказаться от логических математических
формул (стр. 141).
Строгость алгоритмов полностью обеспечивается, но не формулами, а приятной графикой, которая не создает никаких трудностей для врачей.
Подробнее об этом можно прочитать в моей книге для врачей
Глава 8. Логика в медицине и невидимая математика… 122см. здесь стр. 122-151
Логические связки обозначаются специальными знаками, которые надо изучать и запоминать.
Так вас никто не заставляет использовать специальные знаки, используйте слова. Язык Python, с его not, показывает, что это прекрасно возможно.
Логические операции спрятаны в графическом чертеже и становятся невидимыми.
Не становятся. У вас логические выходы подписаны, их видно.
Строгость алгоритмов полностью обеспечивается, но не формулами, а приятной графикой
Неа. Никакая "приятная графика" не избавляет от необходимости читать подписи к выходам из ваших условий. А без этого чтения не будет никакой "строгости алгоритма".
На этой схеме, приведенной в разделе "Язык ДРАКОН помогает програмировать без ошибок" есть (очевидная) логическая ошибка.
Если графика реализует ту же функцию, то она содержит и те же ошибки.Это не так.
Графика реализует ту же самую функцию, что и забракованные операторы и служебные слова.Эта фраза означает, графика и текст математически эквивалентны. Но эргономически они отличаются. Текст глаз и мозг воспринимают приемущественно сукцессивно (последовательно), а графику преимущественно симультанно (одномоментно, разом).
Это не так.
Нет, это именно так. Назовите мне "ошибку" оператора goto, которой лишен ваш эквивалент, и я назову вам функцию, которой в вашем эквиваленте нет.
Эта фраза означает, графика и текст математически эквивалентны.
Что вы назваете "математически эквивалентны"?
Но эргономически они отличаются.
Отличаются, да. Но вот только "отличаются" не означает "графика лучше" и тем более не означает, что ваша графика лучше.
Текст глаз и мозг воспринимают приемущественно сукцессивно (последовательно), а графику преимущественно симультанно (одномоментно, разом).
Во-первых, даже если это правда, то что? Во-вторых, утверждение про симультанность восприятия блок-схемы (т.е. заведомо последовательного конструкта) нуждается в доказательстве. Я вот их читаю строго последовательно.
Я повторюсь, беда в том, что вы не понимаете, что for (n = 1; n < 20; n++) y = y+n надо заменять не на красивую графику, а на y = y + sum(range(1, 20)). В вашей графике все еще есть цикл. В моем варианте осталась только чистая декларация намерения.
Идея проста и сводится к двум положениям:Начните со строгого формального доказательства того, что графические конструкции безопаснее текстовых. Пока вы этого не доказали, дальнейшие рассуждения в данном направлении не имеют смысла.
— надо выявить опасные служебные слова и знаки, используемые в операторах управления, и запретить их;
— вместо них следует использовать безопасную графику.
Картинка "как удалить оператор while", например, меня не убедила. Обе конструкции, на С и на Драконе, одинаково неприятные. Не люблю я, когда инкремент вместе с условием ;) И сложных условий не люблю. Замена ключевого слова на иконку - это всё равно что вместо while использовать пока, как в русских языках программирования. Это не короче, не понятнее, и не безопаснее. Хотя, возможно, у термина "безопаснее" есть какое то специальное значение?
Не люблю я, когда инкремент вместе с условием
+1. Я, хоть убей, не могу вспомнить, что происходит раньше - инкремент или условие.
И сложных условий не люблюВы правы, сложные условия — потенциальный источник ошибок.
Эдвард Йодан советует:
«Избегайте без нужды использования сложных булевых выражений… Даже если нет неоднозначностей, такие выражения обычно с трудом понимают все, за исключением их автора» [10]. ДРАКОН позволяет упростить сложные условия и полностью удалить логические связки из логических выражений. См. мою книгу
стр. 124-183, рис. 68-112
Часть 3. Алгоритмическая логика. Математическая логика в алгоритмах. Визуальная алгебра логики
- Глава 12. Логические операции И, ИЛИ, НЕ
- Глава 13. Логическая функция И
- Глава 14. Логическая функция ИЛИ
- Глава 15. Как удалить логические связки из логических выражений
- Глава 16. Канонические логические схемы
- Глава 17. Логическая функция «исключающее ИЛИ»
- Глава 18. Сложные логические функции
ДРАКОН позволяет упростить сложные условия и полностью удалить логические связки из логических выражений.
Вы, извините за прямоту, жульничаете. Не "удалить", а "заменить одну связку на другую". Вот уже разобрано: https://habr.com/ru/post/539786/#comment_23275912.
Кстати, "другие языки" тоже позволяют упрощать сложные условия. Для какого-нибудь C# уже давно даже есть рефакторинги в каком-нибудь ReSharper, которые это сделают за программиста по нажатию двух кнопок.
ДРАКОН позволяет упростить сложные условия и полностью удалить логические связки из логических выражений.
Любой язык позволяет переписать логическое выражение как-то иначе. При чем без использования графики это даже проще — зря ли всех сколько лет в школе учили раскрывать скобки ;) Тут вопрос в другом: если в исходном выражении допущена логическая ошибка:
— ни Дракон (раз вы ее не видите — значит, Дракон тут совсем не помощник), ни python тут не поможет. Визуальные правила Дракона позволяют только немного упорядочить лапшу из goto (которого в других языках просто нет).
Соглашусь с Вами. Хотя наверное для "продажи" своей идеи просто перебрали в формуле супер-пупер представления. Ни о какой незопасности тут не может быть и речи. Просто сегодня многие люди склонны не к текстовому программированию, а именно к визуальному. Ведь с визуальным можно и детей подключать, что и делают и LEGO, и например такая форма программирования как scetch, которую и для питона, Java и для Arduino подходит. Но раз сказавши "безопаснее", не могут согласиться с тем, что это было через-чур, поэтому и продолжают как мантру повторять это.
Безопасность приходит не от визуальности, а от функтиональных возможностях редактора, который разрешает/запрещает те или иные действия. Например между одним и другим блоком может встать только специальный блок, а не какой-нибудь. Или открыв визуально цикл, сразу в схему вставляется и конец цикла. И не может быть отдельно удалённым. Т.е. безопасность не от блоков или реализации тех или иных синтаксических конструкций азыла, а именно от того, как это всё в редакторе организовано. Но это уже другая песня.
Безопасность приходит не от визуальности, а от функтиональных возможностях редактора, который разрешает/запрещает те или иные действия.На данный момент дракон-редактор ничего не знает о языке программы и позволяет, например, нарисовать переход внутрь области видимости за точку инициализации переменной.
Безопасность приходит не от визуальности, а от функтиональных возможностях редактора, который разрешает/запрещает те или иные действия… Т.е. безопасность не от блоков или реализации тех или иных синтаксических конструкций языка, а именно от того, как это всё в редакторе организовано.В языке ДРАКОН безопасность обеспечивается комплексом мер, в частности, использованием аксиоматического метода, визуального логического исчисления (исчисления икон).
Имеются две визуальные аксиомы (аксиома-силуэт и аксиома-примитив). Из аксиом с помощью правил визуального логического вывода выводятся визуальные теоремы, каковыми являются дракон-схемы силуэт и примитив соответственно. Проще говоря, используется специальный математический аппарат для построения графики дракон-схем.
Аппарат описан здесь, стр. 306-315. Глава 32. Исчисление икон — новый метод предотвращения ошибок.
Буду благодарен за ваши критические замечания.
Проще говоря, используется специальный математический аппарат для построения графики дракон-схем.
Нигде не доказано, что этот аппарат (а) является непротиворечивым и (б) приводит к безопасности.
А еще, кстати, этот аппарат там не описан, а содержит отсылки к другой книге того же автора, которая отсутствует в свободном доступе.
И еще пара слов об "исчислении икон".
Утверждение первое: истинная, с точки зрения исчисления икон, ДРАКОН-схема не обязательно корректна с точки зрения алгоритма (иными словами, существуют такие ДРАКОН-схемы, которые истинны, но некорректны). Это и очевидно из примеров, и даже упоминается в вашей книге.
Утверждение второе: имея истинную с точки зрения исчисления икон и корректную с точки зрения алгоритма ДРАКОН-схему, можно совершить допустимои с точки зрения исчисления икон действие (т.е. схема останется истинной), которое сделает алгоритм некорректным. Это проистекает из предыдущего утверждения (доказательство нужно?).
Я надеюсь, вы не будете оспаривать эти два утверждения?
Язык ДРАКОН содержит большое число правил. К счастью, их не надо учить и запоминать. Почему? Потому что правила знает назубок, хранит в своей памяти и скрупулезно выполняет программа ДРАКОН-конструктор
заменяю слово Дракон на букву C (можно и C++, Java, C#, Assembler, Phyton, SQL...) - получаем:
Язык C содержит большое число правил. К счастью, их не надо учить и запоминать. Почему? Потому что правила знает назубок, хранит в своей памяти и скрупулезно выполняет программа C-конструктор.
И ведь тоже правда?!
Хотя и выражение автора и переделанное высказывание не имеют смысла от слова совсем. Ведь, если компилятор знает все правила использования языка, это вообще не говорит о том, что человек не должен знать эти правила. Это как с музыкой. Даже умея читать музыкальные ноты, не говоря уже о том, что просто зная, чо они есть - не создать музыкальное произведение. Для этого надо их и ноты знать, и их размерность, и знать как использовать, и где, и стили, и разновидности инструментов, иметь слух, талант итд. Инструмент болгарка тоже знает как вертеть диск вокруг оси, но этого мало, чтобы распились плитку и не отколоть края.
Вы не правы. Программа ДРАКОН-конструктор не является аналогом компилятора. Сходство в том, что ДРАКОН-конструктор содержит транслятор (конвертор) в исходный код целевого языка, например Си или JavaScript.
Отличие в том, что ДРАКОН-конструктор выполняет функции графического редактора. Но это не простой графический редактор.
Обычный редактор покорно (бездумно) проводит соединительные линии, подчиняясь воле пользователя, что может приводить к пересечениям, разрывам и внутренним соединителям.
В ДРАКОНе пользователю запрещено рисовать соединительные линии от слова совсем. Линии автоматически без пересечений и без ошибок создает ДРАКОН-конструктор. Для этого придуман институт валентных точек (точек ввода) и макроикон.
Посмотрите в статье gif-анимации на рис. 5, 6, 7.
ДРАКОН-конструктор в целях безошибочности обязан реализовать аксиоматический метод: графика дракон-алгоритма математически строго выводится из двух визуальных аксиом: аксиомы-силуэт и аксиомы-примитив методом визуального логического вывода. Использование визуального логического исчисления — это элементы искусственного интеллекта.
Главное. Если существует алгоритм предотвращения некой ошибки, такой алгоритм следует встроить в ДРАКОН-конструктор.
Есть и еще кое-что. Подобным требованиям должен удовлетворять правильно построенный ДРАКОН-конструктор.
Существующие ДРАКОН-конструкторы заданным трбованиям соответствуют не полностью.
Вы говорите, что человек должен знать правила. Вы правы, но это трудно и человеку (пользователю) надо помочь. Только об этом и идет речь.
Программа ДРАКОН-конструктор не является аналогом компилятора.
Ну да, она является IDE. Причем функционально намного более слабой IDE, чем существующие сейчас на мейнстримном рынке.
Если существует алгоритм предотвращения некой ошибки, такой алгоритм следует встроить в ДРАКОН-конструктор. Есть и еще кое-что. Подобным требованиям должен удовлетворять правильно построенный ДРАКОН-конструктор. Существующие ДРАКОН-конструкторы заданным трбованиям соответствуют не полностью.
… т.е., внезапно, "безошибочность" гарантирует не ДРАКОН, а конструктор?
Вы правы, но это трудно и человеку (пользователю) надо помочь.
Ровно для этого в современных IDE есть автодополнение, автоформатирование, подсветка синтаксиса, анализ путей выполнения и значений, и так далее, далее, далее.
анализ путей выполнения и значений
Это тот же пример, который выше, с логической ошибкой. Только здесь ReSharper (да, это не средства языка, но это доступный статический анализатор) показывает на эту ошибку (синее волнистое подчеркивание), говоря, что s не может быть больше 80 в этом пути выполнения. И да, сначала в каждом условии было n + k, они превратились в s в два нажатия кнопки.
Вот так выглядит помощь человеку.
Ну да, она является IDE.Нет, IDE для ДРАКОНа не существует, это дело будущего.
IDE текстового программирования создавались десятилетиями. Накоплен огромный опыт.
IDE визуального программирования начали создавать с огромным отставанием, намного позже. Они очень слабые. Может быть, LabView чего-то достиг.
т.е., внезапно, «безошибочность» гарантирует не ДРАКОН, а конструктор?Конечно. ДРАКОН — это книжки на полке и память человека, который их прочел (если прочел). Но память может подвести.
А конструктор — это реальность, его можно пощупать, оценить, пустить в дело, получить отзывы, доработать и т.д.
Успех ДРАКОНа целиком завивисит от успехов ДРАКОН-конструктора.
Я подробно описал ДРАКОН-конструктор, предъявил требования к нему и опубликовал их.
Разработка ДРАКОН-конструктора — не мое дело. Это дело добровольцев, которые читают мои книги и понимают их.
Кстать, я сейчас жду известий о появлении еще одного, новейшего ДРАКОН-конструктора. Двигатель прогресса и центр силы — предприниматель Алексей Муравицкий (ОКБ АМУР №3), о котором я вам говорил.
Он сам (без моего участия) составил требования к ДРАКОН-конструктору, который ему отчаянно нужен для работы.
Я уверен, что Алексей своего добьется.
Существующие ДРАКОН-конструкторы заданным трбованиям соответствуют не полностью.
А почему? Современного инструментария нет, потому что популярность языка около 0. На github, например, я не нашел ни одного проекта на Драконе.
А нулевая популярность — в том числе и потому что инструментария нет. Если бы сейчас из редакторов текста в наличии были бы только notepad да Лексикон мохнатых годов — никакого NodeJs не выехало бы.
популярность языка около 0.Вы правы, согласен с вами.
А нулевая популярность — в том числе и потому что инструментария нет.Нельзя сказать, что инструментария совсем нет. Кое-что есть.
Зайдите в Википедию статья DRAKON
В карточке языка смотрим
Website drakon-editor.sourceforge.net
Major implementations
GRAFIT-FLOKS (1996),
IS Drakon (2008),
DRAKON Editor (2011),
DrakonHub (2018),
Drakon.Tech (2019)
На github, например, я не нашел ни одного проекта на Драконе.Есть там два проекта на Drakon.
Какие инструментальные ДРАКОН-программы
имеют открытый исходный код?
Открытый исходный код имеют три программы Степана Митькина.
- Программа DRAKON Editor имеет открытый исходный код. sourceforge.net/projects/drakon-editor/files
- Исходный код DrakonHub.com выложен на GitHub. Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде DRAKON Editor. github.com/stepan-mitkin/drakonhub
- Исходный код среды разработки Drakon.Tech выложен на GitHub Drakon.Tech написан (нарисован) на языке ДРАКОН в среде DRAKON Editor
github.com/stepan-mitkin/drakon.tech
Исходный код DrakonHub.com выложен на GitHub. Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде DRAKON Editor. github.com/stepan-mitkin/drakonhub
https://github.com/stepan-mitkin/drakonhub/blob/master/app/https_sender.drn
Прекрасная иллюстрация к достоинствам графических языков.
Что-то делается — это хорошо. Но насколько я вижу, делается это одним человеком, и ооочень неспешно. В этот вагон нужно было запрыгивать в 90-х — тогда визуальное программирование зашло бы, было бы какое то community. А сейчас… где выпускник вуза сможет применить свои умения в Drakon? Нигде. Зачем тогда его учить?
где выпускник вуза сможет применить свои умения в Drakon? Нигде. Зачем тогда его учить?
- По моим данным, для программирования народ использует программу ИС Дракон Геннадия Тышова. Она имеет лучшую функциональность (но неудобный интерфейс).
- Для рисования и моделирования используют DrakonHub. Хороший интерфейс user-friendly, но без программирования.
- Программа Drakon.Tech хороша, но она умеет программировать только на JS, а народ хочет Си.
Говоря народ, я имею в виду программистов ПЛК и микроконтроллеров — это область промышленной автоматики, где ДРАКОН уже практически применяется в мелких объемах.
В подтверждение приведу ссылку, где практики резко критикуют ДРАКОН.
За что критикуют? За отсутствие графической отладки!
Это правильная критика и развитие дракон-инструментов должно идти в этом направлении тоже.
Практики советуют:
Будь симулятор и графическая отладка, Дракон можно было бы встраивать в микроконтроллер, получая полноценный ПЛК.Правильный совет.
для программирования народ использует программу ИС Дракон
Если верить статистике от GitHub - добровольно не использует никто. 1 человек неспешно пилит IDE - вот и всё. Возможно, потому что IDE за сколько лет разработки все ещё недопиленное, и Arduino IDE в области микроконтроллеров, например, рвёт его как тузик грелку ;) А мотивация тех, кто на GitHub не публикуется, мне неведома. Возможно, насяльнике сказаль сюда рисовать, а за забором очередь :D
Будь симулятор и графическая отладка, Дракон можно было бы встраивать в микроконтроллер, получая полноценный ПЛК.
Правильный совет.
Почему, несмотря на написание/чтение книг об улучшении работы ума — идеологи и создатели дуракона за 30 лет не смогли написать симулятор и графическую отладку?
Почему, в конце концов, те дураконисты, кто хочет симулятор и графическую отладку — не могут взять и написать эти «симулятор и графическую отладку»?
Может, потому, что ДУРАКОН — инструмент, созданный
не обижайте людей с ограниченными возможностями - они имеют право на свою точку зрения и свой клуб )))
Главное, чтобы они инвалидами подобными себе не делали здоровых...
Приходит председатель этого клуба в спорткомитет, и начинает рассказывать: «вот в нашем маленькой лечебнице пациенты даже до туалета дойти не могли. Но когда мы им выдали костыли — большинство пациентов смогло ходить не только в туалет, но и в столовую. Предлагаю выдать костыли нашей футбольной сборной!»
Ну, председателю клуба инвалидов объясняют: «уважаемый, те, кто не может без костылей дойти до туалета — в футболисты не берут. даже в дворовую команду!»
Но он не успокаивается: «Хорошо, давайте тогда использовать костыли в узкой нише — в плаванье, например. Чтоб не утонуть.»-«пловцы на соревнованиях не тонут»- «а мы к ним гирю привяжем!»
ну и все в таком духе…
Современного инструментария нет, потому что популярность языка около 0.Ну, во-первых, это не язык. Способ записи блок-схем, или рисовалка, или подготавливатель мест для вписывания кода на языке программирования, что угодно — но само
этоязыком не является.
Нулевая популярность — потому, что нет необходимости в использовании. Необходимости нет, т.к. как со стороны пользователей нуждающиеся в таком инструменте — это нечто вроде «пика Балмера» — тем, кто программировать (или выстраивать алгоритмы, процессы) еще не умеет — тем дуракон пока не нужен. Тем, кто умеет — уже не нужен. тем, кто учится — он, может, и полезен — но является лишним промежуточным звеном. Что-то простое проще сделать без него. что-то сложное явно проще сделать без него. Остаются люди, которые «не могут, но хотят».
Вот и получается, что это инструмент либо для гиков и извращенцев, либо для интеллектуальных инвалидов. Собственно, он и задумывался как ходунки для людей с атрофией ног, или костыли для инвалидов (ну, если хотите, как «спасательный круг для не умеющих плавать»). Только с того времени «обучение плаванью»/«обучение прямохождению» стало обязательным для каждого, претендующего на роль инженера.
Если бы сейчас из редакторов текста в наличии были бы только notepad да Лексикон мохнатых годов — никакого NodeJs не выехало бы.идея IDE очень древняя. Еще во времена Лексикона, в 91 примерно, на Корветах был сделан в качестве курсача редактор-ассемблер-эмулятор для однокристаллок. Там уже была сделано «автодополнение», проверка аргументов «на лету» (не всех, конечно), и эмуляция с просмотром состояния памяти. Навеяно было, если память не изменяет, ТурбоПаскалем (причем сначала удалось купить книжки, а потом уже увидели «живьем»). примитив, конечно — но это все-таки всего лишь студенческий курсач, причем курсач на специальности, напрямую с программированием не связаной. А кроме нас ведь уже была куча фирм, разрабатывающих софт профессионально. Так что появление IDE было ответом на требования времени. И всего лишь «делом времени».
«Визуальщина» появившаяся году в 93-м (на какой-то выставке в том году в Москве, какой-то экспоцентр рядом с ЛогоВАЗом имел довольно много стендов с аналогами дуракона) года три пыталась отвоевать место, но тихо сгинула (оставив жить по сути только нишевый МатЛаб).
идея IDE очень древняя
Конечно. Программистам нужно автоматизировать работу с кодом — пишутся IDE с подсветкой/проверкой синтаксиса/отладкой/etc. Автоматизировав работу с кодом — можно ворочать огромные проекты, в том числе и развивать новые языки.
А вот Дракона развивать не надо, он сразу вышел хорошо ;)
«Визуальщина»… тихо сгинула
Слишком много плюшек даже при минимальном обучении дает кодирование традиционными способами (клавиатура, буквы).
Кодированию блок-схемами тоже нужно учиться, да, но плюшек получается значительно меньше.
А вот Дракона развивать не надо, он сразу вышел хорошо ;)а вот этого мы не знаем. О применении Дуракона в Буране нам известно только со слов Паронджанова. (да и то: «нарисовали на бумаге, отдали программистам на кодирование»), других упоминаний я не нашел. Книгу о разработке софта Бурана он не пишет — видимо [дальше мои домыслы и инсинуации], если напишет правду, то придется признать, что к Бурану это отношение не имело. а если наврет — его натыкают носом еще живые свидетели..
Судя по исполнению, основные архитектурные решения дуракона относятся к 1990-м, когда программа Энергия/Буран была де-юре заморожена, а де-факто закрыта. И в том состоянии продолжает пребывать. Стабильность, да…
Ну и надо учитывать, что появился Дуракон из потребности облегчить решение задач на ужасном языке, для людей, не желающих ни учиться, ни делиться знаниями, в специфических советских условиях подковерной борьбы в секретных организациях. Возможно, дуракон это даже сделал. Но после того времени и языки сменились, и люди знающие появились. Осталась только «подковерная борьба». И если в «организациях» она еще «действует» ( habr.com/ru/post/539786/#comment_23272662 ), то на «открытом рынке», где заставить нельзя, и где критерий — эффективность работы, там дуракон занимает вполне закономерное место — где-то на помойке, пользуются им только интеллектуальные инвалиды и извращенцы. Имеют право.
Слишком много плюшек даже при минимальном обучении дает кодирование традиционными способами (клавиатура, буквы).язык — он более емкий инструмент. попробуйте изобразить визуально «спелую, крупную, кисло-сладкую антоновку, чуть тронутую легким октябрьским морозцем»…
Кодированию блок-схемами тоже нужно учиться, да, но плюшек получается значительно меньше.скорее, кодированию можно учиться, применяя при учебе блок-схемы. После обучения, как правило, блок-схемы для разработки становятся не нужны (ну, иногда рисуешь что подобное, но без квадратиков и ромбиков, просто линиями. и хватает). изучать же отдельные правила рисования блок-схем для того, чтоб вписывать потом в элементы блок-схем куски кода на изучаемом целевом языке, и получить в результате говнокод на целевом языке (напомню, как минимум одна поделка при генерации принципиально не может обойтись без goto) — это извращение. Это, напомню, ситуация без учета возможностей IDE. С IDE все еще хуже для дуракона — пока дураконится «каркас», куда потом надо будет вписать куски кода — на IDE все уже будет вбито, проверено и запущено в работу. В случае коллективной работы и/или сравнения/исправления всё еще хуже…
ДРАКОН не является мертвым языком. Применяется, в основном, в космической сфере. Использовался для создания ПО для ФОБОС-ГРУНТ, разгонного блока „Фрегат“, модернизации ракетоносителя „Протон-М“. Применяется в НПО им. Лавочкина для создания лунного модуля.
Ну, собственно, вот и ответ на вопросы: «кто эти люди, пишущие на Драконе, почему их нет на GitHub, и как удаётся сколько лет ездить на этой
Ну и, как тут написали в комментах, даже «эти люди» на ДУРАКОНе уже не рисуют. Они пишут нормальные программы в нормальных системах на нормальных языках. А картинки рисуют «для начальства», застрявшего где-то в районе ПРОЛ-2.
Ну и современные среды разработки прекрасно автодополняют набираемый текст, и подсказывают возможные в данном месте свойства, методы, вызовы функций… (т.е. они еще и превосходят по исполнению).
Это то, что касалось применения ДУРАКОНа для программирования.
Использование его в графическом описании процессов тоже не дает никаких явных преимуществ по сравнению с грамотной отрисовкой в других системах. Зато, например, построение параллельных процессов разными исполнителями (например, искусственное дыхание вдвоем) в BMMN гораздо понятнее и нагляднее. Т.е. и тут никакого преимущества не видно.
В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 90'х были такие case редакторы, оно они не стрельнули. Потому что ими генерированный код надо было допиливать или видоизменять. И как только один раз такое делалось, то терялась вся суть использования этого case редактора.
Графические редакторы только там нужны, где все то, что с ними создаётся и есть то что исполняется. Те. они должны представлять из себя нааамного большую абстракцию, чем простой язык программирования. Вот тут уже кем-то указаный MatLab или например редакторы обьектов, цветов и стилей в том же Photoshop. Или редакторы 3D или какой-нибудь CAD программы, или редакторы Workflow процессов. Вон например описание инфраструктуры будущей архитектуры приложений AWS использует похожий принцип, когда используемые элементы как квадратики, кружочки и линии представляют из себя целые горы строчек в настоящем языке программирования. Но они от пользователя "спрятаны". Вот тогда есть толк от такого редактора. Когда он упрощает сложность каких-либо процессов. Когда-же он просто видоизменяет, то что уже есть, но требует всё равно столько же суппорта и при этом уже является 150-м вариантом на рынке, то и успеха у такого начинания мало. Как раз сам работаю над таким framework для своей специализированной идеи. Именно для узкого коридора возможностей, где настоящее програмирование и правда есть муторное дело.
Пример — мои друзья, семейная пара, оба врачи-терапевты. Пришел к одному с сильной простудой — он прописал мне арбидол, цетрин, амоксиклав. Встретил на улице его жену — рассказал, она — «а я это обычно не прописываю, я прописываю...».
В больнице — врач хаотично применяла антибиотики, пока не догадалась сделать еще других анализов — через три недели.
Что еще я видел забавного — превышение рекомендуемой дозировки антибиотика в три раза,
общался с одним товарищем который абсолютно всё лечил методом ГБО, наблюдал
полную неспособность поставить диагноз и прописывание пустышек.
Сейчас у врачей кстати есть рекомендательная система — типа вводишь предварительный диагноз и сразу выдается рекомендация и препарат — при этом я наблюдал полное игнорирование рекомендаций системы. Ощущение, что чем меньше наши врачи будут думать тем пациентам будет лучше, потому что за врачей уже подумали научные сотрудники во всяких медицинских НИИ и разработали методики, рекомендации, и т.п…
[url=https://vk.com]сюда[/url]
Game modeled in Drakon diagrams
I use Drakon daily to work on a game mod which has complicated logic. It is a turn based game in development (but works) which is similar in some ways to chess. Therefore, it has many complicated objects, states, and mechanics to code in. Because of this, I found drakon to be very helpful in writing the game logic.
This was my first time using drakon practically and it taught me a lot. I'm currently in the process of completely rewriting it in drakon again applying what I learned the first time. The main takeaways were to keep diagrams short enough that they fit on a screen, and to abstract away as much as possible in smaller diagrams.
The code base has two .drn files, one is for the lua server side of the game logic (DrakonLua), and the other is for the javascript client side UI logic (DrakonJS), such as what happens when buttons are clicked.
Before I used drakon, I attempted to create this same game using a normal code editor Visual Studio Code, but I kept getting stuck. Drakon enabled me to get to a working alpha version with full gameplay implemented.
See below for a video of the game functionality to get some idea of what was coded. The code base was relatively small for such a mechanically rich game, coming in around 15,000 lines of code.
For me, Drakon is not a toy or experiment, it is the main tool I use to actually make progress in this game development domain.
www.youtube.com/watch?v=qNeu_0d6LRk
Я очень рад, что кому-то ДРАКОН помог преодолеть его блок.
Но.
Это все еще ничего не говорит о заявленных "безошибочности" и надежности ДРАКОНа, равно как о его читаемости, особенно в сравнении со специализированными инструментами для разработки игровых механик. А без примеров кода нельзя оценить даже сложность задачи и/или качество получившегося результата.
«создавать ПО, которое с большой вероятностью не будет содержать никаких ошибок и уязвимостей, что критично для систем управления движением».В статье Защита программного обеспечения системы управления магнитолевитационным транспортом, в частности, сказано:
«На следующем этапе проводится поиск низкоуровневых уязвимостей в полученном коде с помощью существующих методов. Для обеспечения большего процента покрытия возможно совместное использование нескольких методов. Далее выполняется алгоритмизация кода с использованием языка ДРАКОН – визуального алгоритмического языка программирования и моделирования, обеспечивающего большую наглядность [3, 7].
Правила по созданию диаграмм в языке ДРАКОН создавались с упором на требования эргономики (например, в них запрещено пересечение линий алгоритма, которое обычно осложняет его понимание пользователем), т. е. они изначально оптимизированы под восприятие алгоритмов человеком в основном при использовании компьютерной графики.
Схемы, разработанные при помощи указанного языка, просты и понятны даже человеку, далекому от программирования, что позволяет расширить круг специалистов, использующих разрабатываемую методологию. ДРАКОН делает упор на визуальную составляющую, что значительно повышает читаемость программы.
Обычно блок-схемы позволяют графически отобразить логику
программы, но при достаточно большом объеме программного кода они становятся громоздкими и теряют наглядность.
В отличие от классических блок-схем в дракон-схеме выход влево от
условия запрещен, а маршруты рисуются по принципу «чем правее, тем хуже», т. е. чем правее в алгоритме находится какой-либо блок, тем более неприятную ситуацию он описывает. Это позволяет упростить понимание готовой схемы. Кроме того, дракон-схемы охватывают большую часть популярных высокоуровневых языков программирования.
Таким образом, полученная на третьем этапе алгоритма схема позволит получить наглядное представление исследуемого ПО».
Далее выполняется алгоритмизация кода с использованием языка ДРАКОН
Весьма оригинально — сначала написать код безо всяких алгоритмов (интересно, как?), а потом его алгоритмизировать. Примерно как удаление гланд через задний проход.
Ага, сначала "производится поиск уязвимостей", а потом уже "схема позволит получить наглядное представление".
Нет в этой статье никакой методологии, сплошная вода вида "поиск низкоуровневых уязвимостей с помощью существующих методов" и "поиск уявизмостей ведется экспертом по информационной безопасности либо автоматизированно".
Но самое главное вот что:
Специалисты по безопасности ПО используют ДРАКОН в методологии, позволяющей:
Не "специалисты по безопасности", а "сотрудники университета Х", не используют, а предлагают использовать, и не позволяющей, а предположительно позволяющей. Это проект.
ну и не «используют», а «предлагают использовать».
ну и несказанно радует «Для автоматизации работ на данном этапе необходима
разработка специализированных программ, позволяющих анализировать
блок-схемы и выявлять критичные места в них.» Я даже комментировать такое не могу…
в общем, «публикация» с единственной целью «набрать количество публикаций».
на военно-техническом форуме «АРМИЯ-2021»
В рамках форума 26 августа 2021 состоялся Круглый стол:
«Актуальные вопросы развития и применения автоматизированных систем управления комплексом технических средств жизнеобеспечения объектов военной инфраструктуры»
Ссылка на Круглый стол
Цель круглого стола:
— обмен опытом и информацией о новых научно-технических разработках в области создания и развития автоматизированных систем управления, мониторинга и контроля комплексов технических средств,
— объединение ведущих научных школ,
— поиск партнёров и установление деловых контактов.
Организатор Круглого стола:
9-е Управление Министерства обороны Российской Федерации
Модератор:
начальник 43 кафедры Военно-космической академии имени А.Ф.Можайского, доктор технических наук, доцент, полковник Абсалямов Дамир Расимович.
На круглом столе представлен доклад И.Е. Ермакова и А.М. Муравицкого:
Русский визуальный язык ДРАКОН — инструмент для быстрой и надёжной разработки алгоритмов систем управленияie@iermakov.ru
a_muravitsky@okbamur3.ru
Краткое содержание доклада:
В ОКБ АМУР 3 разрабатывается широкий спектр управляющих алгоритмов для ПЛК, для разнообразных промышленных, инфраструктурных и коммунальных объектов.
По нашему опыту, все языки МЭК мало приспособлены для быстрой и надёжной разработки алгоритмов управления.
Они не отображают наглядно состояния управляющей системы, переходы между ними, различные сценарии и исходы каждого логического блока. Управление через дополнительные логические переменные ещё сильнее снижает наглядность.
Как следствие – разработка ведется «методом проб и ошибок», с последующей «агонией отладки».
Мы постоянно встречаем в открытых библиотеках на языке ST пропуски целых логических веток, игнорирование особых случаев – а ведь эти библиотеки используются на тысячах реальных объектов.
Как выход мы применили визуальный язык ДРАКОН (https://drakon.su/), который выводит на другой уровень наглядность и проверяемость алгоритмов управления, улучшает повторное использование логических блоков.
Становится возможной визуальная верификация алгоритма (это не исключает интерактивную отладку как дополняющий инструмент).
Ключевая особенность языка – двумерное структурное программирование, дающее большую свободу управляющих структур, чем классическое структурное программирование (см. И. Е. Ермаков, Н. А. Жигуненко. Двумерное структурное программирование; класс устремлённых графов. – drakon.su/_media/biblioteka_1/ermakov_zhigunenko.pdf).
ДРАКОН определяет однозначное размещение схем на плоскости, для автоматической реализации редакторами. Схема не рисуется, а быстро набирается блоками.
В продуманной до мелочей наглядности, обозримости сценариев, в расширенном структурном программировании, в строгом размещении на плоскости – отличие ДРАКОНа от всех нам известных визуальных алгоритмических схем.
Кроме того, ДРАКОН непосредственно поддерживает программирование на основе конечно-автоматной модели.
Опыт ОКБ АМУР 3 по разработке систем управления на основе ПЛК ОВЕН, с генерацией кода на ST из ДРАКОН-схем:
— насосные станции;
— станции высокого давления СОЖ;
— станции поддержания пластового давления;
— тепловые пункты и вентиляционные установки;
— водозаборно-очистительные узлы;
— туннельные водооткачивающие установки;
— сверлильные станки;
— гибочные прессы;
— координатно-режущие станки;
— пищевые производства (пивзаводы и др.);
— процессы взаимодействия ПЛК с базами данных SQL.
Мы использовали ДРАКОН-редактор предыдущего поколения (ИС ДРАКОН), который позволял чертить схемы и в полуручном режиме генерировать ST-код.
В настоящее время мы ведём разработку новой интегрированной среды программирования ПЛК на основе ДРАКОН-схем.
Её преимущества: поддержка проекта ПЛК в целом, высокопродуктивный ДРАКОН-редактор с быстрым вводом схем, поддержка сильной инкапсуляции и повторного использования блоков, экспорт проекта в формате PLCopenXML.
Результатом нашего проекта должна стать отечественная универсальная визуальная система программирования ПЛК нового поколения.
Благодарю всех, кто принял участие в обсуждении моей статьи.
Я учел ряд замечаний, переработал статью и послал ее в медицинский журнал «Виртуальные технологии в медицине». Переработанная статья называется:
Медицинский алгоритмический язык ДРАКОН и программа ДРАКОН-конструктор для создания и применения клинических алгоритмов«Виртуальные технологии в медицине» — это рецензируемый журнал, в котором используется двойное слепое рецензирование.
Рукопись статьи можно прочитать здесь.
Публикации
Медицинский алгоритмический язык ДРАКОН против пандемии и не только. Статья для профессиональных врачей