roboforum.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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