Дракон - визуальный алгоритмический язык программирования и моделирования

Приветствую

Дракон - https://ru.wikipedia.org/wiki/... 0%9E%D0%9D

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

Вот что мне удалось найти:
Неклассическая теория алгоритмов и язык ДРАКОН

По теме микроконтроллеров:
Обсуждение ИС Дракон
ИС Дракон. Вопрос - ответ.
Приручить Дракона
Графический язык ДРАКОН для программирования микроконтроллеров
Алгоритм работы датчика температуры и влажности DHT11
AVR Dragon и PDI интерфейс
Дракон на Андроиде

...если что пропустил, извините, что google накопал.

Кроме того я читал на других форумах, в частности специализирующихся на Драконе, так что кое какие представления имею, но думаю ситуация такова, что специалистам он уже не нужен а новичкам, для кого он и создавался, создать нормальную программу не по силам. Конечно есть три более менее рабочие версии Дракона, да и тут я нашел ветку с драконоподобной средой разработки - Легкий путь к созданию блок-схем: Diagram Designer но все же хотелось бы обсудить причины по которым данная идея так и не получила широкого распространения.

Так-же хотелось бы все-же обсудить саму идею и поделиться своими соображениями почему верхи не хотят а низы не могут...
Я предлагаю всем желающим тезисно высказаться что именно им не нравится и что нравится в Драконе, плюс хотелось бы услышать идеи как все же вдохнуть жизнь в Дракона.
Просьба излагать свои мысли понятно для всех.

Добавлено через 24 минуты
Изложу некоторые свои соображения по поводу визуального представления алгоритмов.
Конечно это не ново но хочу подытожить.

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

Достоинства блочного программирования (имхо):

1. Быстрое восприятие информации и ориентирование в блок схеме программы.
2. Легкое понимание алгоритма для тех, кто с ними знаком вообще, но не знаком с программированием в частности.
3. Блочное трансформирование алгоритма, что уменьшает вероятность ошибок части кода при изменении программы так как сам код внутри блока скрыт и не может быть изменён случайно.
4. Экономия времени при изучении блок схем чужих программ или их фрагментов.
5. Возможность закрепления за каждым блоком фрагментов кода программ из разных языков программирования, да и не только кода но и любых самостоятельно заданных процедур или других данных включая специализированные команды обращения к аппаратной части. (Возможно поэтому он оказался наиболее удобен для программирования пикконтроллеров.)

Возможно Вы назовете еще некоторые существенные для вас достоинства, но я перейду к недостаткам.

Добавлено через 29 минут
Недостатки вообще и существующих реализаций в частности (имхо):

1. Отсутствие возможности автоматического импорта программного кода из других языков программирования в формат блок схем. Это является на мой взгляд самым основным недостатком из-за которого не развивается Дракон. Данный недостаток свойственен всем существующим версиям программ (имхо - возможно я ошибаюсь?).
Этот же фактор затрудняет отладку программ созданных в Драконе с помощью других программ.
2. Усложненный просмотр фрагментов кода и отсутствие подсветки синтаксиса, это то-же свойственно практически всем существующим версиям. Да, посмотреть код конечно можно, иначе было бы невозможным вобще составление программного кода, только алгоритма, но реализация на мой взгляд неудобна. Подсветки синтаксиса я не видел ни у кого, возможно ошибаюсь?
3. Компиляция конечной программы и отладка, тут тоже пусто, в лучшем случае есть простая проверка на отсутствие закрывающих тегов или явно отсутствующих частей кода.
4. Работа с VCL то-же нигде не реализована, а это основная проблема уже для новичков.
5. Интеграция в другие программы, например то-же Делфи, что то-же могло бы быть полезно для начинающих.
6. Реализация построения сложных блок схем перечеркивает изначальное удобство в визуальном восприятии, так как на некотором этапе мишура из линий и икон становится не разборчивой а попытки навести порядок приводят к еще большему хаосу. Некоторые решения (костыли) были придуманы, а именно запрет на пересечение лиан (линий соединяющих блоки), вынесение фрагментов блок схем в отдельные модули, уменьшение количества текстовой информации на теле иконок и тому подобное. Данные действия приводят к тому, что пользователь вынужден ориентироваться не в основном окне алгоритма а то и дело перескакивать по под-окнам, что перечеркивает все 4 первых пункта достоинств Дракона.
7. Увеличивается время на построение программы за щет того, что необходимо изучить и сам Дракон, и конечный язык программирования, пусть и менее детально чем это требовалось бы при программировании без вспомогательных средств визуализации.

Это возможно то-же не все, но на что хотелось бы обратить внимание в первую очередь, дополните если что.

Добавлено через 50 минут
Пути устранения недостатков, опять же по моему скромному мнению:

1. Вероятно подход к визуальному представлению блок-схем стоит изменить.

а) Исключить возможность перетаскивания блоков вручную. Для этого нужно отойти от существующих гостов на построение подобных схем как устаревших полностью или частично. Под частичным я понимаю сохранение самих иконок для быстрого распознавания блоков но они не должны быть заодно и телом блока. Сама структура блоков должна быть более упорядоченная и выстраиваться самой программой по строгим законам. Варианты таких структур я приведу позже.
Это как раз одна из тем обсуждения.
б) Конечный пользователь должен иметь возможность самостоятельно создавать как сами блоки так и назначать соответствующий программный код каждому блоку. Хотя конечно изначально программа должна содержать базовые наборы как блоков так и возможность добавлять нужный программный код. Думаю нормальным будет если пользователь будет иметь возможность опционально подгружать нужный программный код по желанию и дополнять его своими наборами фрагментов кода но при этом основной пакет кода будет защищен от редактирования. Возможны варианты.
в) Возможность автоматического сопоставления импортируемого кода с имеющимися заготовками для данного конкретного языка и заготовками самого пользователя и представление результата в виде графической блок-схемы Дракон. Само такое графическое представление будет возможным и удобным только при выполнения пункта а, а именно наличия механизма размещения блоков автоматически и строго по определенным законам. При этом не распознанные фрагменты можно то-же представлять графически в виде не распознанных блоков с возможностью их дальнейшей ручной идентификации.
г) Отображение содержимого (фрагмента кода программы) блока в постоянно присутствующем окне с кодом всей программы и разумеется с поиском и подсветкой синтаксиса. Сам механизм такой реализации придуман (то-же FireBug для Mozilla или встроенный анализатор кода Хромоногого), то есть при клике или наведении мыши на блок - выделение кода в теле программы соответствующего данному блоку. При этом для редактирования самого пользовательского кода фрагмента или его комментирования должно вызываться отдельное окно. Таким образом будет возможным одновременно видеть и код самой основной программы и блок схему.
д) Перемещение по лианам (линиям соединения блоков) по клику по лиане не требуется, для быстрого перемещения по линиям достаточно клика по точкам входа в два соединяемых блока, в конечном итоге нужно начало и конец лианы а не где и как она петляет. Кроме того случайный клик по блок схеме в токе прохождения другой лианы приведет к перемещению к не интересующему блоку.
е) При наличии постоянно присутствующего она программы желательно вести проверку кода на лету, насколько это возможно и реализовано в других редакторах кода.
ж) Максимально освободить основное окно программы от лишних элементов управления а управление реализовать через контекстное меню.
з) Реализация обмена данными с внешними аппаратными устройствами, такими как микроконтроллеры например через блоки управления драйверами реализуемыми самим пользователем а не жестко заданными программой. Очевидно в таком случае нужно создать наборы заготовок таких блоков.
и) Ну и само собой возможность распечатки блок схем в бумажном виде для изучения без компьютера.

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

0

Блок схемы Дракона некоим образом не могут улучшить понимание алгоритма, потому что основаны на ошибочной теории структурного программирования, которая не может считаться научным подходом ибо не соответствует полноте по Тьюрингу. Эта теория возникла на западе, и продвигалась Дейкстрой, Виртом и др. Однако следуя этой теории невозможно создать ЛЮБОЙ алгоритм. У нас в России, в университете ИТМО, профессором Шалыто была создана своя теория автоматного программирования, которая наголову разбивает всю ложь структурщины. Тут можно ознаомится с этим. Под автоматы заложена строгая математическая база и за ними, без сомнения - будущее. Попытки как-то облагородить древнюю теорию структурного программирования путём применения визульного предсталения алгоритма ошибочными средствами, типа диаграмм Дракона, обречено на провал. Почему? Потому что алгоритм состоит из совершенно других сущностей, которые не имеют к блокам блок-схем ни малейшего отношения.

0

Сообщение от CoderHuligan на ошибочной теории структурного программирования, которая не может считаться научным подходом ибо не соответствует полноте по Тьюрингу

Можете привести цитату из работы, из которой Вы почерпнули эту мысль? ИМХО "структурное программирование" и "полнота по Тьюрингу" - ортогональные понятия.

Сообщение от CoderHuligan ледуя этой теории невозможно создать ЛЮБОЙ алгоритм

Обоснуйте.

Добавлено через 4 минуты

Сообщение от sysghost понял что тут его особо не жалуют

ИМХО блок-схемы вообще мало полезны. Грамотно написанный код гораздо проще понять, чем блок-схему.
Кроме того, текст гораздо проще копировать, комментировать и т.п.

0

Сообщение от Shamil1 Можете привести цитату из работы, из которой Вы почерпнули эту мысль?

К сожалению не могу, сейчас обьясню почему.
Полноту по Тьюрингу обычно соотносят с языками программирования, а не со стилями кодинга или парадигмами. Это первое.
Второе.
Структурное программирование, которое, так или иначе используется до сих пор и повсеместно, является особой парадигмой, а не языком. Другое дело, что множество языков было создано с учётом этой парадигмы.
В соответствии с этой парадигмой, программа должна строится линейным образом, без прыжков в стороны, и соответственно читаться. Однако, такой стиль, не позволяет точно описывать алгоритм решения задачи! Задача может быть решена ТОЛЬКО применяя определённые всем известные костыли! Без этих костылей структурное програмирование бессильно! А если есть костыли, значит данная парадигма в принципе не способна к ТОЧНОМУ описанию проблемы..
А знаете почему? Потому, что не учла особенностей , которые составляют ту самую машину Тьюринга. Самая главная её особенность в том, что она вводит понятие "состояние" обьекта управления. Причём вводит его явно, как совершенно особую сущность, которая применяется для описания некоего формального алгоритма. Однако в структурном программировании такое понятие отсутствует! Его нет! Там есть 1) циклы 2) ветвления 3) последовательное выполнение неких действий, и - всё! Больше там ничего нет! А где же состояние?..

Сообщение от Shamil1 Обоснуйте.

Я уже пытался в теме про goto предлагать решить простую задачку, но никто не смог или не захотел..
Ну. вот ещё более простой пример. Выход из вложенных циклов. По теории структурного програмирования из блока может быть лишь один выход и один вход. Если из цикла есть нескоько выходов, то таковое явление не может считаться структурным подходом. Однако люди сплошь нарушают его применяя банальное goto из вложенных циклов. Это даже рекомендуется делать(особый случай применения goto). Люди и делают забыв про Дейкстру.)))

0

0

Извиняюсь что долго не отвечал, но вероятно к лучшему, я понял что некоторые идеи были сыроваты но пока не все, есть над чем подумать.

Сообщение от Shamil1 ИМХО блок-схемы вообще мало полезны. Грамотно написанный код гораздо проще понять, чем блок-схему. Кроме того, текст гораздо проще копировать, комментировать и т.п.

Касаемо того, что текст программы проще копировать и комментировать, это важное дополнение, жаль не могу теперь добавить в список недостатков. Насчет комментирования, я так понимаю что имелось ввиду не само комментирование а его присутствие непосредственно возле текста программы, потому как комментирование есть в существующих версиях и вариантов реализации видится не мало.

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

Добавлено через 27 минут

Сообщение от CoderHuligan Полноту по Тьюрингу обычно соотносят с языками программирования, а не со стилями кодинга или парадигмами. Это первое. Второе. Структурное программирование, которое, так или иначе используется до сих пор и повсеместно, является особой парадигмой, а не языком. Другое дело, что множество языков было создано с учётом этой парадигмы. В соответствии с этой парадигмой, программа должна строится линейным образом, без прыжков в стороны, и соответственно читаться. Однако, такой стиль, не позволяет точно описывать алгоритм решения задачи! Задача может быть решена ТОЛЬКО применяя определённые всем известные костыли! Без этих костылей структурное програмирование бессильно! А если есть костыли, значит данная парадигма в принципе не способна к ТОЧНОМУ описанию проблемы..

Хотя и слишком общо, попытаюсь подытожить.
Итак:
1. Программирование ветвится, парадигма требует линейности решения задачи.
2. Несмотря на это множество языков использует парадигму линейности (если не все, то какие не используют?).
3. По Тьюрингу структурное программирование на базе парадигмы линейности не может быть полным.

И если я все выше правильно понял, то по Тьрингу большинство языков программирования не могут быть полными?
Можно ли как то более точно все же описать проблему.

Сообщение от CoderHuligan А знаете почему? Потому, что не учла особенностей , которые составляют ту самую машину Тьюринга. Самая главная её особенность в том, что она вводит понятие "состояние" обьекта управления. Причём вводит его явно, как совершенно особую сущность, которая применяется для описания некоего формального алгоритма. Однако в структурном программировании такое понятие отсутствует! Его нет! Там есть 1) циклы 2) ветвления 3) последовательное выполнение неких действий, и - всё! Больше там ничего нет! А где же состояние?..

Эм. Тут вообще ничего не понятно. Зачем программе знать в каком состоянии устройство на котором она выполняется, это проверяется перед её установкой и запуском?
Или это состояние внешних данных (например с датчиков)?
Я тут вообще не понял мысль, если устройство может выполнять программу, то зачем программе знать как оно его выполняет? Если это тайминги, то для этого делают резервные генераторы тактовых частот если требуется уверенность что контролируемые процессы будут выполняться точно вовремя и не собьются при сбое носителя программы.
Или Вы про параллельное выполнение программ на двух независимых устройствах, где одно контролирует другое?
Если честно, я не любитель гадать.

0

Сообщение от CoderHuligan Полноту по Тьюрингу обычно соотносят с языками программирования, а не со стилями кодинга или парадигмами. Это первое.

Поэтому я написал, что "структурное программирование" и "полнота по Тьюрингу" - ортогональные понятия.

Сообщение от CoderHuligan В соответствии с этой парадигмой, программа должна строится линейным образом, без прыжков в стороны, и соответственно читаться. Однако, такой стиль, не позволяет точно описывать алгоритм решения задачи!

"линейным образом" - неверно. Используются ветвление, циклы и подпрограммы.
"без прыжков в стороны" - верно, если под "прыжками" Вы подразумеваете goto.
"не позволяет точно описывать" - неверно. Но так как Ваше утверждение не аргументировано, то я не знаю, какие контраргументы приводить.

Сообщение от CoderHuligan Потому, что не учла особенностей , которые составляют ту самую машину Тьюринга. Самая главная её особенность в том, что она вводит понятие "состояние" обьекта управления.

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

Сообщение от CoderHuligan Я уже пытался в теме про goto предлагать решить простую задачку, но никто не смог или не захотел..

В чём заключалась задача?

Сообщение от CoderHuligan Выход из вложенных циклов.

Выход из вложенных циклов можно реализовать и без goto.

1

Сообщение от Evg Можешь привести пример в части "ТОЛЬКО"? Просто чтоб хоть понимать, о чём речь идёт

Для простых алгоритмов, школьного уровня можно ограничится структурным стилем. Чуть задачка посложнее без костылей никуда. Другое дело, что костыли стали считаться де факто составной частью структурного кодинга. Чтобы красные ушки не торчали..
Например блок "развилка" должен иметь лишь один вход и, заметьте: ОДИН выход. Так по правилам структурного программирования. Чтобы привести неструктурный алгоритм к структурному виду применяют так называемое "размножение блоков". А это увеличивает код программы. Хотя, в некоторых случаях позволяет легче проводить рефакторинг. К тому же сама по себе развилка не может иметь один выход.
Далее: блок "цикл" тоже должен иметь один вход и один выход. Чтобы выйти из цикла, особенно из вложенных циклов применяют костыли в виде флагов или в лучшем случае goto, при этом получая цикл со множеством выходов..
Структурное программирование не может жить без многочисленных "флагов". Флаг это типичный костыль, ибо без него трудно вообще что-то написать в этом стиле. При этом, даже сам Дейкстра в конце концов признался, что вместо множества флагов лучше бы иметь одну переменную, которая молгла бы принимать в себя все возможные СОСТОЯНИЯ потока программы. Дейкстра был умным малым, и по всей видимости осознал, что раньше ошибался... Но уже было поздно, ибо эти идеи были подхвачены создателями языков, и сейчас мы имеем то, что имеем.

Сообщение от sysghost Но все же хотелось бы услышать с какой непреодолимой проблемой можно столкнуться при визуальном моделировании алгоритмов.

Я не против визуального проектирования алгоритмов. Более того: за этим подходом будущее! Я против ложного подхода к проектированию алгоритмов. А драконовские схемы не учитывают состояния программы.

Сообщение от sysghost Зачем программе знать в каком состоянии устройство на котором она выполняется, это проверяется перед её установкой и запуском?

Программа и не должна знать в каком состоянии находится УСТРОЙСТВО на котором она работает. Программа должна знать состояние самой себя, если можно так выразиться.. Правда если часть этого устройства имеет какое-то отношение к программе в смысле логики, то естественно, что программа должна знать об этом.

Сообщение от sysghost Или Вы про параллельное выполнение программ на двух независимых устройствах, где одно контролирует другое? Если честно, я не любитель гадать.

Но вы задали кардинальный вопросы. Это похвально, ибо редко услышишь действительный интерес что-то понять из основ. Обычно люди сидят в своих лужах и думают что так и надо..
Паралелльность пока оставим в стороне. Попытаюсь обьяснить, как могу.
Приведу пример из книги Кернигана и Риччи "Язык программирования Си".
Там было приведено много решений задач в традиционном стиле, поэтому очень удобно оттолкнутся именно от них и показать на примере, в чём отличие структурного подхода без явного выделения состояний и автоматного с явным выделением. Если вы знакомы с языком си, а вы должны бы его знать, ибо он считается в мире эсперанто программирования, то легко поймёте смысл алгоритма. Вот задача подсчёта числа слов из водимой пользователем строки. Я изменил пользовательский ввод на статическую строку, оставив основной алгоритм в целости:

Тут как видно используются два флага IN И OUT. Флаги символизируют находимся ли мы в слове или вне его, чтобы затем вести подсчёт слов. И хотя переменная носит гордое имя state, однако она не выражает состояний программы, - она лишь содержит тот или иной флаг. Состояния программы продолжают быть скрытыми и даже не имеют своих имён.. Так пишут большинство людей, даже не задумываясь, что это абсолютно НЕПРАВИЛЬНЫЙ алгоритм, хотя и работающий правильно. Неправильный значит неэффективный, трудно формализуемый и подверженный потенциальным ошибкам. Он красиво смотрится на бумаге и его можно читать сверху вниз как книгу, что и добивались создатели структурной парадигмы.
Я переписал этот алгоритм в автоматном стиле при помощи goto переходов из одного состояния в другое. К слову сказать можно избавится от goto и применить здесь переключатель switch, однако goto это самый эффективный приём. Некоторые полагают, что множество операторов goto затрудняют чтение листингов программ. Но в автоматном подходе с явным выделением состояний понимание программы происходит на этапе чтения документации: визуальных диаграмм переходов из одно состояние в другое и схемы связей автомата. Поэтому чтение исходного кода не практикуется - оно просто не нужно.

Эта программа работает на 40-50% быстрее варианта Кернигана и Риччи - отцов основателей Unix и языка Си..
В отличие от первой программы, в моём варианте есть два совершенно САМОСТОЯТЕЛЬНЫХ блока состояний IN и OUT. Причём заметьте: в этих состояниях программа может находится продолжительное время, ничего не зная о других состояниях. В то время как в традиционном подходе первого варианта все состояния перемешаны с друг другом и не видны. Теперь задумайтесь: почему второй вариант быстрее первого почти в 2 раза?
И так с ЛЮБЫМИ программами, которые используют флаги костылей.
На второй вариант я могу написать документацию, а на первый - нет.

Сообщение от Shamil1 "состояние" и "полнота по Тьюрингу" ортогональны. Тьюринг-полный язык может не только не иметь "состояний", но и вообще не иметь переменных.

Не правильно. Не ортогональны, обьяснитесь. А одно целое.

Добавлено через 20 минут
Естественно, что возможен совершенно иной язык программирования, который бы явно учитывал такую сущность, как состояние и скрывал бы неприглядные переходы из одного состояния в другое. Он может быть даже текстовым или визуальным. Уверен, что в итоге к этому придёт индустрия, иначе и быть не может, ведь с истиной можно спорить долго, но от этого она не перестанет быть истиной.

0

Сообщение от CoderHuligan Не ортогональны, обьяснитесь.

ЯП может быть или не быть тьюринг-полным. ЯП может использовать и не использовать состояния. Итого 4 варианта, и все они возможны. Между этими двумя чертами языка нет никакой корреляции.
Мы не можем сказать "ЯП не использует состояния, значит он не тьюринг-полный" или "ЯП использует состояния, значит он тьюринг-полный".

Сообщение от CoderHuligan Тут как видно используются два флага IN И OUT.

Код плохой. Тут я с Вами согласен.

Сообщение от CoderHuligan В отличие от первой программы, в моём варианте есть два совершенно САМОСТОЯТЕЛЬНЫХ блока состояний IN и OUT.

Можно обойтись без состояний. Есть две задачи: пропустить пробелы и прочитать слово.
И никаких goto.

1

Сообщение от Shamil1 Мы не можем сказать "ЯП не использует состояния, значит он не тьюринг-полный" или "ЯП использует состояния, значит он тьюринг-полный".

Согласен.Однако, в почти в любом ЯП состояния конечно присутствуют, но они глубоко скрыты и явно, сознательно не используются.

Сообщение от Shamil1 Можно обойтись без состояний.

Это уже намного лучше. Я тоже использую подобную технику, когда нужно улучшить код в традиционном стиле. Однако будь алгоритм посложнее, то так просто не отделаешься. Даже в таком варианте состояния не видны, то есть у них нет имени. Где есть имя, есть и абстракция. А любой ЯП стремится к высокоуровневым абстракциям. Ещё Кнут писал, что если у метки есть осмысленное имя, то она представляет из себя чистую абстракцию. Метка может обозначать некий блок кода. Этот блок кода может представлять из себя целое состояние, а значит поддаётся формализации. У блоков структурного стиля отсутствуют имена - у циклов нет имён, значит они сами по себе лишены абстракции. Есть у функций, но это совсем другой "зверь".
От goto следует избавляться только тогда, когда ими пытаются подменить структурные конструкции. Тогда это действительно убожество. Если же goto применяется для переходов из одного явного состояния в другое, то goto оправдан. Именно здесь ему самое место, для этого он в сущности и предназначен..
Если у меня есть чётко выраженные состояния, например в коде выше их 3 - IN, OUT и K(конец), то я могу нарисовать диаграмму, в которой 3 прямоугольника будут состояниями, а связи-стрелки между ними - переходы. Над стрелками будут описаны условия и действия на переходах. Также я могу формализовать вход и выход автомата, создав таблицу входных переменных и выходных переменных(действий), и по этой документации судить об алгоритме. Без деления алгоритма на состояния, я этого сделать не могу в принципе. В этом случае программу приходится читать с исходного текста, а это очень и очень сложная вещь.

0

Сообщение от CoderHuligan У блоков структурного стиля отсутствуют имена - у циклов нет имён, значит они сами по себе лишены абстракции.

Блокам кода можно давать имена. Именованные блоки кода называются функциями. Хороший компилятор их заинлайнит (если это выгодно). Эти функции можно сделать локальными - определить внутри функции, в которой они используются.
Цикл в 90% случаев представляет из себя одну из стандартных абстракций - map или fold. Тогда можно использовать соответствующую библиотечную функцию, и код становится ещё более читаемым и более лаконичным.

0

Сообщение от Shamil1 Блокам кода можно давать имена. Именованные блоки кода называются функциями.

Так то оно так, только функции не могут заменить блоки состояний. Иначе может быть банальное исчерпание стека при продолжительной работе программы если код имеет петли, а он имеет петли практически всегда.
Поэтому функции отметаются сразу. Тут линейного блока не может заменить ничто.
Посмотрите на схему переходов, которую я набросал. Она часто встречается в автоматах, которые занимаются управлением технологическими процессами:

Состояний может быть больше чем 4, как в данном случае. Как здесь видно, каждое состояние связано переходами со всеми другими. Попробуйте создать в структурном стиле подобный алгоритм, причём без применения функций, так как функции быстро исчерпают стек.

0

Сообщение от CoderHuligan Иначе может быть банальное исчерпание стека при продолжительной работе программы если код имеет петли, а он имеет петли практически всегда.

Неправда. На практике такой проблемы вообще нет. А когда функции инлайнятся, то стек даже не используется.
И, как Вы могли обратить внимание, в моём варианте кода функции не вызывают одна другую, а вызываются последовательно в одной главной функции. Взаимные вызовы в данном случае были бы неправильным подходом, так как функция "пропустить пробелы" (строка 13) не должна знать о существовании функции "прочитать слово" (строка 18).

Сообщение от CoderHuligan Посмотрите на схему переходов, которую я набросал.

Я не программирую "состояниями", поэтому эта схема мне ни о чём не говорит. Уверен, что задачу можно решить без использования состояний.

0

Сообщение от CoderHuligan Поэтому функции отметаются сразу. Тут линейного блока не может заменить ничто. Посмотрите на схему переходов, которую я набросал. Она часто встречается в автоматах, которые занимаются управлением технологическими процессами: Дракон - визуальный алгоритмический язык программирования и моделирования Состояний может быть больше чем 4, как в данном случае. Как здесь видно, каждое состояние связано переходами со всеми другими. Попробуйте создать в структурном стиле подобный алгоритм, причём без применения функций, так как функции быстро исчерпают стек.

Я бы представил данную схему в таком виде как на рисунке, это обычные связи многие ко многим.
Это если нужно просто отобразить связи. Но ведь кроме этого нужно указать какие связи и в какой последовательности работают, а то и вовсе назначить каждой связи или их группам условия, когда они работают.
Очевидно что в таком случае вместо стрелок нужно добавить блоки которые будут это регулировать.
Блоки можно идентифицировать по номерам присваиваемым автоматически при создании нового блока или назначаемым для связки, если подходящий блок уже существует.

Что касаемо линий связи при отображении алгоритмов то я считаю что от них нужно избавляться, это не электрическая принципиальная схема и лазить по линиям двигая картинку нерационально и да-же вредно, так как легко можно запутаться.
В данном случае достаточно иметь точки входа и выхода при клике по которым будет осуществляться движение туда-обратно (это не GO TO а просто перемещение по агоритму) по линии связи.
Я в программировании не силен, так что ищу способ сделать инструмент который будет вроде Дракона где можно сразу обдумать сам алгоритм а затем применить его в конкретном случае.
Поэтому обдумываю возможно ли такое для сложных программ.
Кроме того очевидно, и этот спор я так понимаю о том-же, что для решения одной и той-же задачи можно применить целый ряд решений, и далеко не все они будут рациональны в плане построения кода программы, да и самого алгоритма.
Поэтому как раз и хотелось бы понять какие сложности в реализации блочного подхода в построении программ.

Миниатюры

 

0

Я тут заметил, что указанную выше схему можно значительно упростить.
Увы не могу поправить сообщение выше.

Миниатюры

 

0

Вот алгоритм опроса блоков по часовой и против часовой стрелок начиная с 1 блока, и один по диагонали.
Тут становится видно, что если например нужно опросить блоки попарно, например 1-2-1 или 1-4-1 то места для данного условия уже не найдется.
То-же будет если нужно опрашивать блоки хаотично.
Вижу два варианта решения проблемы.
1. Создать алгоритм прерывающий опросы по условию 1 и 2 и переходящий к условиям 4 и так далее для возврата из текущего блока в исходный.
2. Всё же применить матрицу выше (12 строк) и использовать её поля условий.

Кажется я понял о каком состоянии Вы говорите, логическом состоянии?

Миниатюры

 

0

Хотелось бы начать с простого.
Как можно узнать какое максимальное количество может быть входов и выходов у одного блока?
Я так понимаю больше всего входов у блока условия, это один вход и два (три?) выхода.
Обычно имеется два исхода на одно условие в одном таком блоке - да и нет.
Но ведь можно сделать и два условия в одном блоке с двумя вариантами да и одним нет.
Так можно уменьшить число блоков, но для простых условий один из выводов будет лишним.
Как оценить рационален ли второй вариант?
Разумеется можно так увеличивать число условий в блоке до бесконечности, но тогда в большинстве случаев лишние условия будут не востребованы а им все равно нудно будет прописывать логику поведения, если эта логика изначально будет устанавливаться как неактивная.
Ну и тут уже начинает нарушаться принцип элементароности блока, хоть и в пользу уменьшения количества их самих.
Если где информация чем руководствовались изначально при создании блоков алгоритма кроме элементароности?
Или это единственный и основной критерий?

Миниатюры

 

0

Сообщение от Shamil1 Уверен, что задачу можно решить без использования состояний.

А я не уверен, что это возможно в классике.
Усложним задачу: добавим переход в собственное состояние. Всего лишь одно для простоты, но в каждом отдельном состоянии.
Я могу эту задачу решить просто:
Как решить эту задачу в классике? Функции понятно использовать нельзя из-за рекурсии: программа может управлять длительными процессами.

Сообщение от sysghost Что касаемо линий связи при отображении алгоритмов то я считаю что от них нужно избавляться, это не электрическая принципиальная схема и лазить по линиям двигая картинку нерационально и да-же вредно, так как легко можно запутаться.

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

Сообщение от sysghost Вы говорите, логическом состоянии?

Да именно об этом. В блоках состояний находится логика, которая решает каким образом изменить данные присутствующие на входе в данные на выходе. Автомат состоит из трёх частей: 1)входные переменные, события и т.д.; 2) логического блока; 3) выходные действия, переменные и т. д;
Состояния автомата представляют из себя основную его сущность. По сути в них реализуется вся логика, условия.

Сообщение от sysghost Как можно узнать какое максимальное количество может быть входов и выходов у одного блока? Я так понимаю больше всего входов у блока условия, это один вход и два (три?) выхода.

По правилам структурного программирования у условной конструкции должен быть ОДИН вход и ОДИН выход! Как на рисунке:

В этом -то и весь сыр-бор между двумя подходами. Вся эта условная конструкция представляет из себя ОДИН БЛОК, который имеет один вход и выход. Из таких блоков, включая сюда и циклы, которые в структурном программировании(СП) тоже считаются блоками имеющими один вход и один выход, и строится программа. Тут следует сразу сказать, что писать программы в таком стиле ЧЕРЕЗВЫЧАЙНО трудно. Львиную долю времени приходится тратить на то, чтобы так изощриться, чтобы более менее осуществить задуманное. при этом приходится часто отступать от правил структурности, чтобы ДОПИСАТЬ программу.. Но это ещё цветочки. Люди, которые поняли всю несостоятельность СП, изобрели нечто, что было призвано заменить собой СП, - они предложили Обьектный подход: ООП. В этом подходе программа делится на обьекты, - структуры данных и методы их обработки. Скажу сразу, что подобное нововведение только усложнило программинг, который теперь стал доступе только супер пупер специалистам по ООП. Всех же остальных эти специалисты обозвали ламерами, говнокодерами и пр "одерами")). Однако они горько ошибаются..

1

Сообщение от CoderHuligan Усложним задачу: добавим переход в собственное состояние.

Вы сформулируйте задачу нормально. Возможно, её можно решить вообще без использования состояний.

У меня сложилось впечатление, что Вы изучили один подход к решению задач и все остальные подходы пытаетесь "натянуть" на свой, а это неудобно. Как если бы Вы научились играть в хоккей с мячом, увидели по телевизору хоккей с шайбой и теперь пытаетесь доказать, что такими клюшками, как у них, даже ударить нормально нельзя. Действительно, если взять клюшку двумя руками за конец черенка и замахнуться так, чтобы другой конец клюшки был направлен вверх, то не получится нормально ударить. Но это не значит, что им, чтобы получить нормальный результат, нужно играть такими клюшками, какими в хоккей с мячом играют.

0

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

Я начинаю понимать.
Можно ли сказать то-же самое так, что принятые на сегодняшний день условности в построении программ и вызывают трудности творческого подхода?
Все должны действовать в строгих рамках стандартных подходов по построению программ и не отступать от них потому что иначе такое отступление будет считаться не профессиональным или просто в конкретных языках нет подходящих средств реализации?
ООП - https://ru.wikipedia.org/wiki/... 0%B8%D0%B5

Цитата:

Основные принципы структурирования в случае ООП связаны с различными аспектами базового понимания предметной задачи, которое требуется для оптимального управления соответствующей моделью: абстрагирование для выделения в моделируемом предмете важного для решения конкретной задачи по предмету, в конечном счете — контекстное понимание предмета, формализуемое в виде класса; инкапсуляция для быстрой и безопасной организации собственно иерархической управляемости: чтобы было достаточно простой команды «что делать», без одновременного уточнения как именно делать, так как это уже другой уровень управления; наследование для быстрой и безопасной организации родственных понятий: чтобы было достаточно на каждом иерархическом шаге учитывать только изменения, не дублируя все остальное, учтенное на предыдущих шагах; полиморфизм для определения точки, в которой единое управление лучше распараллелить или наоборот — собрать воедино. То есть фактически речь идет о прогрессирующей организации информации согласно первичным семантическим критериям: «важное/неважное», «ключевое/подробности», «родительское/дочернее», «единое/множественное». Прогрессирование, в частности, на последнем этапе дает возможность перехода на следующий уровень детализации, что замыкает общий процесс.

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

Сообщение от CoderHuligan Если придерживаться определённых соглашений, то проблем не возникает. Такая схема очень наглядна и позволяет окинуть взглядом и понять весь алгоритм в целом. Таблица этого не позволяет.

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

Удобство я вижу в том, что в самом алгоритме имеется только указание что именно нам нужно вытаскивать из этих данных на конкретном этапе задачи - блоке алгоритма и проводить это в виде связей.
При этом если мы захотим привязать иной блок но со сходными характеристиками или участок кода, то нам нужно будет поменять только ссылку на него в алгоритме.
Насчет визуального удобства такого метода составления алгоритма я пока думаю, ну и опять же, визуально не обязательно представлять таблицу в виде месива ячеек а выделять только нужное, и таких средств выделения предостаточно.
Ладно, это пока размышления.

0