roboforum.ru

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

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

_________________
У меня в голове опилки и длинные слова меня только огорчают.

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

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

Dave 3 от инфениона и еще FlowCode

_________________
Читайте !

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

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

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

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

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

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

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

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

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

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

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

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



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

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

И это не единственный его косяк.
Ща надыбал в Драконе две несуразицы.
1. У меня по брейку (break) прога должна выходить из цикла, а он ветку не переносит за пределы цикла. Блин, косяк.
2. Ветвление идёт только по правой стороне Ифа (картинка внизу)

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

_________________
Краткость - сестра таланта.

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

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

_________________
Краткость - сестра таланта.

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

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

_________________
Краткость - сестра таланта.