Comments 155
Удивительное рядом, но похоже что взлетают языки с очень компактным базовым синтаксисом и документацией, написанной на английском так, чтобы автоматические переводчики не шибко врали при переводе на другие языки.
Плюс стало понятно, что для разработки надежных больших систем куда важнее даже не сам язык как таковой, а культура вокруг — количество кода на функцию, покрытие тестами, скорость получения ответа на тупой вопрос «проходят ли все тесты», сложность графа зависимостей компонентов. А для поддержания визуальной читаемости на должном уровне линтеры и считалки цикломатической сложности — прямо песня. Когда пытаешься запилить функцию в 300 строк а оно тебе (само, железко) — «чувак, тут слишком много кода в одной функции, распилил бы ты ее...» или «ой, чой-то ты вот это ветвление тестом не покрыл» — это прям радость, правда.
Он используется при выпуске документации прежде всего. Речь идет о схемах алгоритмов. Этот стандарт задает графику схем алгоитмов. Но не коды. Коды здесь вообще ни при чем.
Вы, по-видимому, не используете стандарт ГОСТ 19.701—90.
Но другие разработчики вынуждены им пользоваться.
К сожалению, ваш комментарий не относится к теме статьи.
Документация — она же вроде всегда должна писаться для чтения людьми, правда? Люди, занимающиеся реализацией, способны читать хорошо написанный код, это не сложнее чем визуальная схема алгоритма. Тогда схема не нужна. Ненужное нужно выкинуть.
Если документация пишется для чтения людьми на более высоком уровне иерархии — то на кой черт им детали реализации? Им нужен результат — что на входе, что на выходе, какая должна случиться польза. Ну, может, сколько это все будет стоить времени/денег/каких-нибудь ресурсов. И с какой вероятностью сломается. Для описания этих вещей никакой дракон не нужен, это описывается простым человеческим языком — русским, английским, суахили — каким нужно.
Прежде всего это учит логическому мышлению.
Блок-схемы когда-то учили в школе на информатике, сейчас этого нет.
А стандарт существует и будет существовать, даже если он устарел.
Так вот когда сталкиваешься со стандартами для документации, то получается что-то очень сложное и непонятное и не удобное.
В общем, это попытка улучшить документацию, и в серьезных разработках без нее никуда. Это все равно, что собирать плату сразу без схемы.
Scrach прекрасен, но он не подходит для документирования и цели его другие.
В общем, это попытка сделать удобной и полезной документацию, на которую плюются из-за ГОСТа.
У каждого стандарта и документации есть своя область применения.
Конечно нет смысла рисовать блок-схему на очередной сайт, но для построения более-менее промышленного сложного устройства придется.
Обратите внимание — весь мир живет без ГОСТ-а (в буквальном понимании) и отлично себя чувствует, хотя это не значит что в широком смысле нет аналогичных/близких систем визуализации — они есть, и таки да, помогают логическому мышлению.
Другой разговор, что 25 лет попыток насаждения авторского видения более широкому сообществу выглядят, мягко говоря, странно.
Может, стоит сосредоточить усилия на отказе от ГОСТ 19.701-90 и закопать уже стюардессу?
Тут дело имхо в другом. В том, что проектировать все равно приходится, а существующие инструменты по-прежнему неидеальны, хоть и стали лучше, чем 35 лет назад. За последние 2 месяца я отсобеседовал не меньше десятка корпоративных архитекторов, и к моему удивлению, каждый из них признавался, что разочарован в существующих нотациях, а в идеале хотел бы работать без строгого соответствия архитектурным языкам и фреймворкам.
Их можно понять. Любой более-менее опытный проектировщик (будь то архитектор решений, бизнес- или системный аналитик) неминуемо сталкивался с родовой травмой всех формальных нотаций. Начиная с определенного уровня сложности, бизнес-процессы уже невозможно описать так, чтобы одновременно было:
- читаемо
- подробно
- достоверно
Пару-тройку лет назад я открыл для себя нотацию Archimate, которую использую до сих пор в качестве базового инструмента проектирования. В моем случае, основная ее ценность — помогать мне стряпать старые добрые UML-диаграммы проще и читаемее, чем без нее. Но серебряных пуль не бывает, и у моей любимой Archimate тоже есть много бесящих повседневных моментов.
Как я понял, Parondzhanov очередной раз выносит на суд публики свою старую разработку, у которой одна из ценностей тоже заключается в том, чтобы сделать диаграммы более читаемыми, чем раньше.
Вряд ли я когда-нибудь сойду с ума настолько, чтобы всерьез использовать этот дракон как low coding platform, помогающую доменному эксперту писать код на Java/Scala/Coq/etc. Но сегодня утром открыл эту статью, посмеялся над «принципом шампура», дал почитать нескольким знакомым аналитикам и получив от них позитивную обратную связь, решил попробовать эти самые шампуры в своей рутине. Мне как раз нужно подготовить очередной ненужный занудный архитектурный документ (из тех, что никто не читает), в котором 5-6 иллюстраций с вырвиглазными BPMN и UML. Почти уверен, что внедрение принципа шампура сделает эти иллюстрации если не читаемее, то по крайней мере, компактнее. А это значит, Parondzhanov не зря затеял эту свою статью.
P.S. Владимир Данилович, а есть ли возможность фигуры из вашей нотации (те, что на иллюстрациях) выложить в любом векторном формате, а еще лучше — в виде библиотеки для Figma, по аналогии с ArchiMate_Shapes.fig? Так будет проще подсадить на вашу нотацию некоторых молодых специалистов. Тем более, что drakonhub.com стилизует фигуры явно по-другому, не столь этетично, как в этой статье.
Владимир Данилович, а есть ли возможность фигуры из вашей нотации (те, что на иллюстрациях) выложить в любом векторном формате, а еще лучше — в виде библиотеки для ......................Вся информация в моих книгах и статьях полностью открыта. Вы можете использовать ее по своему усмотрению полностью или частично.
Но. Фигуры — только часть дела. Чрезвычайно важно, чтобы были правильные связи между иконами, то есть соединительные линии, причем без пересечений и внутренних соединителей.
В ДРАКОНе связи строго формализованы с помощью визуального аксиоматического метода (метод визуального логического исчисления). Благодаря логико-математической формализации достигается защита от многих (но не всех) ошибок. Защита от ошибок — важная часть идеологии ДРАКОНа.
Используя только фигуры и отбрасывая защищенные связи между фигурами, вы выбрасываете автоматическую защиту от ошибок, которую реализует правильно построенный ДРАКОН-конструктор.
Отзыв индивидуального предпринимателя Сергея Ефанова о языке ДРАКОН
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»! we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html
чур-меня
Это всего лишь ваша субъективная проф деформация. Носителям английского языка как то не мешает синтаксис на их родном языке))
Да, люди выполняют алгоритмы, но если для объяснения алгоритма действий человеку приходится вводить новый язык со сложными конструкциями — неплохо строить такой язык в рамках конкретной культуры на основе обратной связи от тех, кто этот язык будет читать, а не пытаться насадить мастерским произволом как универсальный ГОСТ. Я вполне допускаю, что в какой-то индустрии и наборе организаций это чудо прижилось, но попытка безапелляционного обобщения на всех читателей выглядит глупо. С другой стороны — UML вот тоже пытались продать как универсальную штуку для всего, теперь потихоньку хоронят (https://simpleprogrammer.com/unified-modeling-language-age-of-agile/) :)
На основании анализа алгоритмов на Рис. 1—10 можно составить перечень эргономических ошибок, которые мы выявили:
"Ошибки" могут быть тогда, когда есть правила. Правила вы вводите самостоятельно (например, "должен быть шампур") и так, как вам удобно.
Ваши выводы не являются объективными.
Например, «неправильная» блок-схема в разделе «Разрыв шампура — серьезная ошибка» практически соответствует парадигме структурного программирования (надо только чуть подправить входящие и исходящие стрелки возле точки G и можно будет при помощи пунктирных прямоугольников окаймлять вложенные структуры).
А вот какой парадигме соответствует «правильная» блок схема — не понятно. Во всяком случае — не структурному программированию. Попробуйте выделить визуально в ней вложенные структуры — это будет сложнее сделать.
Поэтому, для дальнейшего кодинга с использованием структурно-ориентированного ЯВУ данный подход будет скорее вредным, чем полезным.
Да, в качестве сферического ДРАКОНА в вакууме причесанные блок-схемы смотрится вполне нормально и даже понятнее. Но при спуске в нижние слои атмосферы обнаруживаются вот такие неприятности.
Речь шла только о том, что полезность данного подхода не является абсолютом, но сильно зависит от парадигмы программирования, с уклоном на которую создается блок-схема.
я ни слова не сказал ни в адрес ГОСТа, ни о том, что его следует отменить.Я вовсе не предлагаю отменить ГОСТ19.701-90.
Я предлагаю:
— сохранить ГОСТ19.701-90 почти полностью;
— убрать из ГОСТ19.701-90 упоминание об алгоритмах;
— создать новый ГОСТ для алгоритмов на основе языка ДРАКОН
Речь шла только о том, что полезность данного подхода не является абсолютом, но сильно зависит от парадигмы программирования, с уклоном на которую создается блок-схема.Мой ответ состоит из двух пунктов:
1. Хотите, чтобы стандарт сильно зависел от парадигмы программирования? Оченьь хорошо. Пользуйтесь ГОСТ19.701-90. Вы получите блок-схему программы (но не алгоритм).
2. Предлагаемый мною ГОСТ на алгоритмы на основе языка ДРАКОН позволяет создать дракон-схему (блок-схему алгоритма), которая никак не зависит от парадигмы программирования.
Надо развести два понятия: алгоритм и программа. В этом я согласен с академиком Академии наук СССР, основателем Вычислительного центра АН СССР (ВЦ РАН) А.А. Дородницыным.
В чем выигрыш?
Выигрыш, в частности, в том, что мы выходим далеко за рамки программирования и охватываем не только потоки управления, но и алгоритмы действий врача (клинические алгоритмы), биологические процессы, потоки работ (workflows), модели бизнес-процессов и т. д.
Продолжение ответа
ТЕЗИС АКАДЕМИКА ДОРОДНИЦЫНА
Академик А. А. Дородницын четко проводит границу между алгоритмом и программой, подчеркивая, что «без алгоритмов предмета информатики не существует» [94]. Более того, он предлагает выделить «алгоритмические средства» как отдельную, самостоятельную сущность:
«…состав информатики — это три неразрывно и существенно связанные части: технические средства, программные средства и алгоритмические средства. Если о первых двух частях никогда не забывают — … они получили специальные термины «hardware» и «software», — то алгоритмическая часть информатики остается почему-то в тени… об этой важнейшей части информатики просто забывают» [94].Таким образом, согласно Дородницыну, алгоритмические средства должны составлять третью, самоценную часть информатики, наряду с программными средствами (software) и техническими средствами (hardware) [94].
Чтобы в полной мере реализовать идею Дородницына, нужно иметь отдельный стандарт, посвященный алгоритмам.
Я могу ошибаться, но, на мой взгляд, популяризации ДРАКОНа препятствовали две вещи.
Во-первых, завышенные амбиции на старте: позиционирование его не как усовершенствованной инкарнации блок-схем (и, возможно, нотаций бизнес-процессов), а как универсального языка, призванного изменить парадигму разработки программного кода, а впридачу научить мыслить.
Во-вторых (по порядку, но не по значимости), безапелляционный стиль подачи материала: отношение к ДРАКОНу не как к удачному, но одному из имеющих право на существование подходов, со своими преимуществами и недостатками, не как к первому среди равных, а как к единственно верному, лишенному недостатков в принципе.
Ну и коварный удар в спину нанёс UML.
Насчёт "научить мыслить" частично верно, потому что одна из идей в ДРАКОНе - привести сложный алгоритм к тривиальной state-machine, что сильно упрощает его, алгоритма, понимание.
Другое дело, что не каждый алгоритм имеет смысл приводить к этому виду, и не каждый вообще стоит описывать в виде блок-схемы.
У ДРАКОНа есть своя ниша - встроенное ПО, которое по требованию заказчика необходимо полностью документировать. Вот там он и конкурирует с ГОСТ 19.
Я вот сам так и не смог наладить использование Дракона в повседневной работе. Но сумел подсадить на него коллегу, неоднократно получал благодарности - тот не нарадуется, благодаря Дракону получается писать тесты на более высоком уровне не опускаясь до частностей. Это дает возможность легко модифицировать и проще разбираться в подзабытом коде. Не раз предлагал ему написать статью на эту тему, но так и не удалось уговорить.
...а как ваш коллега модифицирует код с помощью Дракона?
Он описывает алгоритм на Драконе, а затем из дракон-схемы автоматически синтезирует текст исходного кода теста на Tcl или что-то еще. Соответственно подправляя схему он получает новый код.
А откуда берется соответствие между схемой и кодом?
В редактор дракон-схем встроен конвертер в различные языки программирования. Плюс к этому, насколько я знаю, можно самому определить код который будет соответствоать "иконам" и к тому же есть икона в которую можно просто написать кусок кода и конвертер поместит его в сооответсвующее место синтезированного кода.
И что же отвечает за согласованность кода между разными "иконами"? Скажем, банальное именование переменных?
Не могу сказать. Я практически не применяю Дракон. Я только хотел сказать, что мой коллега сумел получить от этой технологии практически полезный выхлоп.
Проблема утверждения "мой коллега сумел получить от этой технологии практически полезный выхлоп" в том, что я каждый день получаю практически полезный выход от обычного написания кода буковками.
В этот момент возникает, собственно, вопрос: а как же померять, эффективность какого подхода выше? (а в команде?)
Мой коллега тоже писал буковки и получал результат, теперь он его получает с меньшими усилиями и обнаруживает неточности в им же написанных и отлаженных в "до драконовскую" эру тестах аппаратуры. Измерение эффективности опять же зависит от того, какие критерии вы сочтете важными. У меня нет готовых ответов по работе в команде.
Мой коллега тоже писал буковки и получал результат, теперь он его получает с меньшими усилиями
Я очень рад за вашего коллегу, но на общий опыт это высказывание непереносимо, поскольку невозможно определить, являются ли "меньшие усилия" следствием введения ДРАКОНа, или каких-то других причин, включая, гм, повышение квалификации вашего коллеги.
А кто бреет брадобрея, точнее, кто проверяет поавильность синтеза ТCL? Или «это другое»?
Почему, вообще, TCL, кстати, какая-то странная привязанность у «советских» программистов к нему. Почему не Perl/Python/Clojure?
В данном конкретном случае tcl это язык скриптов для Cadance Orcard, разработчики FPGA-проектов также до сих пор его используют. А так нет принципиальных препятствий использовать другие языки как выходные для синтезатора.
Прошу прощения, опечатался Cadance Orcad.
Cadence
дал же бог имечко продукту)
Итальянское cadenza (происходящее от латинского cadentia — падение) в русском превратилось одновременно и в «каденция» (при прямом заимствовании) и в «каданс» (пройдя через французский) — причём, для обозначения одного и того же. В наше время просочилась и форма "каденс".
Отличная иллюстрация для статьи. Бабы же такие тупые, действительно было уместно взять карикатурный образ.
У вас есть примеры дракон схемы для каких-нибудь базовых алгоритмов программирования, например, сортировки или графов?
Посмотрите английскую Википедию статья DRAKON.
— Dijkstra search algorithm in DRAKON
— Outer part of quicksort algorithm in DRAKON-C
У вас есть примеры дракон схемы для каких-нибудь базовых алгоритмов программирования, например, сортировки или графов?
Посмотрите английскую Википедию статья DRAKON.
— Dijkstra search algorithm in DRAKON
— Outer part of quicksort algorithm in DRAKON-C
Outer part of quicksort algorithm in DRAKON-C
Дадада.
Эта "визуализация" квиксорта даже не способна явным образом показать рекурсию.
Аналогичное веселье и с переменными - попробуйте найти, где присваивается значение storeIndex, используемое в рекурсии.
В вашей статье прямым текстом говорится, что разрыв «шампура» — серьезная ошибка, полное отсутствие «шампура» — еще более серьезная, однако если нельзя, но очень хочется, то немножечко можно. Так? M'kay.
Я вам могу еще одну интересную вещь рассказать. В статье написано:
Все вертикали (маршруты алгоритма) упорядочены слева направо по принципу "чем правее, тем хуже".
...так вот, это тоже "если хочется, то можно не так". Скажем, если у вас идет обработка трех равноправных сценариев (на вход алгоритма приходит три вида документов), то их расположение слева направо - произвольно.
(это не я придумал, это из предыдущих обсуждений).
если нельзя, но очень хочется, то немножечко можно. Так?
Нет, не так.
Совсем не так.
Вы видите дракон-схему Силуэт. Это основная и наиболее мощная конструкция языка ДРАКОН.
Силуэт состоит из веток. Ветка — зрительно-смысловая часть алгоритма. Порядок выполнения веток указан в иконах Адрес.
На чертеже вы видите силуэт из пяти веток.
Каждая ветка имеет свой шампур.
На данном чертеже Вы видите пять шампуров.
Я рекомендую рисовать шампуры жирной линией.
Но автор этого ДРАКОН-конструктора не выполнил эту рекомендацию. И нарисовал шамруры обычной линией (а не жирной).
Все пять шампуров на этом чертеже нарисованы правильно.
Надо лишь сделать их жирными.
Это правило шампура напоминает правило старинного бейсика - нумеровать строки через 10. В конце 20 века на нумерацию строк уже забили, ибо текстовые редакторы научились управлять строками кода без явной нумерации.
Блок-схема - это же направленный граф? Ну так есть 100500 (О(n!)) способов автоматически нарисовать его на плоскости, и можно автоматически выбрать несколько, удовлетворяющих придуманным граничным условиям (минимальное количество пересечений, минимальная длина связей, оптимальное размещение на формате А0, выделение основных и воспомогательных шампуров..).
Это правило шампура напоминает правило старинного бейсика — нумеровать строки через 10. В конце 20 века на нумерацию строк уже забили, ибо текстовые редакторы научились управлять строками кода без явной нумерации.Вы правы, текстовые редакторы научились управлять строками кода без явной нумерации.
Но к языку ДРАКОН это не имеет ни малейшего отношения.
Дракон-схему рисуют с помощью специальных инструментальных программ ДРАКОН-редактор.
Сейчас существуют три ДРАКОН-редактора.
Попробуйте их. Ни один ДРАКОН-редактор не позволит вам нарисовать схему с пересечениями.
ДРАКОН-редакторы реализуют визуальное логическое исчисление (исчисление икон). Любая дракон-схема выводится из визуальной аксиомы методом визуального логического вывода. Это специальный математический аппарат (визуальная математическая логика).
ДРАКОН-редакторы реализуют визуальное логическое исчисление (исчисление икон). Любая дракон-схема выводится из визуальной аксиомы методом визуального логического вывода. Это специальный математический аппарат (визуальная математическая логика).
Сорри, не могу не вспомнить сепульки, сепуление и сепулятор :) Загуглил эти термины - они встречаются только в трудах одного автора.
Дракон идеален в связке с ассемблером. В языках высокого уровня уже слишком много наворотов, чтобы на основе дракона строить оптимальный алгоритм. Или нужно писать под каждый язык эвристический линковщик-компилятор для сборки программ по правилам дракона, но по синтаксису языка.
И вишенка на торте - различные опции компиляции, скажем в плюсах, по скорости, по размеру, с отладкой... Как тебе такое, дракон?
Столкнулся с некоторыми затруднениями, некоторые из которых разрешить было тривиально:
— Diff, merge и в целом просмотр истории изменений — как и для любого ориентированного графа эти проблемы относительно легко решаются (при определённых усилиях можно даже полностью снять с программиста задачу по разрешению конфликтов, но, разумеется, никакой git тут неприменим и понадобится CVS, основанная на других принципах).
— Try-catch — это тоже можно решить, хотя уже с изменением стандарта языка (нужно модифицировать икону ветки, чтобы она могла допускать ветвление при ошибке внутри ветки и переходить к веткам catch и finally).
Однако, есть концептуальные сложности — ориентированность Дракона на процедурное и автоматное программирование приводит к очень громоздкому графу выполнения, когда мы встречаемся с задачей описания асинхронных потоков данных, на которых построены веб-приложения. Дракон не умеет передавать функции как данные, поэтому в своей студии мне пришлось сделать гибридный визуальный язык — для «атомов», то есть элементарных функций используется Дракон, а вот для передачи сообщений/функций используется нодовый редактор — примерно такой-же, как Blueprints в Unreal Engine. А такая структура уже не так эргономична, как чистый Дракон.
Я думаю, что Дракон имеет в себе потенциал стать языком разработки, который сможет сделать программирование доступным для большинства людей, но для этого стандарт нужно серьёзно дополнить и переработать
Если говорить об описании асинхронных потоков данных в Драконе, возможно было бы использовать методологию библиотеки SystemC.
Я в качестве эксперимента делаю что-то вроде визуальной фронтенд-студии и попробовал реализовать дракон в качестве основного языка визуального программирования (не гибридный ДРАКОН-JavaScript, а чистый Дракон со специальным движком обработки данных, похожим на смесь Excel и Smalltalk).
Я приветствую вашу инициативу и ваш эксперимент. И желаю вам успехов.
Ваш текст я выложил на форуме языка ДРАКОН здесь.
Приглашаю вас принять участие в работе форума и рассказать о ходе вашей интересной разработки.
Посмотрите тему
Java try/catch/finally в языке ДРАКОН
Схема на рис. 3 имеет много изъянов:
— слева от иконы Ж есть пересечение линий (в дракон-схеме пересечения запрещены);
Меня вот это удивило, и никто не пишет. Математически доказано, что этому языку это не нужно? Потому что в общем случае это ограничение, так как можно придумать такой алгоритм, где пересечения будут (топологически проекция некого 3д графа в 2д).
Математически доказано, что этому языку это не нужно?
Нет, зачем вам какие-то доказательства? Просто верьте автору статьи на слово, что его эргономические правила - правильные.
Не знаете о теореме Бёма-Якопини?
Загуглил. Заодно вспомнил, что, оказывается, я пишу комментарии прозой! :D
Как из этой теоремы следует наличие или отсутствие пересечений на схеме - не понял.
Я думаю, что пересечение в блок-схеме аналогично goto в программе (на языке, где этот оператор есть, естественно).
Гм, это же совершено не обязательно. Повторю уже приводившуюся здесь схему quicksort:
В ней в двух местах есть вызовы операции Compare, и в трех - операции Swap. Попробуйте провести от них линии к месту описания этих операций (которое находится за пределами картинки), ничего не пересекая.
Вот еще любопытный пример (из статьи):
Предположим, "главный путь" - это АБВГЕЖИДК (т.е. пусть, при котором мы от Г переходим к Д - это ошибочный путь). Как это нарисовать, выполняя одновременно правило "нет пересечений" и правило "чем правее, тем хуже"?
То есть, преобразовать эту схему в структурную программу напрямую не получится.
Но при этом справа - корректная ДРАКОН-схема.
то, что сейчас нарисовано справа, не сделать без goto, так как из Б есть переход, ведущий внутрь ветки ГЕЖИ.
То есть, преобразовать эту схему в структурную программу напрямую не получится.
Структурное программирование создано для текстового (textual) одномерного программирования.
Язык ДРАКОН подчиняется правилам визуального (visual) двумерного структурного программирования см здесь
насчет goto
goto опасен, когда его пишут руками.
goto не опасен, когда он формируется автоматически (как и jump).
В дракон-схемах нет goto. В ДРАКОНе никто не пишет goto руками.
Он (goto) появляется автоматически при конвертации дракон-схемы в исходный код выбранного целевого языка. Но на этот исходный код не надо смотреть, как мы не смотрим на машинный код после компиляции.
P.S. А goto опасен хоть написанный руками, хоть сгенерированный автоматически, если он ведёт туда, куда нельзя.
Итого: любой алгоритм, описанный на Драконе, может быть преобразован в программу на другом языке. Обратное, в общем случае, не верно.
goto опасен хоть написанный руками, хоть сгенерированный автоматически, если он ведёт туда, куда нельзя.
Если сгенерированный автоматически goto или jmp ведёт туда, куда нельзя, значит компилятор (транслятор, конвертер) содержит ошибку; его надо доработать. Только и всего.
То есть ошибки пользователя вы полностью исключаете?
Вот отзывы из сети:
«Язык Дракон — это способ визуального описания алгоритмов, исключающий ошибки» (vtral).
«Я на ДРАКОНе работаю уже шесть лет. Любое создание программы начинаю с него и при отладке работаю только с ним. Скорость разработки, качество возрастает в разы! ДРАКОН — это сила, но многие не догоняют, думают, что это обычная блок-схема» (Ро-
ман Озеров).
Одна из целей ДРАКОНа — сократить число ошибок. ДРАКОН устраняет не все
Это означает, что "опасные" goto все еще остаются. О чем, собственно, и сказали.
«Язык Дракон — это способ визуального описания алгоритмов, исключающий ошибки»
Это утверждение доказуемо ложно.
Возьмем уже приводившуюся схему quick sort, и напишем в рекурсивном вызове вместо `QuickSort(collection, begin, storeIndex, compare)` - `QuickSort(collection, begin, end, compare)`. Получим бесконечный цикл, т.е. ошибку.
Скорость разработки, качество возрастает в разы!
По сравнению с чем? И на каких задачах? Почему ядро Linux до сих пор на ужасном С? Почему его до сих пор никто не переписал перерисовал за выходные на благодатный Дракон? ;)
ДРАКОН устраняет не все, но многие ошибки.И позволяет добавить другие ошибки.
Вот вам пример. Из A попасть между C и D можно только через goto, сгенерированный автоматически. И это приведёт к ошибке использования неинициализированной переменной.
Спасибо за еще одно опровержение к "Язык Дракон — это способ визуального описания алгоритмов, исключающий ошибки".
И позволяет добавить другие ошибки.
Я согласен с вами. Язык ДРАКОН не позволяет исключить все ошибки.
Статистика на этот счет отсутствует.
Дело осложняется тем, что ДРАКОН мало кому известен и занимает ничтожную (почти нулевую) долю рынка.
Как же в таком случае можно оценить реальное положение вещей (feedback)?
Приходится полагаться на три источника:
— специалисты, которые реально используют ДРАКОН и которых я знаю и которым доверяю (их немного);
— сообщения в сети интернет об использовании языка ДРАКОН;
— отзывы в печати.
Я процитировал два отзыва из сети.
Слова Романа Озерова вызвали здесь сомнения. Я не знаком с Романом и не знаю подробностей (кроме того текста, что я процитировал).
Приведу слова Сергея Ефанова, которого хорошо знаю:
Использую ДРАКОН уже десять лет (с 2010 года) при программировании микроконтроллеров: PIC (Microchip), MSP430 (Texas Instruments), STM32 (STMicroelectronics).
За это время с помощью программы ИС Дракон я сделал несколько десятков проектов: торговые автоматы, блоки защиты электродвигателей, GPS-трекеры, GSM-устройства и др.
Когда пришлось столкнуться с незнакомой ранее темой торговли, управления контрольно-кассовыми машинами — ДРАКОН просто спас. Без него я бы, наверное, не смог быстро привести сеть торговых автоматов в соответствие с новым федеральным законом «54-Ф3».
Прекращать, или сокращать каким-либо образом применение ДРАКОНа не планирую.
Зато прописанный руками goto ведёт только туда, куда можно ;). Если компилятор допускает переход внутрь функции (со сломом стека, ага) - значит, в компиляторе ошибка.
Не так чтобы я без goto сильно был опечален (когда последний раз использовал не помню), но это проблема того же уровня, что наличие пересечений на блок схеме. Это относится больше к стилю оформления, чем к смыслу алгоритма. В визуальных языках больше внимания уделяется стилю - ну ок, я художник и я так вижу :)
goto опасен, когда его пишут руками.
goto не опасен, когда он формируется автоматически (как и jump).
Оба этих утверждения нуждаются в формальном доказательстве.
Как это нарисовать, выполняя одновременно правило «нет пересечений» и правило «чем правее, тем хуже»?
Если в дракон-схеме Примитив нельзя сделать без пересечений, надо использовать дракон-схему Силуэт.
Силуэт позволяет убрать любые пересечения.
Алгоритмическая макроконструкция Силуэт не имеет аналогов в других языках.
Покажите на конкретном приведенном примере.
Алгоритмическая макроконструкция Силуэт не имеет аналогов в других языках.Имеет. Это простейший детерминированный конечный автомат (state machine), реализуемый практически на любом языке.
Вы правы. Это действительно конечный автомат, который можно реализовать практически на любом языке.
Но. В языке ДРАКОН это единая алгоритмическая макроконструкция, а этого нет ни в одном визуальном языке (и в текстовых тоже).
Добавлю. В ДРАКОН-конструкторе ИС Дракон Геннадия Тышова предусмотрены три режима работы с силуэтом.
— Процедурный
— Автомат 1
— Автомат 2
Два последних — это режимы автоматного программирования
В языке ДРАКОН это единая алгоритмическая макроконструкция, а этого нет ни в одном визуальном языке (и в текстовых тоже).
Угу, потому что в текстовых языках вообще нет понятия "алгоритмическая макроконструкция" (ну или я никогда не видел).
А вот способов удобно выражать конечные автоматы в языках предостаточно.
В языке ДРАКОН это единая алгоритмическая макроконструкция, а этого нет ни в одном визуальном языке (и в текстовых тоже).Этого нет в текстовых языках потому, что там нет никакой необходимости выделять ДКА как отдельную конструкцию. Уже показанная здесь схема quicksort спокойно реализуется без конечного автомата. Вы же вынуждены его использовать из-за невозможности нормально уложить визуальную схему на страницу.
В настоящей работе иногда приходится рисовать блок-схемы, и я всегда придерживаюсь Дракон-правил: сверху вниз, слева направо, запрет пересечений, главное по центру, второстепенное — сбоку. Редактор при этом не важен, в любой среде придерживаюсь этих правил.
Редактор при этом не важен, в любой среде придерживаюсь этих правил.В ДРАКОН-технологии не так. Редактор (точнее ДРАКОН-конструктор) чрезвычайно важен, без него нельзя.
Инструментальная программа ДРАКОН-конструктор содержит специальный математический аппарат, который:
— автоматически рисует соединительные линии между иконами без пересечений, без разрывов и внутренних соединителей;
— сокращает число ошибок.
Похоже, что вы соблюдаете правила ДРАКОНа вручную, это не есть хорошо.
Если хотите попробовать, возьмите программу ИС Дракон Геннадия Тышова
Во всех блок-схемах, представленных в статье предполагается единственный исход, тогда как в работе зачастую исходов может быть несколько (например рабочее выполнение и прерывание работы с ошибкой). Как тогда быть с правилом «шампура»? Или последняя ячейка это условный end и все мои альтернативные случаи ошибок будут огромной пачкой стрелок забивать подходы к этой последней ячейке?
Для решения задачи на дракон-схеме добавляются икона Полка, икона Адрес «Завершение» и икона имя ветки «Завершение».
Оператор Полка обеспечивает:
• прекращение работы данного алгоритма;
• немедленный выход из алгоритма…
При этом надо четко различать:
• фактическую работу алгоритма;
• эргономичное изображение дракон-схемы.
Фактически Полка с надписью «Выход» играет роль конца работы.
Иными словами, маршрут, доходя до полки, ОБРЫВАЕТСЯ.
Происходит выход из алгоритма, но не через икону Конец, а через икону Полка. Полка играет роль конца.
Но с эргономической точки зрения, такие «обрывы» зрительно (только зрительно, не более того) нежелательны.
Нежелательны потому, что у дракон-схемы будет нарисован не один конец, а несколько.
Фактически алгоритм может иметь несколько концов. Неприятность
в том, что глядя на схему, человеку трудно зрительно воспринимать алгоритм, имеющий несколько концов. Такой алгоритм похож на елку, увешанную «концами», как елочными игрушками.
Подобная зрительная сцена распыляет внимание и мешает сосредоточиться на главном.
Поэтому, с эргономической точки зрения, желательно создать видимость того, что у схемы всего один конец. Это нетрудно сделать. Бегунок, двигаясь к концу алгоритма, пробегает через иконы:
• икона Полка с надписью «Выход»;
• икона Адрес «Завершение»;
• икона имя ветки «Завершение»;
• икона Конец.
Возможно, читатель возразит. Дескать, такая схема не отвечает фактическому положению дел и дезориентирует.
С этим возражением нельзя согласиться. На дракон-схеме показано
все, что нужно, для исчерпывающего понимания алгоритма.
Кроме того, соблюдается эргономическое правило: Дракон-схема имеет только один конец.
То есть в угоду Вашей парадигме Вы намеренно делаете иллюзию, что в алгоритме один выход, даже если у него их несколько (даже если они условно равноценны) и оставляете пользователя в поиске оставшегося?
Не очень мне понятен подобный подход, однако я не специалист и критиковать не разбираясь в алгоритмах смысла не вижу. Спасибо за Ваши разъяснения.
оставляете пользователя в поиске оставшегося
Это не так. Наоборот, ДРАКОН устраняет путаницу и облегчает понимание алгоритма. Для этого он и создан.
Особенно большую пользу ДРАКОН приносит непрограммистам, программистам-любителям, начинающим программистам.
Посмотрите статью Сергея Ефанова. Возможно, она внесет ясность.
а откуда обязательное правило шампура?
Автор статьи его придумал, и утверждает, что так правильно.
Добавлю свои 5 копеек.
Я - препод программистов. Учу уже порядка 30 лет.
После принятия ЕГЭ довольно часто приходится объяснять алгоритмы "на пальцах".
Выяснилось, что большинство пацанов предпочитают алгоритмы в виде текста.
Но есть те, которым понятнее в виде схемы. И девочки все поголовно такие. Они текст воспринимают хуже, чем схему. В этом плане ДРАКОН - прекрасное средство начального обучения алгоритмике.
Во-вторых, мы столкнулись с тем, что есть куча людей, которые не являются программистами (технологи всякие), но которым нужно по роду своей работы создавать алгоритмы в какой-нить системе управления на микропроцессорах.
Я лично разговаривал с таким человеком, который мне сказал так: схему я понимаю прекрасно, а вот код писать мне трудно, я там много ошибок сделаю. Которых на схеме - не сделаю.
И хотел, чтобы была такая среда, где бы он мог на Драконе сохдать схему алгоритма, и которая потом преобразовалась бы в код программы.
И мы у себя на кафедре пару студентов загрузили. Один писал и, надеюсь, в магистратуре допишет и внедрит, Drakon IDE для обучения. Там сделано преобразование дракон-схемы в код на JS.
А второй студент пилит IDE для технологов - и там прямой интерпретатор схемы реализован.
Проблема автоматизации во всех этих графических языках одна: человек любую схему РИСУЕТ. Стирает те куски, которые хочет исправить, и опять рисует.
Нужен инструмент типа карандаша, с помощью которого можно было бы рисовать прямо на экране как на бумаге. А окончательный вариант уже делать чертежом автоматически.
Пока такого прбора нет - для большинства людей (программистов) текст писать гораздо проще.
И девочки все поголовно такие. Они текст воспринимают хуже, чем схему.
Я вам не верю.
Нужен инструмент типа карандаша, с помощью которого можно было бы рисовать прямо на экране как на бумаге. [...] Пока такого прбора нет
Как это нет, когда у меня дома их три штуки?
Верить или не верить - это в Бога.
А у нас - почти 30-летний опыт обучения программированию, в том числе и с нуля.Поделитесь. А то я при моем 50-летнем опыте работы в ИТ не видел на персоналке такого инструмента.
А у нас — почти 30-летний опыт обучения программированию, в том числе и с нуля.
Опыт обучения программированию не эквивалентен корректно проведенному объективному наблюдению.
Я вот больше двадцати лет работаю с программистами, и не наблюдаю, чтобы "пацаны предпочитали текст".
Поделитесь. А то я при моем 50-летнем опыте работы в ИТ не видел на персоналке такого инструмента.
(это, кстати, пример того, что опыт не эквивалентен наблюдению)
Вакомовские (и не только) планшеты, если вам просто рисовать. Их же Pen Displays, если хочется рисовать именно на экране. У ленововских ноутбуков бывают перья для рисования на экране. У MS Surface есть перо для рисования. У iPad бывают перья для рисования.
Короче, если надо рисовать, то инструментов завались уже много лет.
Ну, ваши объективные наблюдения ничем не отличаются от наших... :)))
Не лучше и не хуже наших.Понятно, почему я их не замечал - у меня просто нет планшета и никогда не было.
А на компах, которые в классе стоят, такого не было.
Спасибо за наводку, попробую посмотреть, что там и как.
Ну, ваши объективные наблюдения ничем не отличаются от наших...
Вот именно поэтому я вашим и не доверяю.
Понятно, почему я их не замечал — у меня просто нет планшета и никогда не было. А на компах, которые в классе стоят, такого не было.
И вы даже не интересовались, что вообще есть в мире?..
Мы даже несколько раз опросы проводили. Это кроме непосредственно наблюдений на занятиях.
Планшеты меня никогда не интересовали. Я и смартфон-то купил только в прошлом году только для связи с одноклассниками.
Мы даже несколько раз опросы проводили. Это кроме непосредственно наблюдений на занятиях.
Повторюсь, ваше высказывание противоречит наблюдаемой мной картине мира. Я сам - будучи мужчиной, на всякий случай - регулярно прошу у людей блок-схемы в требованиях, мы с коллегами-мужчинами, обсуждая что-то, рисуем схемы, и так далее. Да чего далеко ходить, автор поста - мужчина, и, если я не путаю, все приводимые им хвалебные отзывы на Дракон - от мужчин. Зато ваше высказывание хорошо сочетается с неоднократно наблюдавшимся мной предрассудком. Так что за отсутствием подтверждений объективности вашего наблюдения, я предпочту верить тому, что вижу сам.
Что веселее - вы сам обесцениваете свое высказывание почти сразу же:
мы столкнулись с тем, что есть куча людей, которые не являются программистами (технологи всякие), но которым нужно по роду своей работы создавать алгоритмы в какой-нить системе управления на микропроцессорах. Я лично разговаривал с таким человеком, который мне сказал так: схему я понимаю прекрасно, а вот код писать мне трудно, я там много ошибок сделаю.
Эти вот "куча людей" - это все поголовно женщины? Человек, который сказал вам - это женщина?
Планшеты меня никогда не интересовали.
Может быть, не стоит тогда говорить о том, что таких приборов нет?
Особенно грустно, что ваши коллеги - например, Tim Roughgarden (извините за отсутствие транскрипции, никогда не мог запомнить, как это читается), ведущий одного из самых популярных на курсере курсов по алгоритмам - прекрасно пользуются графическими планшетами в своих лекциях, именно потому, что это позволяет быстро что-то написать или нарисовать на экране. Да что там, мой преподаватель в фотошколе уже скоро как двадцать лет назад пользовался дешевеньким планшетом для тех же целей.
Спорить не буду. У нас наши студенты как-то не очень любят диаграммы рисовать.
Хотя изучают UML в полном объеме. И даже у работодателей наших неоднократно наблюдал на экранах разнообразные UML-диаграммы.
Но студенты не любят - ибо в классах удобного инструмента нет.
На планшетах, есть, но вуз не может каждому студенту выдать планшет.
Вот мне самому - посмотрю, возможно получится использовать.
Но я лекции веду прямо у доски, поэтому рисую прямо на доске.
И, кстати, спасибо за подсказку - поразмыслю над темой, возможно тему такую замутим на кафедре.Опять же, мы говорим о разных сообществах людей.
Начинающие программеры и профи.
Они делают разного объема и уровня сложности системы.
Большие сложные системы скорее всего, удобно обозреть графически.
Но мне самому как-то не сильно требовалось.
Даже когда мы писали бортовую ось -еще в 80-х.
У нас наши студенты как-то не очень любят диаграммы рисовать. Хотя изучают UML в полном объеме.
UML-диаграммы я тоже не люблю рисовать.
Но студенты не любят — ибо в классах удобного инструмента нет.
… только ли поэтому? У меня вот есть инструменты, а я все равно не люблю.
Опять же, мы говорим о разных сообществах людей.
Начинающие программеры и профи.
Так на какое же сообщество ориентирован ДРАКОН?
Большие сложные системы скорее всего, удобно обозреть графически.
… но при этом "особенно большую пользу ДРАКОН приносит непрограммистам, программистам-любителям, начинающим программистам."
Что-то не складывается.
Это не говоря о том, что ДРАКОН не предназначен для представления систем он предназначен для представления алгоритмов, и по мере увеличения сложности алгоритма его читаемость на ДРАКОНе падает (см пример с quick search).
по мере увеличения сложности алгоритма его читаемость на ДРАКОНе падает (см пример с quick search).Нет, не падает. поясню.
Программа quick search — это вовсе не сложный, наоборот, это простейший, элементарный алгоритм. Его не надо придумывать, он давным-давно придуман.
Есть классические алгоритмы, например, quick search. Не надо их писать на ДРАКОНе, смысла нет.
Зачем нужен ДРАКОН?
В программировании — для разработки новых продуктов (а не для копирования старых, давно известных).
Программа quick search будет малой, тысячной или миллионной долей создаваемого нового сложного продукта.
Новый сложный продукт будет на ДРАКОНе, а входящие в него мелкие, классические, давно известные частицы типа quick search не обязательно переводить на ДРАКОН.
Чем сложнее продукт, тем больше выигрыш от использования ДРАКОНа.
Нет, не падает. поясню.
Если бы не падала, то quick search можно было бы выразить корректно, а это не удается.
Программа quick search — это вовсе не сложный, наоборот, это простейший, элементарный алгоритм.
Он не элементарный хотя бы потому, что в нем есть рекурсия. Которую, собственно, ДРАКОН выразить и не может.
Есть классические алгоритмы, например, quick search. Не надо их писать на ДРАКОНе, смысла нет.
Речь не о том, что надо или не надо, речь о том, что не получается.
Зачем нужен ДРАКОН?
В программировании — для разработки новых продуктов (а не для копирования старых, давно известных).
Как вы предлагаете разрабатывать продукт на языке для описания алгоритмов? У меня вот тут есть сервис, который сам по себе продукт, который состоит из нескольких десятков взаимодействующих компонентов, как вы предлагаете эти взаимосвязи описать на ДРАКОНе?
Чем сложнее продукт, тем больше выигрыш от использования ДРАКОНа.
(это утверждение нуждается в доказательстве)
Если на пальцах, то нет, потому что ДРАКОН, как он продемонстрирован, не умеет совершенно базовые вещи типа композиции, рекурсии или хотя бы типов данных с верификацией. Проще говоря, ДРАКОН никак не защищает от банальной ошибки "мы передали в операцию сложения картинку вместо числа".
У меня вот тут есть сервис, который сам по себе продукт, который состоит из нескольких десятков взаимодействующих компонентов, как вы предлагаете эти взаимосвязи описать на ДРАКОНе?Ваши взаимосвязи носят алгоритмический характер. Значит, их можно описать на ДРАКОНе.
Нет, взаимосвязь "функция А выполняется под ролью Б" не несет алгоритмического характера.
Понятно, почему прошло мимо - для вуза нашего дороговатое удовольствие в классы ставить.
Конкретный пример
youtu.be/_XOuhV_8N_I
Язык ДРАКОН на Южно-Балыкском газоперерабатывающем заводе (ГПЗ) компании «Сургутнефтегаз».
Шкаф управления установки глубокой переработки
широкой фракции легких углеводородов (ШФЛУ)
На видео показана установка глубокой переработки
широкой фракции легких углеводородов (ШФЛУ).
Во второй половине видео показан шкаф управления установки.
В шкафу управления используется программа управления, 70%-80% которой написано на языке ДРАКОН.
Программа управления загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Разработчик шкафа управления и программы управления Алексей Муравицкий.
Шкаф управления осуществляет управление
Установкой глубокой переработки широкой фракции легких углеводородов (ШФЛУ) на Южно-Балыкском газоперерабатывающем заводе (ГПЗ) компании «Сургутнефтегаз».
Фракция ШФЛУ — продукт переработки попутного нефтяного газа (ПНГ) и газового конденсата.
«Сургутнефтегаз» (СНГ) — одна из крупнейших российских нефтяных и газодобывающих компаний.
ДРАКОН-программа в шкафу управления создана с помощью инструментальной программы «ИС Дракон» Геннадия Тышова.
В шкафу управления используется программа управления, 70%-80% которой написано на языке ДРАКОН.
Это, простите, как посчитали?
Давайте на примере. Какой процент приведенного ниже алгоритма написан на языке ДРАКОН?
Уточню. При программировании ДРАКОН всегда работает в паре с целевым языком.
Например, Дракон в паре с языком Си — это называется гибридный язык Дракон-Си.
Иногда, надо дописать какую-то часть на Си (или другом целевом языке).
Это, простите, как посчитали?Так мне сказал автор программы Алексей Муравицкий. Ему виднее. Значит, Муравицкий 20-30% написал на чистом Си или на чем-то еще.
Здесь все на ДРАКОНе, т.е. на гибридном языке.
А. Тогда я знаю, как написать программу на 100% на ДРАКОНе: рисуем один квадратик с названием "програма", весь текст помещаем внутрь.
Так мне сказал автор программы Алексей Муравицкий. Ему виднее.
Ааа. Анекдот про "и вы говорите" слышали, я надеюсь?
я знаю, как написать программу на 100% на ДРАКОНе: рисуем один квадратик с названием «програма», весь текст помещаем внутрь.
Нет, не так. ДРАКОН создает графический каркас (графический чертеж) и имеет свои правила для текста (их очень немного).
99% текста внутри икон пишут на целевом языке (target language).
Ну вот я и сделаю "каркас" из одной "иконы", где будет весь текст программы на целевом языке. Получится программа, на 100% написанная на ДРАКОНе, по вашему определению.
я и сделаю «каркас» из одной «иконы», где будет весь текст программы на целевом языке. Получится программа, на 100% написанная на ДРАКОНе, по вашему определению.
Чем ближе к крайностям, тем дальше от истины.
Объясняю. При программировании на ДРАКОНЕ вы всегда программируете на гибридном языке Дракон-Х, где Х — целевой язык. Для краткости, можно условно сказать: программа написана на ДРАКОНе (при этом подразумевая гибридный язык Дракон-Х).
Ваш пример не имеет смысла, так как на ДРАКОНе в первую очередь идет проработка алгоритма. В вашем примере проработка алгоритма полностью отсутствует. Вы держите алгоритм в голове, что чревато ошибками.
Сергей Ефанов программирует на ДРАКОНе с 2010 года. Вот что он пишет в своей статье в 2012 году:
Попытаюсь сказать несколько слов о том, что это мне дало, и как выглядит процесс.
Написание программы распалось на два этапа — проработка алгоритма, и собственно программирование.
Главное в любой программе — алгоритм. В ДРАКОНе он рисуется, точнее — составляется из графических элементов. Очень похожих на элементы блок-схем.
Но есть несколько строгих правил, которые не позволяют схеме превратиться в запутанный клубок линий, квадратов и ромбиков.
Правила, на первый взгляд, простые. Но эффект от их применения — колоссальный!
На ДРАКОНЕ запутанный и непонятный алгоритм нарисовать просто нельзя. И наоборот, любой сложный алгоритм, нарисованный согласно этим правилам, становится очень понятным.
При разработке алгоритма теперь его не надо держать в голове при написании текста программы. Работа сводится к визуальному конструированию алгоритма. Это гораздо легче. Не требуется такое сосредоточение, как обычно. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент, потом легко вернутся к её продолжению.
И только когда весь алгоритм «отлизан» — переходим к собственно программированию. В чём оно теперь заключается? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка. На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.
Если же алгоритм хорошо декомпозируется, то и в текстовом виде он будет представлен в виде набора функций/методов с говорящими названиями так, что одновременно в голове надо будет держать всего десяток-другой строк.
Ваш пример не имеет смысла, так как на ДРАКОНе в первую очередь идет проработка алгоритма.
Да нет, он имеет смысл, потому что меня интересует очень простая вещь: что такое "программа на Х процентов написанная на ДРАКОНе". Вот у меня есть программа на 1000 строк. Вы говорите, что запихнуть все 1000 в одну драконовскую икону "не имеет смысла". Ну ладно, хотя мне интересно, какое правило ДРАКОНа это запрещает.
А если я сделаю 1000 икон по одной строке в каждой - так можно? На сколько процентов тогда эта программа будет написана на ДРАКОНе? А если я сделаю 10 икон по 100 строк? 100 икон по 10 строк?
Вы держите алгоритм в голове, что чревато ошибками.
Нет, не держу. Я его пишу. Точно так же, как разработчик на ДРАКОНе свой алгоритм рисует, я этот алгоритм пишу, только у меня еще есть инструментальные средства, которые мне подсказывают, что я переменные перепутал, или пытаюсь влезть куда не надо, или еще что - все то, что ДРАКОН просто игнорирует, потому что в нет нет средств работы с состоянием.
меня интересует очень простая вещь: что такое «программа на Х процентов написанная на ДРАКОНе».Предположим, что программа состоит из двух частей. Первая часть в виде дракон-схемы на гибридном языке Дракон-Си (это 80%). Эта часть автоматически конвертируется в исходный код на Си. Оставшаяся часть дописывается на чистом Си (20%).
Я не держу алгоритм в голове. Я его пишу. Точно так же, как разработчик на ДРАКОНе свой алгоритм рисует, я этот алгоритм пишу.Это не так. Вы пишете программу, но не алгоритм.
Это принципиальное отличие. Все (и вы в том числе) привыкли называть программу алгоритмом.
Академик АН СССР А.А. Дородницын (и я вслед за ним) строго различаем эти понятия.
Повторяю: вы держите алгоритм в голове, что чревато ошибками. В прошлой статье на Хабре
Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОНна примере Боинга 737 МАХ я показал, что человечество не умеет писать алгоритмы без ошибок.
Язык ДРАКОН — это шаг к безошибочным алгоритмам. ДРАКОН позволяет заметно сократить число ошибок.
Насчет IDE вы частично правы, но это дело наивное. Со временем появятся и качественные ДраконIDE.
Почему частично?
У ДРАКОНа нет средств работы с состоянием.Отвечаю. Силуэт можно использовать как конечный автомат. Ветка силуэта — это состояние автомата. Подробнее см. статью Степана Митькина Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019.
Первая часть в виде дракон-схемы на гибридном языке Дракон-Си (это 80%). Эта часть автоматически конвертируется в исходный код на Си. Оставшаяся часть дописывается на чистом Си (20%).
Как вы меряете соотношение между картинками (ДРАКОН — это картинки) и текстом?
Повторяю: вы держите алгоритм в голове, что чревато ошибками.
Вы можете повторять, сколько угодно, вы от этого более правым не станете. Я не держу алгоритм в голове, я его записываю. То, что я записываю алгоритм в виде программы, никак не отменяет того, что я его записываю. Для сравнения, вы записываете алгоритм в виде ДРАКОН-схемы.
А еще, как уже показывалось выше, есть вещи, которые ДРАКОН-схема сама по себе выразить не может, и которые "надо держать в голове".
Язык ДРАКОН — это шаг к безошибочным алгоритмам. ДРАКОН позволяет заметно сократить число ошибок.
Как неоднократно обсуждалось и на примере Боинга, и в этой статье, утверждение "ДРАКОН позволяет заметно сократить число ошибок" безосновательно.
Насчет IDE вы частично правы, но это дело наивное. Со временем появятся и качественные ДраконIDE.
… а я не про IDE. Я про язык.
Отвечаю. Силуэт можно использовать как конечный автомат. Ветка силуэта — это состояние автомата.
А мне недостаточно состояния автомата. Состояние автомата — это слишком бедно. Сумма строк заказа невыразима как состояние автомата.
Подробнее см. статью Степана Митькина Автоматное программирование на языке ДРАКОН
Даже в этой статье прекрасно видно, что состояния автомата недостаточно. Все выделенное — это состояние, но не состояние автомата.
(отдельно, кстати, прекрасное мысленное упражнение — понять, глядя только на эту диаграмму, есть в ветке Bar ошибка, или нет)
Опять дракон не сделал алгоритм безошибочным…
Кстати, да, спасибо за пример. Это вот типичное "надо держать в голове" — надо помнить, какие входные символы бывают, это нигде явно не описано. В то время как есть языки, в которых это описывается явно и проверяется на этапе компиляции. Так какой же язык позволит меньше ошибок, ДРАКОН, или тот, который проверяет, что КА обрабатывает весь алфавит?
PS В сгенеренном коде, кстати, вообще ничего не произойдет. Т.е. состояние не изменится, не будет ошибки — мы просто проигнорируем непредвиденную ситуацию.
Вызов будет проигнорирован без генерации исключения. Важно иметь возможность игнорировать ненужные сигналы. Если в автомат приходит сигнал, который не обрабатывается в текущем состоянии, это не ошибка. Игнорирование сигналов — полезный элемент поведения автоматов.
Happy debugging.
PPS Из статьи:
Непустые иконы "вариант" на всех ветках вместе задают входной алфавит, или множество входных символов (сигналов) V автомата.
Это значит, что одна опечатка — и мы получим лишний символ, который нигде больше не обрабатывается. Снова happy debugging.
Как вы меряете соотношение между картинками (ДРАКОН — это картинки) и текстом?Очень просто. Предположим, что мы работаем на гибридном языке Дракон-Си.
В этом случае, говоря вашими словами, «картинка (ДРАКОН — это картинка)» автоматически транслируется (конвертируется) в исходный код на языке Си. А «текст» тоже написан на чистом Си.
Таким образом, согласно ДРАКОН-технологии обе части программы (дракон-схема и текст) приводятся к одному знаменателю. И предстают перед нами в виде исходного кода на языке Си.
Две части кода на Си сравнить нетрудно. Если первая часть содержит, например, 800 строк, а вторая 200 строк, значит, получим 80% и 20%.
То есть если для одной и той же схемы один генератор создает 200 строк, а второй - 800, то _одна и та же программа_ будет написана то на 50 процентов на ДРАКОНе, то на 80?
(учитывая то, какой код генерит приведенный выше пример для КА, такая разница вполне возможна)
Шаг 1. Дракон-схема транслируется в исходный код на языке Си. Здесь же добавляется кусочек на чистом Си.
Шаг 2. Исходный код на языке Си
стандартным образом с помощью стандартных IDE обрабатывается и преобразуется в исполняемый (executable) код.
__________
Шаг 2 может быть и иным (это отдельный разговор).
Генератор, о котором вы говорите, входит в состав ДРАКОН-конструктора, например, программы ИС Дракон Генадия Тышова.
Именно с ним работает предприниматель Алексей Муравицкий. Так что Алексей пока что имел дело только с одним генератором. Экспериментальная статистика о двух (или трех и более) генераторах отсутствует. Возможно, вы и правы.
Вот что пишет сам Алексей (ПЛК — программируемый логический контроллер):
Моя компания ОКБ АМУР №3 okbamur3.ru уже 5 лет работает на языке ДРАКОН для программирования ПЛК на промышленных объектах с помощью ДРАКОН-конструктора.
Специалисты моей компании пишут программу непосредственно в языке ДРАКОН, и затем генерируют код ST для CODESYS 3.5 (2.3). Отладку схемы осуществляют в среде CODESYS, в связи с отсутствием на сегодняшний день МЭК-версии ДРАКОН-конструктора.
Существующий ДРАКОН-конструктор имеет ряд недостатков, снижающих производительность труда.
По этой причине моя компания второй год занимается разработкой более совершенного ДРАКОН-конструктора с возможностью эмулятора схемы, и непосредственной загрузкой программы из ДРАКОН-схемы в ПЛК, без промежуточного ПО.
Алексей Муравицкий
Главный инженер ОКБ АМУР №3
Такие "дополнительные сведения" можно про любой язык написать, они бесполезны, пока нельзя сравнить с решением той же или аналогичной задачи на другом языке.
Вот я, скажем, уже больше 15 лет пишу на языке, на котором я сейчас пишу (название не важно), специалисты компании, в которой я работаю, пишут программы непосредственно на этом языке, отладку осуществляют в его же родной среде разработки (это, заметим, лучше, чем у ДРАКОНа).
Ну вот и что поменялось от этого знания?
я уже больше 15 лет пишу на языке, на котором я сейчас пишу (название не важно), специалисты компании, в которой я работаю, пишут программы непосредственно на этом языке, отладку осуществляют в его же родной среде разработки (это, заметим, лучше, чем у ДРАКОНа).Это недоразумение. На ДРАКОНе можно делать точно так же. Обозначим язык, про который вы говорите, XYZ.
ДРАКОН-технология работает так (в случае гибридного языка Дракон-XYZ).
Шаг 1. Дракон-схема транслируется в исходный код на языке XYZ.
Шаг 2. Исходный код на языке XYZ стандартным образом с помощью стандартных IDE языка XYZ обрабатывается и преобразуется в исполняемый (executable) код. Или, говоря вашими словами, «специалисты осуществляют отладку в его же (XYZ) родной среде разработки».
Разница лишь в том, что отладка в родной среде XYZ будет проще и быстрее, так как ДРАКОН уже выявил и устранил значительную часть ошибок.
Таким образом, отладка в родной среде языка XYZ входит в состав ДРАКОН-технологии. Но в некоторых случаях по желанию пользователя ее можно опустить. Например, предприниматель Алексей Муравицкий, пытаясь оптимизировать свою работу и сократить издержки, стремится исключить из ДРАКОН-технологии работу с языком программирования ST стандарта IEC61131-3. и IDE промышленной автоматики CoDeSys 3.5 (2.3).
Так что ваша фраза «это, заметим, лучше, чем у ДРАКОНа» основана на недоразумении и неверна.
Так что ваша фраза «это, заметим, лучше, чем у ДРАКОНа» основана на недоразумении и неверна.
Она основана на утверждении из приведенной вами же цитаты: "Отладку схемы осуществляют в среде CODESYS, в связи с отсутствием на сегодняшний день МЭК-версии ДРАКОН-конструктора."
ДРАКОН уже выявил и устранил значительную часть ошибок.
Нет, не выявил и не устранил. Примеры выше.
Таким образом, отладка в родной среде языка XYZ входит в состав ДРАКОН-технологии.
Угу. Как дополнительный этап. А когда эта отладка показала ошибку в алгоритме, надо вернуться на шаг 1, исправить схему и начать все сначала, получая дополнительные, по сравнению с "моим" языком шаги и временные затраты.
Но в некоторых случаях по желанию пользователя ее можно опустить.
Нельзя исключить отладку "по желанию пользователя". Отладка нужна тогда, когда есть ошибки, которые не обнаружимы другим способом.
Так что ваша фраза «это, заметим, лучше, чем у ДРАКОНа» основана на недоразумении и неверна.
Как показано выше, эта фраза все еще верна: ДРАКОН заставляет делать при отладке дополнительные шаги по сравнению с его отсутствием.
ДРАКОН уже выявил и устранил значительную часть ошибок.
Я, кажется, уже спрашивал, и, кажется, так и не получил ответа: приведите, пожалуйста, пример хотя бы пяти распространенных ошибок, от которых ДРАКОН как язык гарантированно защищает.
То, что этот вопрос (уже не первый раз) остается без ответа, наводит меня на грустные мысли, что таких ошибок нет, а утверждение про "выявил и устранил" - это просто надежды автора, не подкрепленные никаким формальным аппаратом.
Таким образом, отладка в родной среде языка XYZ входит в состав ДРАКОН-технологии. [...] Так что ваша фраза «это, заметим, лучше, чем у ДРАКОНа» основана на недоразумении и неверна.
По здравому разышлению, это банальная подмена. В случае ДРАКОНа: "Специалисты моей компании пишут программу непосредственно в языке ДРАКОН [...] Отладку схемы осуществляют в среде CODESYS [другой язык]". В моем примере: "специалисты компании, в которой я работаю, пишут программы непосредственно на этом языке, отладку осуществляют в его же родной среде разработки".
Важно не то, что отладка ведется в родной среде разработки целевого языка. Важно то, что отладка ведется в среде разработки языка разработки.
Отладку схемы осуществляют в среде CODESYS [другой язык]Тут у вас неточность. CoDeSys — это не другой язык. Это вообще не язык.
CoDeSys — это IDE промышленной автоматики.
А где же язык программирования?
В CODESYS для программирования доступны все пять определяемых стандартом IEC 61131-3 (МЭК 61131-3) языков:
— IL (Instruction List) — ассемблер-подобный язык
— ST (Structured Text) — Pascal-подобный язык
— LD (Ladder Diagram) — язык релейных схем
— FBD (Function Block Diagram) — язык функциональных блоков
— SFC (Sequential Function Chart) — язык диаграмм состояний
В дополнение к FBD поддержан язык программирования CFC (Continuous Function Chart) с произвольным размещением блоков и расстановкой порядка их выполнения.
Вы пишете:
Важно не то, что отладка ведется в родной среде разработки целевого языка. Важно то, что отладка ведется в среде разработки языка разработки.А что говорит Алексей Муравицкий? Он не согласен с вами. Для него язык разработки — ДРАКОН, а отладку он ведет не в среде языка разработки, а в среде целевого языка ST — одного из пяти языков, определяемых стандартом IEC 61131-3 (МЭК 61131-3) языков.
Мы с вами знаем, что Алексей стремится устранить лишнее звено, сократить издержки и избавиться от ST и CoDeSys:
моя компания второй год занимается разработкой более совершенного ДРАКОН-конструктора с возможностью эмулятора схемы, и непосредственной загрузкой программы из ДРАКОН-схемы в ПЛК, без промежуточного ПО.Но это не значит, что метод Алексея Муравицкого удастся легко распространить на другие целевые языки.
Тут у вас неточность. CoDeSys — это не другой язык. Это вообще не язык. CoDeSys — это IDE промышленной автоматики. А где же язык программирования?
Это совершенно не важно для этой дискуссии.
А что говорит Алексей Муравицкий? Он не согласен с вами. Для него язык разработки — ДРАКОН, а отладку он ведет не в среде языка разработки, а в среде целевого языка ST — одного из пяти языков, определяемых стандартом IEC 61131-3 (МЭК 61131-3) языков.
Он не согласен со мной? Он не согласен со мной в том, что отладка в среде целевого языка - это лишнее звено?
Мне кажется, вы - намеренно или случайно - не понимаете, что я вам хочу сказать. Мне важно, что при разработке на используемом мной языке я веду всю разработку и отладку в одной среде. То, что ДРАКОН такой возможности не предоставляет, я считаю недостатком ДРАКОНа.
Мне важно, что при разработке на используемом мной языке я веду всю разработку и отладку в одной среде.Так работают многие или даже все программисты в мире. А что получается? Несмотря на наличие замечательных IDE и других средств (для борьбы с ошибками) проблема ошибок как была, так и осталась нерешенной.
На тестирование, отладку, моделирование и др. человечество вынуждено тратить значительные ресурсы. И тем не менее на этапе эксплуатации выявляются новые ошибки, которые не удалось выявить ранее.
Все (и вы в том числе) считают такое положение нормальным. А я считаю, что это ненормально, что нужны новые средства для противодействия ошибкам.
Язык ДРАКОН — новое средство подавления ошибок.
То, что ДРАКОН такой возможности не предоставляет, я считаю недостатком ДРАКОНа.Я отношусь к вашему мнению с уважением, но согласиться с вами не могу.
А я считаю, что это ненормально, что нужны новые средства для противодействия ошибкам. Язык ДРАКОН — новое средство подавления ошибок.
В том-то и дело, что нет. Вы упираете на то, что существующие языки "не решили проблему ошибок", но при этом не можете привести ни одной ошибки, которую бы исключал ваш язык.
Все (и вы в том числе) считают такое положение нормальным.
Это, кстати, неправда. Я считаю, что ошибки во время выполнения программы - это плохо, и поэтому пользуюсь различными инструментами, которые уменьшают вероятность таких ошибок.
Я отношусь к вашему мнению с уважением, но согласиться с вами не могу.
Вы не можете согласиться с тем фактом, что необходимость использования двух инструментов при отладке вместо одного - это недостаток?
Это, кстати, неправда. Я считаю, что ошибки во время выполнения программы — это плохо, и поэтому пользуюсь различными инструментами, которые уменьшают вероятность таких ошибок.Вы (как и все остальные программисты на земном шаре), пользуетесь только теми инструментами, которые придумало человечество, других просто нет.
Но все эти замечательные инструменты, (прекрасные сами по себе) не могут решить проблему ошибок. Именно поэтому произошла парная катастрофа Боинга 737 МАХ, унесшая сотни жизней.
Разве это хорошо? Разве это нормально?
Нет, это плохо. Это ненормально.
Поэтому нужны новые инструменты для подавления ошибок. ДРАКОН — именно такой инструмент.
Поэтому нужны новые инструменты для подавления ошибок. ДРАКОН — именно такой инструмент.
Подождите, то есть вы просто проигнорировали ту часть моего комментария, где написано, что это не так?
Именно поэтому произошла парная катастрофа Боинга 737 МАХ, унесшая сотни жизней.Вот как раз ошибок в самом ПО там и не было. Оно работало строго по тому алгоритму, который заложили конструкторы самолёта.
Основная причина этих катастроф — плохая подготовка пилотов, не выполнивших чек-лист «Runaway Stabilizer», который должны были выполнять по памяти, то есть знать наизусть как условия активации чек-листа, так и порядок действий. А основное действие по этому чек-листу — отключение электропривода триммера — не менялось с 1967 года (https://habr.com/post/556052/#comment_23008598).
Сопутствующая проблема была в архитектуре системы — решение на перекладку стабилизатора принималось на основании только одного датчика угла атаки. Но проблемы архитектуры никакой дракон не решит.
Видимо, это был финал дискуссии
Нет, не финал. Как только у меня кончится форс-мажор, я собираюсь ответить.
Как улучшить блок-схемы алгоритмов по ГОСТ 19.701-90? Эргономичный визуальный алгоритмический язык ДРАКОН. Критерии