roboforum.ru

Технический форум по робототехнике.

Язык программирования ДРАКОН

Re: Язык программирования ДРАКОН

setar » 16 апр 2014, 16:09

Есть разные методики контроля от зацикливаний.
рекомендация не применять goto была введена в объектных языках именно как один из вариантов такого контроля.
здесь другие методики - через запрет прямого перехода между вертикальными связками.

Re: Язык программирования ДРАКОН

hudbrog » 16 апр 2014, 16:45

Да не, я понимаю что само по себе goto не является злом, да и все наши любимые системы ветвления кода через синтаксические конструкции все равно в результате становятся jmp/je/jz и т.п.
Но как-то.. отвык =) Но посмотрю еще в его сторону чуток, да.

Re: Язык программирования ДРАКОН

Madf » 17 апр 2014, 12:51

Поглядел первый пример видео про замок, чот рутины до фига, вроде описываем алгоритм, но всё в итоге сводится к унылой настройке/совмещения аппаратной части с программой/кодом.
Т.е. вместо того, как обычно/привычно всё решается за 1 раз (в коде), тут нам предлагается это всё распихивать по полочкам. Т.е. быстро проект не создать и профилей готовых нет под разные камни. Где-то видел программы, в которых красиво и понятно упрощен конфигурирования железа через визуальную систему (прямо вид МК, с описанием ножек, что куда подключено), а дальше в коде уже используешь готовые метки...

Re: Язык программирования ДРАКОН

setar » 17 апр 2014, 14:29

Безусловно визуальный программатор контроллеров всегда будет удобнее универсальной системы.
Другое дело что возможно (это мне пока предстоит изучить) можно применять профили для разных задач, и это сделает разработку более быстрой.

Re: Язык программирования ДРАКОН

avr123.nm.ru » 17 апр 2014, 16:46

Madf писал(а):Где-то видел программы, в которых красиво и понятно упрощен конфигурирования железа через визуальную систему (прямо вид МК, с описанием ножек, что куда подключено), а дальше в коде уже используешь готовые метки...
Dave 3 от инфениона и еще FlowCode

Re: Язык программирования ДРАКОН

daner » 01 май 2014, 00:42

несколько раз приходилось заниматься различными системами визуализации программирования (по разным принципам : потоки данных, потоки действий, потоки событий и т.д.)
и в начале, все выглядит очень оптимистично. Получается симпатичный редактор, все очень даже понятно, даже не для программиста. В общем красота.
Пока не начинается какой-то серьезный проект с использованием этого самого языка.

1. И получается, что те, кто способен понять (а тем более написать) алгоритм, как минимум не имеют проблем и с псевдокодом, а то и в 90% знают какой-то язык.
Остальные, что-то сложнее нескольких последовательностей с парой, тройкой ветвлений, с трудом осиливают.

2. Вся красота рисованной схемы, перестает быть красивой, после полусотни блоков. Если блоки сворачивать, делать в виде ссылок и т.д. теряется наглядность, если разворачивать, то теряешься ты сам.

Вот и выходит, что если тоже самое, написать на псевдокоде (т.е. без "мусора" синтаксических заморочек языка), то с использованием функций и прочих именованных блоков (когда код становиться размером с десяток команд) наглядность, практически ничем не уступает графическому варианту. А если приходиться говорить о большом объеме кода, то и программы в 100 а то и 200 строк, читаются без больших проблем и ориентироваться в этом на много проще, чем в рисунке.

Короче, тоже самое что и обычная книга по сравнению с комиксами. Конечно картинка может быть очень выразительной, но в конце концов, представляете себе "дословный" комикс "Война и Мир" или "Этика" Спинозы.

Вот и получается, что в конце, я быль чуть ли не единственным, кто вносил существенные изменения в эти рисунки. Остальные либо делали только наброски (и боялись, что-то менять в конечной схеме), либо занимались удалением из основной схемы, ненужных частей, для создания тестовых схемок.

А я в конце устав, от этих рисунков, писал компилятор (из графики в текст и обратно), что бы можно было со всем этим работать через какой-нибудь текстовый сктрипт.

Игрушки это все, не более.

Re: Язык программирования ДРАКОН

Madf » 01 май 2014, 10:39

Надо было делать на оборот, имеется код, IDE его анализирует и выводит графическое представление (в блоках), дальше хочешь пиши код, а хочешь смотри на блок схему и где видишь проблему, то кликаешь в нужный блок - раскрывается та часть кода, которая к нему относится. В общем всё должно быть единым. Отображение блоков должна выглядеть как сейчас карты (при малом масштабе - одна картина, при приближении - более детальная).

Re: Язык программирования ДРАКОН

daner » 02 май 2014, 10:34

Madf писал(а):Надо было делать на оборот, имеется код, IDE его анализирует и выводит графическое представление (в блоках), дальше хочешь пиши код, а хочешь смотри на блок схему и где видишь проблему, то кликаешь в нужный блок - раскрывается та часть кода, которая к нему относится. В общем всё должно быть единым. Отображение блоков должна выглядеть как сейчас карты (при малом масштабе - одна картина, при приближении - более детальная).

В последнем нашем проекте примерно к этому и пришли. Т.е. пишем на простом языке, а после анализируем исходники и рисуем блоки.
Тут вопрос не в самой графике ( если много деталей выкинуть, то жить можно и наглядность не теряется ), а редактировании. Для редактирования (особенно, если полагаться только на графику) нужно много деталей и всего такого, что и засоряет все это дело.

С картами вы тоже совершенно правы. Я тоже пытаюсь в этом направлении думать и делать, вот только не для любого графа это подойдет.
Вот скажем для иерархий по смыслу, подойдет, а для иерархий по каким-то другим признакам не очень. Ну например, для иерархической FSM, легко можно скрывать внутренние машины, а вот для ... ну скажем деревьев поведений : мы попробовали делать тоже самое для веток, но это совершенно портило обще представление, только немного помогло ориентироваться и то, только когда скрытие перевели в ручной режим.

Re: Язык программирования ДРАКОН

Madf » 03 май 2014, 09:17

daner писал(а):С картами вы тоже совершенно правы. Я тоже пытаюсь в этом направлении думать и делать, вот только не для любого графа это подойдет.
Вот скажем для иерархий по смыслу, подойдет, а для иерархий по каким-то другим признакам не очень. Ну например, для иерархической FSM, легко можно скрывать внутренние машины, а вот для ... ну скажем деревьев поведений : мы попробовали делать тоже самое для веток, но это совершенно портило обще представление, только немного помогло ориентироваться и то, только когда скрытие перевели в ручной режим.

Всё зависит от представления и как выводить эти ветки, вот например как сейчас визуализируют:



Такое рассматривать как "карту" - не сложно.

Re: Язык программирования ДРАКОН

daner » 03 май 2014, 10:44

Вот вы как раз отлично проилюстрировали мои слова.
Например тот граф который в ролике отлично подашел бы для отображения статистических данных. Т.е. вам достаточно что вы в каком-то месте видите большую кучу чего-то.
Для деревьев решений это бесполезно. Это как популярные, но на мой взгляд совершенно бесталковые карты документов. Так сказать текст с высоты птичьего полета. Если этот текст ты сам писал, то еще есть надежда что это чем-то может помочь, а для другого пустая информация.
В программировании увеличивать надо как-то по-другому т.е. фонт должен оставаться неизменным. Хм... а это наводит на мысли...

Re: Язык программирования ДРАКОН

Smitt&Wesson » 21 авг 2014, 11:34

hudbrog писал(а):Я сначала хотел положительно отнестись к этому, но увидев "if(a == b) goto :L20", видимо, не смогу

И это не единственный его косяк.
Ща надыбал в Драконе две несуразицы.
1. У меня по брейку (break) прога должна выходить из цикла, а он ветку не переносит за пределы цикла. Блин, косяк.
Косяк Дракона1.jpg
Косяк Дракона1.jpg (90.87 КиБ) Просмотров: 3651

2. Ветвление идёт только по правой стороне Ифа (картинка внизу)
Косяк Дракона.jpg

Начинаю подозреват, что автор, мягко говоря 3,14здит, что на этом ракеты летают.
Блин, начал разочаровываться.

Re: Язык программирования ДРАКОН

Sledo » 01 дек 2015, 18:48

Надо бы подредактировать первый пост с "оптимистического и чего то хорошего", "в попробуйте, может понравится". Визуальное программирование не для создания серьезных проектов, а для того, что бы показать что написал программист человеку далекому от кода. Вот пример - не так давно, в качестве хобби, взялся за конструктор миссий для игры Arma, как платформу для отработки поведения ИИ. Первый же скрипт вышел на почти 1000 строк местного кода, 4 функции, и 5 "подфункций", в котором есть три стороны для противников, каждая из которых может быть отключена, для каждой из которых формируются места дислокации в количестве n. Эти места дислокации задает пользователь в виде [["City_", 0, 59]]; где цифрами указывается диапазон мест, из которых надо случайным образом выбрать указанное пользователем количество мест дислокации, исключить повторения названий, исключить возможные ошибки синтаксиса, сформировать полное название мест дислокации ("City_0" например), проверить на соответствие указанных пользователем количества мест дислокации, к указанному диапазону, и если диапазон меньше, то пропорционально ограничить количество мест дислокаций для каждой стороны, исключить повторения одних и тех же мест дислокаций для каждого противника. До кучи надо будет туда в будущем добавить проверку и сортировку мест дислокации по расстояниям для каждого противника, как друг от друга, так и для самих мест и добавить случайную выборку места не привязанную к определенным местам. И все это умноженное на 3, для каждой стороны противника.
Стоит ли говорить что нужно сделать 3 логики, которые пересекаются, разветвляются и снова пересекаются? В визуальном коде, подобное будет выглядеть как картина добротного абстракциониста, хотя конечно, и не лишено смысла. Какой смысл его использовать, если мне намного проще отследить логику построчно и последовательно, четко видя какие значения куда передаются и вычисляются? Зачем мне рассматривать картинку, если я могу прочитать текст и точно понять, что автор хотел сказать? А вот для человека не подготовленного, блок-схемы могут выглядеть весьма наглядно. Однако он все равно не уловит особенностей кода, поскольку у него нет подготовки - почему сделано именно так, а не иначе.
В таких проектах где работает большое количество людей, имеющих знания не связанных с написанием программ, однако обязанных их контролировать, подобная визуализация просто жизненно необходима, именно по этой причине ДРАКОН и был разработан. Но для не "инженерно механических" проектов, он бесполезен.

Re: Язык программирования ДРАКОН

Smitt&Wesson » 19 фев 2016, 08:26

hudbrog писал(а):Я сначала хотел положительно отнестись к этому, но увидев "if(a == b) goto :L20", видимо, не смогу

Как-то разбирался с Драконом. Нашел две несуразицы.
У меня по брейку (break) прога должна выходить из цикла, а он ветку не переносит за пределы цикла. Блин, косяк.
И ещё косяк. Ветвление идёт только по правой стороне Ифа (картинка внизу)
Сомневаюсь, что на этом ракеты летают.
Кружочками показано как делает Дракон, а стрелочками, как должно быть в алгоритме.
Вложения
Косяк Дракона1.jpg
Косяк Дракона1.jpg (90.87 КиБ) Просмотров: 3051
Косяк Дракона.jpg

Re: Язык программирования ДРАКОН

Madf » 19 фев 2016, 12:37

Может просто надо мыслить по драконовски...)

Re: Язык программирования ДРАКОН

Smitt&Wesson » 20 фев 2016, 09:42

Madf писал(а):Может просто надо мыслить по драконовски...)

Простите, а это как? Как по-драконовски, можно принудительно выйти из цикла? И как обойти блок?


cron
Rambler\'s Top100 Mail.ru counter