Comments 71
В основе ДРАКОН лежат принципы эргономизации традиционных блок-схем. Соединители - один из элементов для достижения этой цели.
принято разбивать на ветки и перемещаться между ними с помощью специальных элементов. Мы называем их «порталами».в блок-схемах не хватало именно соединителей. Ну, или знаний о том, что таковые в блок-схемах существуют.
Это не совсем так. Помимо запрета пересечений, ДРАКОН предполагает упорядоченное расположение элементов. По моим наблюдениям, многие дизайнеры пренебрегают этим, за счет чего схема превращается в подобие осьминожки.
Есть и другие принципы, которые остались за рамками статьи. Про один из них вы правильно отметили - выделение «главного пути». Помимо этого, в методологии есть принцип «общей судьбы» (однотипные элементы разных веток располагаются на одном уровне) и рекомендации по проектированию сложных условий.
Кроме того, мы внесли в методологию ряд собственных изменений, чтобы сделать её удобнее для работы с разговорными продуктами. Главное из них - карточки ситуаций.
(«рекомендации по проектированию сложных условий» — это Паронджанов придумал специально для умственно неполноценных, неспособных к тому, что ученики средней школы 30 лет назад осваивали)
зы. попробуйте BPMN. Там как раз есть разделение по ролям (как раз в первой схеме у вас разделение на действия юзверя и действия бота), есть нормальные рисовалки (которые автоматически верифицируют процесс), есть даже средства моделирования.
Мы рассматривали IDEF3 в качестве одного из вариантов, но ДРАКОН показался нагляднее и легче для восприятия.
Это немного разные области.
Я, например, использую BPMN для описания общих бизнес-процесса и ДРАКОН для конкретных сценариев, пробовал таблицы параметров - гораздо сложнее воспринимается.
Действительно, для BPMN есть рисовалки, верификаторы и автоматизация, но особенности реализации в нем гораздо менее наглядны.
Как только люди не изгаляются, лишь бы код не писать.
Попробуйте в коде задать граф квестов и потом научить гейм-дизайнеров его делать, некоторые структуры гораздо проще задавать визуально, графы это одна из них, дракон это грубо говоря правила упорядочивания графа, что бы он не превращался в огромного макаронного монстра.
Даже табличное представление квестового графа это полная ж... ГД тут же начинают плакать и просить цветовую подкраску что бы хоть как-то читать это.
Кстати, о гейм-дизайнерах. Для "Planescape: Torment" диалоги и квесты расписывали как раз в таблице Excel.
Было ли это легко в работе?
Вот тут сделали собственный редактор для создания диалогов на Unity.
https://www.youtube.com/watch?v=JJsBJty8DKo
Точно не легко, такую работу вижу каждый день, без минимальной цветовой раскраски невозможно работать, в экселе это решали заливкой ячеек. И мысль пока развивается в сторону примерно такого редактора, но никто не пробовал насколько удобно будет им пользоваться, это красиво выглядит когда в демке примерно 1% от необходимого контента, что будет когда добавят остальные 99% не понятно, но думаю что в любом случае будет лучше, если не давать пользователям свободно размещать блоки и связи, а контролировать геометрическое расположение блоков будут правила как в Драконе.
Описание квестов в виде конечного автомата, а не набора правил, приводит к запоротым сейвам, когда игрок действует не так, как задумывал дизайнер.
В чем проблема конечного автомата? В том, что он плохо интегрируется в игру и переходы не осуществляются как надо?
В том, что он имеет своё состояние, никак не связанное с состоянием мира. Классический пример: по квесту надо поговорить с персонажем, а он самоубился ранее, упав с высоты.
Это просто конченый автомат с багом. Где гарантия, что в наборе правил вы это не забудете? В любом случае играть дальше без обновления программы не получится.
КА без багов не существует. Банально замучаешься вставлять после каждого шага условие "такой-то персонаж мёртв? фейлим квест". А потом для каждого персонажа "умер? а такой-то квест активен? тогда фейлим его". А правило тут простое: "кто-то из участников квеста мёртв => квест зафейлен".
Существуют способы описания КА, которые позволяют делать переход из группы состояний.
КА без багов существует, но этому есть цена. Испорченные сейвы это просто побочка, а проблема в сложности их написания.
А еще можно делать разные комбинации КА с другими подходами, по отдельности и все сразу:
- КА + Правила (Если нода в графе надоступна, выкинуть граф)
- Автогенерация дополнительных состояний КА. При сборке проекта добавлять нужные ноды на смерть персонажа.
- Вложенные КА, квестовой просто рассматривает выходы из диалога, а диалог отдельный КА. Нужно будет добавить автоматическую проверку для совместимости.
КА это вещь которая легко воспринимается человеком, правила сильно сложнее в понимании и поддержке. В идеале нужно брать лушчее из каждого подхода.
из моего опыта программирования интерфейсов пользователей оборудования (из этого можно сделать тот еще квест):
Взаимодействуя с системой пользователь создает в своем мозге ее модель.
Если поведение системы не соответствует модели, пользователь испытывает боль и негодование.
Задача программиста - при проектировании системы постараться, чтобы взаимодействие с системой как можно быстрее приводило к формированию в мозге пользователя той модели, которая запрограммирована.
мои наблюдения показывают, что модели на базе конечных автоматов (в т.ч. иерархических) гораздо понятнее (быстрее усваиваются), чем на базе цепочек действий, флагов, таблиц, наборов правил и т.п.
Только вот граф квестов, скорее всего, будет иметь больше связей чем разрешено в драконе.
Создатели дракона гордятся тем что на их языке нельзя составить программу нарушающую принципы структурного программирования — а при составлении квестов требуется прямо противоположное: возможность предусмотреть как можно больше переходов.
Насколько я знаю, единственный способ представить произвольный КА в виде дракон-схемы — воспользоваться "силуэтом", но это будет так же экселька, вид с боку.
Если вы можете это описать словами, таблицей, программой — значит, сможете и отобразить в блок-схеме, даже обставленной более строгими правилами.
Единственное, что может не быть «главного пути».
Создатели дракона гордятся тем что на их языке нельзя составить программу нарушающую принципы структурного программированияв одной из прошлых веток доказали, что можно.
Ну вот возьмём простейшую цепочку из 4х стадий: A — B — C — D, и попробуем добавить сокращения A — C и B — D. Насколько я знаю, дракон не даст добавить оба сокращения, хотя в блок-схеме такое отображается без проблем.
в одной из прошлых веток доказали, что можно
Ага, путём перехода к "силуэту". Но это убивает главное достоинство графического представления — наглядность.
Идея в том что бы брать что-то хорошее из одной системы и адаптировать для другой системы. Если не подходит чистый Дракон, можно сделать же какую-то подходящую модификацию на основе идеи дракона о том что одинаковые логически схемы выглядят одинаково. Как мне видится нодовый редактор квестов, это обычный нодовый редактор, только с автоматическим позиционированием элементов. Возможно это нельзя сделать в полной мере, возможно вообще нельзя, у меня еще не было возможности проработать эту идею.
Не должно быть графа квестов, один квест один граф, а то и один квест, много графов.
Например: надо найти меч кладинец и зарубить кащея. В этом квесте состояния простые, нашёл/не нашёл. А сам процесс поиска это отдельный граф.
Тогда и писать и тестировать можно будет по частям. И каждый граф можно сделать таким, чтобы человек легко его воспринимал.
Порталы на дракон схеме позволяют выносить части диаграммы отдельно для переиспользования. А по факту это и есть те самые подграфы квеста и их можно использовать еще и для упраления сложностью.
Поскольку код парсится в абстарктный синтаксический граф, то все метрики по сложности кода, вполне применимы и к сложности квестового графа.
я бы сказал: лишь бы его потом не переписывать
Как пользователь могу сказать: засуньте себе в жопу этих чат-ботов и дайте мне форму с 4 полями, а потом уже говорите про эргономику.
/sarcasm
Да, даже в «форме из 4 полей» эти дизайнеры умудряются сделать 6 полей — ибо показания счетчиков горячей воды отправляются в 2 конторы — поставщику воды и поставщику тепла.
И что забавно, в поле для «поставщика воды» допустим только ввод цифр, а для «поставщика тепла» и цифр, и букв.
После перехода на ДРАКОН дизайнеры получили визуальный язык, с которым комфортно работать и которому можно быстро обучить членов команды.
Все проблемы блок-схем раскрываются с увеличением сложности. Вот когда блок-схема становится на 10 экранов по ширине и по высоте. Начинаются проблемы с навигацией, отладкой, переиспользованием.
Кроме всего блок-схемы часто скрывают структуры данных, в которых все хранится. Действия в них видно, а вот что между ними передается, где и какое значение и чем перезапишется — не видно.
Все эти проблемы в той ли иной степени удобства решены в классическом подходе с кодом. У блок-схем же с этим пока туго. Поэтому блок-схемы появились чуть ли не раньше языков программирования, но использование их очень нишевое.
Вы можете дизайнеров обучить коду — дорого, не у всех выйдет — это все да, но оставшиеся смогут. А вот если вы выбрали подход с блок-схемами и сложность в них доросла до критичного уровня — обучением тут уже ничего не добьешься. Рефакторинг поможет, но это крайне дорогая операция, запускать ее часто не выйдет — проект выйдет золотым.
Поддерживаю Кирилла Богатова @Rainvention. Применение языка ДРАКОН для описания сценариев чат-ботов — интересное направление. Хорошо, что по этой теме появилась статья на Хабре.
@Keeper13 "Как только люди не изгаляются, лишь бы код не писать".
Язык ДРАКОН позволяет писать код. Для этого используется концепция "гибридный язык", например Дракон-Си, Дракон-JavaScript, Дракон-Python, Дракон-Lua и т.д.
@mixstureВсе проблемы блок-схем раскрываются с увеличением сложности. Вот когда блок-схема становится на 10 экранов по ширине и по высоте.
Этого можно избежать с помощью декомпозиции. Для декомпозиции в языке ДРАКОН служит икона Вставка (по ГОСТ 19.701-90 она называется "предопределенный процесс").
@DvoiNic «рекомендации по проектированию сложных условий» — это Паронджанов придумал специально для умственно неполноценных, неспособных к тому, что ученики средней школы 30 лет назад осваивали
Это не так. Умственная неполноценность и неспособность тут ни при чем. Суть в том, что речь идет об очень занятых людях, у которых нет времени изучать дополнительную информацию.
Вот пример. Сейчас написана медицинская книга
«Клиническая алгоритмическая медицина. Алгоритмы диагностики и лечения на медицинском языке ДРАКОН».
При создании книги участвовали 5 докторов медицинских наук и 3 кандидата медицинских наук. Это специалисты очень высокой квалификации. О чем книга? Например, глава 15. «Проблема COVID-19. Респираторная терапия дыхательной недостаточности, ассоциированной с COVID-19».
Врачи очень заняты. Их задача — лечить людей, в частности, от коронавируса. Они могут выделить очень мало своего драгоценного времени на изучение правил записи клинических алгоритмов.
Однако правила клинических алгоритмов они должны знать. Как же быть? Ответ простой. Надо упростить задачу и сделать ее наглядной и легкой для понимания. Это можно сделать с помощью языка ДРАКОН.
Этого можно избежать с помощью декомпозиции. Для декомпозиции в языке ДРАКОН служит икона Вставка (по ГОСТ 19.701-90 она называется «предопределенный процесс»).
Да, это похоже на вызов функций. Но все также не дотягивает до классического подхода. Где тут сигнатура функции с описанием параметров и типов (а в некоторых языках еще и с типами бросаемых исключений)? Что вернет эта функция и куда? А как передать ошибку вместо результата? Как передать параметры по ссылке и по значению в функцию? А вот если функция принимает на вход сложный тип данных — объект с 5 полями — это как описать?
А как хранить эти функции? В одной общей куче или есть деление по модулям?
Вот в итоге и получается, что вроде функции есть, но на таком зачаточном уровне, что много и часто их применять не выйдет. Ответы на все вопросы выше не зря придуманы в классическом подходе — каждый из них снижает связность функции и внешнего мира, что снижает сложность восприятия алгоритма, позволяя реализовывать более сложные при все тех же ограничениях человека.
@mixsture Вы говорите о программировании. "Чистый" ДРАКОН описывает только поток управления (control flow), поток работ (workflow), но не программирование.
Чтобы программировать, нужно использовать гибридные языки, например Дракон-Си. Для этого служат специальные программные средства, например ДРАКОН-конструктор Геннадия Тышова "ИС Дракон".
Вы говорите о программировании. «Чистый» ДРАКОН описывает только поток управления (control flow), поток работ (workflow), но не программирование.
Допустим, пусть только поток работ (хотя в чат-боте то пытаются на нем программировать, но оставим это на совести автора). Смысл остается тем же:
1) при крайне ограниченных инструментах снижения сложности, вся система довольно быстро упрется в максимально осознаваемую человеком сложность. И эта точка на порядки ближе, чем для классического программирования. Затем придется решать, либо переходить к лапше-стилю (условия и циклы на драконе, а операторы внутри на классическом ЯП) и у этого стиля масса недостатков, либо все с нуля переписать на классическом ЯП.
2) данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме. Каждый волен понимать состав по-своему.
@mixsture либо переходить к лапше-стилю (условия и циклы на драконе, а операторы внутри на классическом ЯП) и у этого стиля масса недостатков
Здесь нужны конкретные примеры. Ваше описание похоже на программирование на ДРАКОНе на гибридном языке.
Посмотрите пять примеров Степана Митькина. Каждый пример содержит
1) программу на гибридном языке ДРАКОН-JS и
2) эквивалентную классическую текстовую программу на JavaScript.
данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме.
Почему не отражается? Это не так. Можно отразить с помощью иконы Полка и иконы Комментарий.
function Tree_itemClick(machine, item, event) {
if (event.button !== 0) {
return;
}
const now = getUnixTime();
const isDoubleClick = item.lastClick && now - item.lastClick < DoubleClickThreshold;
if (machine.state === "expanding") {
if (isDoubleClick) {
machine.postponedDClick = item.id;
}
return;
}
if (isDoubleClick) {
Tree_doubleClick(machine, item, event);
return;
}
item.lastClick = now;
if (event.ctrlKey) {
Tree_ctrlClick(machine, item);
return;
}
if (item.leaf) {
Tree_singleClick(machine, item, event);
return;
}
Tree_clearSelection(machine);
Tree_selectItem(machine, item);
Tree_toggleExpand(machine, item, event);
}
Я вижу, например, какая каша из if/else получилась в третьем примере из-за дословного следования блок-схеме. А ведь всё читается гораздо проще при использовании early return.
Аналогично и с другими примерами. Каждый из них можно переписать так, что он будет гораздо понятнее.
Вы совершенно правы. Что отсюда следует?
Две нотации эквивалентны, они дают одинаковый результат.
Нотация ДРАКОНа позволяет писать программы.
ДРАКОН-схему можно автоматитчески преобразовать (транслировать) в эквивалентный код на классическом языке программирования.
В оттранслированный код смотреть не нужно, точно так же, как мы не смотрим на машинный (executable) код после компиляции.
Исходником (исходным кодом) является ДРАКОН-схема и только она.
Все исправления, изменения и улучшения делаются только в исходнике, то есть в ДРАКОН-схеме.
Производить изменения и улучшения в оттранслированном коде ЗАПРЕЩЕНО.
Таким образом, ваши слова "всё читается гораздо проще при использовании early return" в рамках ДРАКОН-технологии просто не нужны.
Почему не нужны? Потому что все читается гораздо проще, когда мы смотрим на ДРАКОН-схему (а не на код).
Впрочем, некоторые профессиональные программисты, привыкшие к текстовому коду, с этим могут не согласиться. Но ДРАКОН создан не для них, а для тех, кто испытывает трудности при работе с кодом.
Потому что все читается гораздо проще, когда мы смотрим на ДРАКОН-схему (а не на код).Всё гораздо проще читается, когда мы смотрим на красивый, правильно структурированный код, а не на листик с блок-схемой. Хороший код читается практически линейно.
Все исправления, изменения и улучшения делаются только в исходнике, то есть в ДРАКОН-схеме.Кстати, раз уж упомянули об изменениях и улучшениях, как там у дракона с diff-ами? Как мне увидеть изменения между двумя версиями схемы?
Вы правильно заметили по поводу линейности хорошего кода. Однако разговорные интерфейсы (чат-боты, голосовые помощники) редко бывают такими. Например, пользователи могут пропускать шаги, переспрашивать или вовсе уходить от темы.
Проектирование сценариев не ограничивается кодом. Так, на этапе проектирования мы читаем сценарий по ролям, чтобы учесть как можно больше вариантов поведения пользователя. А для этого нужно видеть весь флоу, с чем прекрасно справляется схема.
Кроме того, дизайнер сценариев и программист - это разные роли с разными скиллсетами.
Я возражаю против того, чтобы называть дракон языком программирования и пытаться сделать из него серебряную пулю.
Нарисовать общий сценарий работы чат-бота — возможно. Переносить (транслировать) код напрямую из блок-схемы — так себе решение (что можно увидеть на тех пяти примерах Митькина), особенно с учётом того, что отлаживать то придётся по коду, отладчиков для схемы у дракона нет.
Аналогично и с другими примерами. Каждый из них можно переписать так, что он будет гораздо понятнее.
Вы совершенно правы. Что отсюда следует?
Напрашивается ответ, что оттуда следует низкая квалификация того, кто писал первоначальные варианты, не правда ли?
особенно если почитать претензии Митькина «Снова противная „ёлочка“ из фигурных скобок.» или «эти функции имели бы странные, мало значащие имена» (На мой взгляд, функции имеют такие имена, которые им дает автор. Если Митькин дает странные имена — глупо этим возмущаться. Хотя, возможно, он давал имена по вашим рекомендациям)
схему можно автоматитчески преобразовать (транслировать) в эквивалентный код на классическом языке программирования.для этого нужно в каждую иконку вписать код на требуемом языке программирования. Собственно, ровно такой же «транслятор» можно сделать для блок-схем. Никакой разницы.
В оттранслированный код смотреть не нужно, точно так же, как мы не смотрим на машинный (executable) код после компиляции.потому, что там сплошные goto. Более-менее полноценный транслятор вы (вся ваша команда) не осилили. И вы знаете, почему.
Исходником (исходным кодом) является ДРАКОН-схема и только она.Отладчик с отображением на дуракон-схеме сделали? Средства верификации? средства коллективной разработки? средства отслеживания изменений?
Впрочем, некоторые профессиональные программисты, привыкшие к текстовому коду, с этим могут не согласиться.А есть ли «профессиональные программисты, не привыкшие к текстовому коду»? А есть ли профессиональные программисты, пользующиеся дураконом? Есть ли более-менее сложные системы, надураконенные (задураконенные?) такими программистами?
Но ДРАКОН создан не для них, а для тех, кто испытывает трудности при работе с кодом.т.е для «умственно неполноценных программистов».
дуракон-схеме
дураконом
надураконенные
задураконенные
Что за детский сад, зачем слова коверкать?
т.е для «умственно неполноценных программистов».
У вас ЧСВ воспалилось, обратитесь к врачу.
Что за детский сад, зачем слова коверкать?
На мой взгляд, это точнее отражает суть этого предмета.
У вас ЧСВ воспалилось, обратитесь к врачу.
А как вы считаете, у кого больше проблемы с ЧСВ — у меня, или у человека, пишущего книги «почему мудрец похож на обезьяну», «почему врачи убивают и калечат пациентов», «как улучшить работу ума», создателя «теории жизнеритмов»?
данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме. Каждый волен понимать состав по-своему.С данными тут еще хуже, чем с потоком управления. Ибо в одной из реализаций дуракона все данные — глобальные. Никакого описания данных нет. Никакого разграничения доступа нет. никакого контроля типов — нет.
Все потому, что дуракон замер на этапе советских реалий 1985 года. (ибо у буржуев уже в 68 году обозначился «кризис программного обеспечения», и они были вынуждены начать его решать тогда). С тех пор появились новые языки (а некоторые уже и умерли), IDE изменились до неузнаваемости, поменялись технологии (все эти асинхронности, например). а это осталось на уровне языка ПРОЛ-2.
И даже для описания workflow он убог.
Я могу в блок-схему (в том числе и оформленную по правилам дракона) вписать текст на русском языке. Это не сделает дракон русским языком.
Подробнее см. Википедию, страница ДРАКОН.Вспоминаем знаменитые Лемовские сепульки.
«СЕПУЛЬКАРИИ — устройства для сепуления (см.)».
«СЕПУЛЕНИЕ — занятие ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКИ».
Приведу пример реального использования языка ДРАКОН
для программирования в промышленной автоматике
(на газоперерабатывающем заводе, в сенсорном программируемом контроллере).
На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании "Сургутнефтегаз" и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Подробности по ссылке.
Разработчик шкафа управления установкой и программы управления ОКБ АМУР №3.
Участники обратили внимание на Степана Митькина @rykkinn
На Хабре можно прочитать его статью «Визуальное программирование на языке ДРАКОН». Степан объясняет, что программирование на гибридном языке происходит следующим образом:
Рисуем ДРАКОН-схему.
Внутрь икон помещаем небольшие кусочки кода на соответствующем языке программирования.
Программа-транслятор преобразует ДРАКОН-схему в текстовый файл с исходным кодом.
Этот текстовый файл включается в проект обычным образом. Генерацию кода из диаграмм на сегодняшний день поддерживают несколько редакторов. Примеры в данной статье сделаны в DRAKON Editor.
Все эти и смежные вопросы подробно рассматриваются.
Рейтинг статьи Степана Митькина +29.
В этой теме был высказан ряд критических замечаний, в частности, о невозможности описания данных. Например, @mixsture писал:
блок-схемы часто скрывают структуры данных, в которых все хранится. Действия в них видно, а вот что между ними передается, где и какое значение и чем перезапишется — не видно...
данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме. Каждый волен понимать состав по-своему.
Некоторые вопросы обсуждаются на официальном форуме языка ДРАКОН https://forum.drakon.su/
Предполагается, что ДРАКОН найдет применение для программирования микроконтроллеров и программируемых логических контроллеров (ПЛК).
Поэтому обсуждение ведется в разделе форума Проект «Язык Дракон–ПЛК» Алексея Муравицкого. Это большой раздел, в нем 31 тема.
Приглашаю вас посмотреть тему Отображение потока данных на Дракон схемах. В сообщении и следующем сообщении посмотрите на левую схему (левые схемы).
В левой дракон-схеме Алексей Муравицкий представил свой оригинальный вариант использования конструкции Силуэт для описания данных.
Алексей продемонстрировал, что язык ДРАКОН можно использовать не только для описания алгоритмов, но и для описания данных.
Алексей показал, что программировать на языке ДРАКОН можно не только на гибридных языках, но и на "чистом" ДРАКОНе.
Алексей Муравицкий показал это не только на лабораторном макете, но и создал действующую систему промышленной автоматики — шкаф управления Кустовой насосной станции КНС 59, который работает в Татарстане в поселке Азнакаево.
1. Кустовая Насосная Станция предназначена для Поддержания Пластового Давления в нефтяном пласте.
2. Всего на языке ДРАКОН запрограммировано и работает в Поселке Азнакаево (Татарстан) семь шкафов управления в семи КНС (кустовых насосных станций).
3. КНС укомплектованы Насосными агрегатами на базе мембранных насосов Gydra-CELL T-100 и сдвоенные Gydra-CELL G-15 партнера — Компании Pump Union и шкафами управления ОКБ АМУР №3 на базе контроллера и частотного преобразователя ОВЕН.
Второй вариант как-то проще, понятнее и компактнее.
свой оригинальный вариант использования конструкции Силуэт для описания данных.И чем этот «оригинальный вариант» лучше таблицы? ничем.
Он как-то связан с основной схемой? нет.
Он как-то помогает в рисовании основной схемы (ну, допустим, проверяет/подсказывает написание имени переменной)? нет.
Он как-то ограничивает использование данных в схеме (например, не позволяет писать во вход, читать выход)? Нет.
Он проверяет использование данных на соблюдение типов или диапазон? опять нет.
Хотя бы помогает понять, какими значениями инициализируются переменные? И это нет
тогда зачем оно?
Зачем вместо таблицы из 6 строк и 4 колонок этот «пейзаж»?
Дмитрий @nin-jin пишет: Второй вариант как-то проще, понятнее и компактнее.
Дмитрий, вы правы. Для профессиональных программистов, которые опираются на коллективный опыт и традиции многих десятилетий создания и эксплуатации программ (если считать с середины ХХ столетия, то опыт свыше семидесяти лет), то действительно получим, что ваш вариант проще, понятнее и компактнее.
Однако для людей со стороны (например, инженеров-электриков и специалистов по электронике, которые всю жизнь имеют дело со схемами (СхЭ — схема принципиальная электрическая, схема функциональная, схема логическая и т.д.) ситуация будет другой.
Зачастую у них нет денег, чтобы нанять программиста, и они начинают программировать сами, превращаясь в программистов-любителей (amateur programmers). Таких любителей очень много — миллионы.
@DvoiNic назвал их «умственно неполноценными программистами». Это не так. Они могут быть талантливыми инженерами, но они мыслят, опираясь на свой электронный и электротехнический опыт, то есть на многолетний опыт работы со схемами.
Поэтому при разработке программ, программисты-любители делают то, что профи-программистам кажется неправильным и неразумным, а именно — используют схемы в тех случаях, когда профи используют код и текст.
Я удивляюсь, как они вообще выживают, если даже рецепт из поваренной книги прочитать не могут.
Однако для людей со стороны (например, инженеров-электриков и специалистов по электронике, которые всю жизнь имеют дело со схемамиЭти люди и письма «схемами» пишут? Нет, наверное — они научились писать текстом. ровно так же можно научиться писать программы текстом. Более того, этому уже почти 40 лет учат в средних общеобразовательных школах. И в обязательном порядке более 40 лет- в ВУЗах на технических (инженерных) специальностях.
Зачастую у них нет денег, чтобы нанять программиста, и они начинают программировать сами, превращаясь в программистов-любителей (amateur programmers). Таких любителей очень много — миллионы.И эти любители прекрасно используют ардуино, например. Где программы — «в текстовом виде». И где «любители» наваяли гору проектов (порой не очень качественных, но достаточно объемных, чтоб задолбаться «рисовать»). Причем осваивают «текстовое программирование» для ардуино даже не инженеры, а дизайнеры, повара, швеи, врачи — люди вообще без технического бэкграунда…
Более того, если даже «программировать блок-схемами», то все равно «Внутрь икон помещаем небольшие кусочки кода на соответствующем языке программирования.». Т.е. язык программирования учить надо.
DvoiNic назвал их «умственно неполноценными программистами».Неправда. Умственно неполноценными программистами я назвал тех, кому трудно научиться, например, разбираться в логических условиях (напомню, учащиеся средней школы прекрасно это осваивают). Программирование — обычный навык, в нем нет ничего непостижимого для нормального человека. Точно такой же, как чтение и письмо.
Вы же не будете называть умственно полноценным человека, неспособного обучиться читать и писать? И если человек не умеет писать — странно называть его «писателем-любителем». А «человека, не умеющего программировать» вы почему-то называете «программистом-любителем».
Поэтому при разработке программ, программисты-любители делают то, что профи-программистам кажется неправильным и неразумным, а именно — используют схемы«Схемы» используют не «любители», а «неспособные научиться» (или не желающие). Либо извращенцы.
Еще раз объясняю, почему:
1. Для «программирования с помощью гибридного языка» нужно учить правила «улучшеных блок-схем» (все эти отличающиеся от ГОСТовских картинки-иконки, и т.п.)
2. Для «программирования с помощью гибридного языка» все равно нужно учить правила целевого языка программирования (т.е. синтаксис, типы данных, и т.п.)
3.Для рисования «блок-схемы» нужно какой-то еще один инструмент, кроме IDE.
4.Для получения из «блок-схемы на гибридном языке» текста на ЯП — часто нужен еще один инструмент.
5. инструмент рисования «блок-схем» не спасает от ошибок нарушения правил структурного программирования (в прошлой ветке приводили примеры).
6. при вписывании в иконки «блок-схем» текстов на ЯП инструмент никак не контролирует даже синтаксические ошибки, и уж тем более — не помогает, не подсказывает.
7.Для отладки (а отладка для малоопытных очень важна) все равно придется смотреть в текст (сгенерированный), а не на картинки. Мало того, что для этого все равно придется изучать ЯП (отладчика блок-схем принципиально нет), так еще и сгенерированный текст тошнотворен. по крайней мере у Тышова.
8.Все доступные нормальным людям удобства (начиная от удобной отправки любым способом текста программы коллеге «на посмотреть», до систем контроля версий) для «рисовальщиков блок-схем» просто недоступны.
9.Для «любителей», может, не столь важно, но поддержка/сопровождение/доработки/повторение другими/bus factor — это будет ад.
Отсюда простой вывод — для начинающих и «любителей» — излишнее усложнение, необходимость дополнительных затрат времени, не гарантирующее безошибочности (более того, убирающее возможность пользоваться возможностями IDE ).
При этом для «любителей» теряется возможность осознанного использования наработанного сообществами кода, теряется возможность консультаций в сообществе.
Для начинающих (т.е. тех, кто планирует в дальнейшем применять программирование более-менее регулярно) — это, дополнительно к перечисленному в предыдущем пункте, бесполезные затраты времени. Т.е. вместо рисования иконок полезнее, как показал выше пример с кодом Митькина, уделить время совершенствованию навыков.
Для более-менее опытных это не нужно, потому что текстом быстрее, удобнее, компактнее, понятнее, безошибочнее, стандартнее, и т.д.
Приведу мнение профи-программиста, преподавателя доцента из Астрахани, автора книги по С++ Валерия Лаптева. Вот что он сказал на Хабре здесь
Добавлю свои 5 копеек.Я - препод программистов. Учу уже порядка 30 лет...
... мы столкнулись с тем, что есть куча людей, которые не являются программистами (технологи всякие), но которым нужно по роду своей работы создавать алгоритмы в какой-нить системе управления на микропроцессорах.
Я лично разговаривал с таким человеком, который мне сказал так: схему я понимаю прекрасно, а вот код писать мне трудно, я там много ошибок сделаю. Которых на схеме - не сделаю.
И хотел, чтобы была такая среда, где бы он мог на Драконе сохдать схему алгоритма, и которая потом преобразовалась бы в код программы.
И мы у себя на кафедре пару студентов загрузили. Один писал и, надеюсь, в магистратуре допишет и внедрит, Drakon IDE для обучения. Там сделано преобразование дракон-схемы в код на JS.А второй студент пилит IDE для технологов - и там прямой интерпретатор схемы реализован.
Для разработки встроенных систем ДРАКОН весьма подходящий инструмент.
Как показывает жизнь, существует масса людей, которым НАДО разрабатывать алгоритмы, но они не являются программистами. Они хорошо видят картинку, но плохо читают текст.
Для таких людей ДРАКОН — то, что доктор прописал.
Вижу еще одну нишу для ДРАКОНА: построение ДРАКОН-схемы по коду.
Надо экспериментировать. Возможно, такой подход действительно снизит количество программмистских ошибок — на схеме будет сразу видно. Возможно, в некоторых случаях заменит отладку.Для начинающих программеров жесткая дисциплина ДРАКОНА — то, что нужно для правильной «постановки руки».
В общем, серебряной пули нет, но в своих нишах ДРАКОН был бы весьма полезен.
1. Именно, что ВАМ удобнее писать текст (как и мне).
А вот мы непосредственно общались с разработчиком, которому УДОБНЕЕ делать схему. А в код системы CodeSys происходит перевод автоматом.
И этот человек от нас хотел именно ИДЕ для дракон-схем. Тексты в дракон-схемах он тоже пишет, но сначала делает скелет алгоритма именно в виде схемы.
Для представления переменных использует силуэт, обозначая ветки: Входные, Выходные, Внутренние (переменные).
И все у него наглядно.И мы в Москве были еще в паре мест, где именно схемы хотели, а не код.
Вот и занялись, преследуя и свои цели тоже.
Ибо сейчас в вуз приходят люди, которые об алгоритмизации понятия не имеют.
А учить надо. Блок-схемы все рисуют самым разным образом. Один студент рисовал вложенные IF по-арабски — справа налево… :)))))))
А мы как раз и сделали текстовое представление дракон-схемы. Можно ее написать в Блокноте, и выполнить.
Но нашему заказчику текст не нужен. Ему нужен именно чертеж. Он сам умеет писать программы на бейсике, но не пишет. А делает дракон — схемы в редакторе Тышова.
Так ему удобнее и понятнее. Поэтому ваше предпочтение текста — это ваше личное предпочтение.
Другим людям предпочтительнее видеть чертежи/схемы.
3. Насчет писать/рисовать. Наши наблюдения показывают, что для разных людей понятие удобства создавать алгоритмы – очень разное. Замечу, что для программистов удобнее писать текст/код.
Я сам программист со стажем более 45 лет, поэтому говорю от первого лица. Но оказывается, существует множество людей, которым надо алгоритмы создавать, но они НЕ являются программистами.
Они – инженеры-технологи. И им гораздо удобнее создавать и читать чертежи/схемы. Я об этом сказал в докладе на конференции День Оберона – 2019 в Орле.
Вот ссылка: www.youtube.com/watch?v=nGvpO51gBRI
Эти люди создают управляющие комплексы различного рода с микропроцессорами. И им надо создавать алгоритмы для этих микропроцессоров.
Они НЕ программисты ни по образованию, ни по призванию. Оказывается, для подобных разработок гораздо удобнее использовать строгий формализованный графический язык типа Дракона, а не текст/код на обычном языке программирования.
4. В Вооруженных Силах подавляющее большинство компьютерных систем – это бортовые системы. Надежность для подобных систем – абсолютное требование. Содержать вместе с основной армией еще и армию высококвалифицированных программистов – сильно накладно будет. Программированию обучать долго и получается не у всех. А делать алгоритмы на Драконе – это могут ВСЕ.
При чем здесь программирование мышью?
Вообще все действия по созданию схемы алгоритмов можно делать клавиатурой. Для этого есть горячие клавиши.
Тем более, что заготовку начальную тоже можно делать сразу.
Вопрос в реализации редактора.
Проблема — в мышлении создателя алгоритмов.
Как программист могу сказать, что писать словами — это просто привычка с одной стороны, и предрасположенность с другой. Мы опрашивали студентов. Одни говорят, что писать псевдокод удобнее, другие — что рисовать схему понятнее.
Есть и такие, которым пофигу.И опять же, мы не просто так за Дракон взялись. Есть в Москве люди, которые даже при отсутствии полноценной ИДЕ применяют Дракон (вполне успешно) именно для разработки необходимых алгоритмов.
Поэтому мои слова выше не на пустом месте сказаны, а исходя из встреч с реальными людьми.
Они хорошо видят картинку, но плохо читают текст.
Читать учат в начальной школе. Если вместо того, чтобы учиться читать и писать люди картинки за гаражами разглядывали, то их дальше должности дворника пускать нельзя.
Возможно, такой подход действительно снизит количество программмистских ошибок — на схеме будет сразу видно.
Для этого давно придуман статический анализ. Что такого может показать блок-схема, что не обнаружит статанализ?
А делать алгоритмы на Драконе – это могут ВСЕ.
«Делать алгоритмы» могут не только лишь все, для этого нужны специфичные знания, хоть те же базовые алгоритмы, и долгая практика. Иначе будет решето с неучтёнными граничными случаями и экспоненциальной сложностью.
Содержать вместе с основной армией еще и армию высококвалифицированных программистов – сильно накладно будет.
Перефразируя, «Народ, который не желает кормить своих программистов, будет кормить чужих».
@Rsa97 IMHO, до полноценного языка дракон сильно недотягивает. Максимум его можно назвать стайлгайдом для блок-схем.
Если вы хотите называть ДРАКОН стайлгайдом, называйте.
Но в научной и учебной литературе принят термин "язык ДРАКОН".
Это началось в 1995 году, когда в журнале «Программирование» была опубликована статья:
Паронджанов В.Д. Графический синтаксис языка ДРАКОН // Программирование, 1995, N3. — С. 45–62.
В 1996 году Государственный комитет Российской Федерации по высшему образованию включил изучение языка ДРАКОН в программу курса «Информатика» для направлений:
510000 — Естественные науки и математика
540000 — Образование
550000 — Технические науки
560000 — Сельскохозяйственные науки
В официальном документе Госкомвуза "Примерная программа дисциплины информатика" 1996 года имеется раздел, посвященный языку ДРАКОН и использующий его понятийный аппарат.
«Примерная программа дисциплины „Информатика“» одобрена Президиумом совета по информатике Госкомвуза.
Председатель Президиума академик РАН Юрий Журавлев является руководителем Секции прикладной математики и информатики Отделения математических наук РАН, а также заместителем Академика-секретаря Отделения математических наук РАН
Гугл на запрос "стайлгайд ДРАКОН" дает 0 ответов.
А на запрос "язык ДРАКОН" Гугл отвечает:
Результатов: примерно 5 560 (0,36 сек.)
На запрос "DRAKON language" Гугл отвечает:
Результатов: примерно 746 (0,24 сек.)
В 1996 году Государственный комитет Российской Федерации по высшему образованию включил изучение языка ДРАКОН в программу курса
Может он что-то куда-то и включил, но Pascal, Lisp, Prolog, C++, ассемблер в ВУЗах в начале нулевых были, а вот никаких Драконов не было.
Хотя, вру.
Был дракон на обложке известной книги Ахо — Сети — Ульмана, но она не про блок-схемы.
Может он что-то куда-то и включил, но Pascal, Lisp, Prolog, C++, ассемблер в ВУЗах в начале нулевых были, а вот никаких Драконов не было.
Вы совершенно правы. Это очень инерционный процесс. Результаты запаздывают, иной раз на годы. Но сейчас ситуация улучшается и язык ДРАКОН начинают преподавать. Вот примеры здесь
Калиногорский Н. А. Автоматизация процесса разработки алгоритмов управления в интегрированной среде Дракон 2007-2010: Методические указания / Сибирский государственный индустриальный университет — Новокузнецк: Изд. центр СибГИУ, 2013. — 50 с.
Предназначены для магистров, обучающихся по направлению подготовки: 140400.68 «Электроэнергетика и электротехника», профили подготовки «Электроприводы и системы управления электроприводов», «Автоматизированные электромеханические комплексы и системы»
Российский экономический университет имени Г.В. Плеханова.
МОСКОВСКИЙ ПРИБОРОСТРОИТЕЛЬНЫЙ ТЕХНИКУМ. РАБОЧАЯ ПРОГРАММА ОП.08 Теория алгоритмов Специальность: 09.02.03 Программирование в компьютерных системах
Кирилл Богатов @Rainvention
Кирилл, желательно установить связь и обменяться сообщениями. Мой имейл vdp2007@bk.ru
Лабиринты из линий: превращаем сложный сценарий в понятную схему на языке ДРАКОН