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

Приветствую

Дракон - 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

Сообщение от Shamil1 По условию есть четыре кнопки (синий, красный, оба, никакой) , и только одна из них может быть нажата.

Не не не,) по условию есть 4 состояния индикации и 4 кнопки управления, состояние может быть только одно из 4, а как нажимаются кнопки не сказано, значит как попало. Впрочем это шутка была, мне лично все равно да и тема не о том, но Sindbad_M может быть другого мнения раз он условия придумывает по ходу реализации алгоритма. Я вот только не понимаю зачем ходить вокруг да около а не сказать конкретно что и чему тут мешает.

Добавлено через 7 минут
У меня то-же есть косячек в алгоритме, состояние когда нажимается кнопка 4 лучше перенести в начало опроса на случай если оператор решит, что для включения всех светодиодов лучше нажать все кнопки)

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

0

Сообщение от sysghost по условию есть 4 состояния индикации и 4 кнопки управления, состояние может быть только одно из 4, а как нажимаются кнопки не сказано, значит как попало.

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

0

Сообщение от Sindbad_M Мне казалось очевидным что "{включаем синий}" это абстракция, которой в структурном программировании соответствует подпрограмма.

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

Сообщение от Sindbad_M Если для выполнения каких-то действий требуются проверки, то их выполняют в теле подпрограммы.

А вот это уже сомнительно. Действия и проверки должны быть разделены.

Сообщение от Sindbad_M Решение в структурном программировании тривиально, любой школьник справится.

Ну дык где решение? Нужно сделать именно в структурном стиле ТОЧНЫЙ алгоритм, который я предложил. То есть, не нужно обсуждать конкретно светодиоды там или что-то другое и что они делают - это не важно - важно осуществить ТОЧНЫЙ алгоритм. Похоже мне придётся самому этим заняться..
Заметьте такую важную вещь: в каждом состоянии при нажатии одной и той же кнопки осуществляются разные действия. Например при нажатии на кнопку "выключить оба светодиода" в первом состоянии выполнится действие "выключаем синий". Во-втором состоянии действие "выключаем красный". В третьем состоянии действие "выключаем оба светодиода", а в четвёртом "остаёмся в этом же состоянии." Это не просто так. Просто примите это к сведению, и когда горят например оба светодиода, выполните определённые действия.

Сообщение от Shamil1 Программирование для микроконтроллеров уже сама по себе нетипичная задача (очень небольшой процент программистов этим занимается).

Если избавиться от иллюзий, то станет понятно, что программированием микроконтролёров занимается БОЛЬШИНСТВО программистов в мире, ибо микроконтролёры сейчас практически везде: от автомобиля до стиральной машины. В одном автомобиле может быть несколько сотен микроконтролёров, и каждый нужно запрограммировать.

Сообщение от Shamil1 Я считаю, что для очень узкого класса задач - программирования для микроконтроллеров - наилучшим подходом являются автоматы, реализованные с помощью GOTO." Правильно я сформулировал Вашу мысль?

Нет. При помощи автоматов можно И НУЖНО реализовывать абсолютно ВСЕ вещи.

Сообщение от Shamil1 Во-первых, у меня здесь нет никакой рекурсии.

Если кнопки будут нажиматься в определённой последовательности, то произойдёт та самая рекурсия.

Сообщение от Shamil1 ИМХО мой вариант итак не хуже Вашего.

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

Сообщение от Shamil1 Вот вариант с таблицей переходов

По сути реализован тот же автомат, только через таблицы указателей на функции, которые реализуют логику. Здесь нет рекурсии, это уже лучше. Однако скажите мне: что понятнее - ваш вариант, или мой? Что проще: ваш или мой? Что производительней: ваш ли мой? К тому же у вас опять отсутствует явное деление на состояния, а значит затруднён будущий рефакторинг, а также совершенно не учитываются действия при определённом состоянии светодиодов..
Конкретно мой алгоритм не реализован. Попробую сам реализовать его в традиционном стиле при помощи флагов. Без флагов реализовать невозможно. А потом сравним, что легче для понимания и обьём кода.

0

Сообщение от sysghost существующих реализаций Дракона

Сама система основана на том, что алгоритм в виде схемы наглядней, чем алгоритм в виде текста. Утверждение весьма спорное. Возможно так и было во времена небольших программ, ассемблера и "спагетти-кода".
ИМХО грамотно написанный код на нормальном ЯП гораздо наглядней, чем какая-то схема.
И если мне нужны, например, зависимости какого-то метода, то мне удобнее в два клика получить их в виде списка строк кода, в которых он вызывается (с возможностью кликом перейти к любой из этих строк в коде).
Например, у меня в основном Сольюшене 50 проектов, всего в приложении около 100 проектов. В самом большом проекте 500 классов, но обычно около 50. Теперь представьте, что я оформил всё это в виде диаграммы классов и пытаюсь найти, куда ведёт вот эта стрелочка зависимости. Как в детской задаче "проведи колобка по лабиринту".

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

Сообщение от CoderHuligan Если избавиться от иллюзий, то станет понятно, что программированием микроконтролёров занимается БОЛЬШИНСТВО программистов в мире, ибо микроконтролёры сейчас практически везде: от автомобиля до стиральной машины. В одном автомобиле может быть несколько сотен микроконтролёров, и каждый нужно запрограммировать.

Согласно Вашей логике, так как телефонов продаётся больше, чем компьютеров, то большинство программистов в мире занимаются прошивкой телефонов.
Зайдите на какой-нибудь сайт с вакансиями и увидите, что на 1 вакансию "программист микроконтроллеров" приходится 10 вакансий "программист 1С". Хотя очень небольшой процент программистов занимается 1С, микроконтроллерами занимается в 10 раз меньше.

Сообщение от CoderHuligan При помощи автоматов можно И НУЖНО реализовывать абсолютно ВСЕ вещи.

Чего Вы тогда привязались к микроконтроллерам? Давайте посмотрим на Ваши автоматы на примере обхода графа или умножении матриц.

Сообщение от CoderHuligan Если кнопки будут нажиматься в определённой последовательности, то произойдёт та самая рекурсия.

Объясните, пожалуйста, как может "произойти" рекурсия в коде, в котором нет ни одного рекурсивного вызова?

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

Обоснуйте.

Сообщение от CoderHuligan Однако скажите мне: что понятнее - ваш вариант, или мой? Что проще: ваш или мой?

Оба простые.

Сообщение от CoderHuligan Что производительней: ваш ли мой?

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

Сообщение от CoderHuligan К тому же у вас опять отсутствует явное деление на состояния, а значит затруднён будущий рефакторинг

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

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

Какие действия при каком состоянии светодиодов учитываются в Вашем коде и не учитываются в моём? Два светодиода исправно моргают - можно запустить код и убедиться в этом. Если Вы придумали новые действия, то я не телепат.

0

Сообщение от Shamil1 Зайдите на какой-нибудь сайт с вакансиями

Микроконтролёрщики все сидят на фабриках и заводах..

Сообщение от Shamil1 Давайте посмотрим на Ваши автоматы на примере обхода графа или умножении матриц.

Умножние матриц легчё лёгкого решается обычным образом, тут автоматы не нужны, хотя можно применить. Обход деревьев реализуются например так: http://is.ifmo.ru/works/traverse.pdf

Сообщение от Shamil1 Объясните, пожалуйста, как может "произойти" рекурсия в коде, в котором нет ни одного рекурсивного вызова?

Я про ваш предыдущий код.

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

По предыдущему коду и так всё ясно.

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

Вызов функций быстрее прямого перехода? Не смешно.

Сообщение от Shamil1 Для добавления состояния Вам нужно добавить блок кода и внести изменения во все остальные блоки кода.

Заметьте: мне нужно всего лишь ДОБАВИТЬ это в текст, НИЧЕГО при этом не ИЗМЕНЯЯ. А вам требуется кое-что изменить.

0

Сообщение от CoderHuligan тут автоматы не нужны

То есть, до этого Вы писали неправду? (Что при помощи автоматов НУЖНО реализовывать все вещи).

Сообщение от CoderHuligan Я про ваш предыдущий код.

Покажите мне рекурсивный вызов в моём предыдущем коде.

Сообщение от CoderHuligan Вызов функций быстрее прямого перехода? Не смешно.

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

Сообщение от CoderHuligan не нужно всего лишь ДОБАВИТЬ это в текст, НИЧЕГО при этом не ИЗМЕНЯЯ

Вам нужно изменить все блоки кода. Если бы код занимал 20 экранов текста, то Вам пришлось бы редактировать все 20 экранов. Мне нужно добавить функции в одном месте и изменить инициализацию массива в другом месте. Код основной функции, реализующей логику переходов, мне вообще менять не надо. Итого 2, а не 20.

0

Сообщение от CoderHuligan Ну дык где решение? Нужно сделать именно в структурном стиле ТОЧНЫЙ алгоритм, который я предложил. То есть, не нужно обсуждать конкретно светодиоды там или что-то другое и что они делают - это не важно - важно осуществить ТОЧНЫЙ алгоритм. Похоже мне придётся самому этим заняться..

Может таки так?
Правда стрелочку забыл нарисовать с "a=в, включить синий" на условие "в-б>Х?"

Миниатюры

 

0

Впрочем если случае ошибки оператора предпочтительнее выключать а не включать то последовательность опросов можно сохранить начальную (не 1,2,4,3 а 1,2,3,4) в теле алгоритма.

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

Сообщение от Shamil1 Теперь представьте, что я оформил всё это в виде диаграммы классов и пытаюсь найти, куда ведёт вот эта стрелочка зависимости. Как в детской задаче "проведи колобка по лабиринту".

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

0

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

Миниатюры

 

0

Там есть ошибки, например по действию 4 вместо Нет нужно назначить Да, и кроме того инициализация переменных и назначение портов можно вынести в отдельную таблицу, но тот рисунок что бы иметь представление о чем я вообще говорю.
Ну и можно назначить столбцы Да/Нет параллельно с условиями и выделять их чекбоксами как активный/неактивный, в общем есть над чем подумать.

0

Сообщение от sysghost Приведу данный алгоритм в виде таблицы в первом приближении, что бы понятнее было.

Для меня код, написанный CoderHuligan, более понятен, чем эта схема.

0

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

Их нет.

Сообщение от sysghost 1. Быстрое восприятие информации и ориентирование в блок схеме программы.

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

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

Сообщение от sysghost 2. Легкое понимание алгоритма для тех, кто с ними знаком вообще, но не знаком с программированием в частности.

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

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

Я не позавидую человеку, который захочет провести рефакторинг такой блочной структуры. А как работать в команде? Как делать ревью? Как анализировать такую программу? Это всё ключевые вещи.

Блок-схемное «программирование» это исключительно монопольная процедура, без права на ошибку.

Сообщение от sysghost 4. Экономия времени при изучении блок схем чужих программ или их фрагментов.

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

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

Уже сто лет как существуют модули. Если угодно, можно посмотреть на них как на картинки, открываете папку с DLL, например, и смотрите на пиктограммы файлов. Кто мешает? Нужно что-то ещё придумать?

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

Скажем так. Если людей не считать за дураков, перманентно, то можем увидеть, что никаких «графических» языков программирования, которые бы серьёзно использовались сейчас нет. Максимум, это прикладная область, типа построение бизнес-процессов в виде кубиков, и workflow. Но это не программирование по сути, это настройка, конфигурация. К тому же, легко выражаемая любыми другими средствами (xml, например). Картинки, это лишь одно из представлений.

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

Добавлено через 7 минут
Поговорим о художественной литературе? Герой будет иконкой человечка. Герой пошёл -- линия -- куда пошёл. Герой думает -- блок в виде облачка. И т.д.

Существуют комиксы, но это не то, они не являются другой формой книги, это совершенно другой формат, другое искусство.

Речь идёт именно о том, как передать содержание книги в виде блок-схем и ничего не потерять. Возможно ли это? Я думаю, да. Это возможно. Просто другой язык, графический. Разумно ли это? Нет. Не разумно.

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

Все инструменты хороши. Вместе, каждому инструменту своя ниша.

Заявить, ну а чем молоток не замена микроскопу? Можно. Но зачем людей смешить?

2

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

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

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

Да, только если это не код микропроцессора например.

Сообщение от csproj Я не позавидую человеку, который захочет провести рефакторинг такой блочной структуры. А как работать в команде? Как делать ревью? Как анализировать такую программу? Это всё ключевые вещи. Блок-схемное «программирование» это исключительно монопольная процедура, без права на ошибку.

Ну наверно потому Дракон по большей части приглянулся именно программистам микроконтроллеров.

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

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

0

Сообщение от sysghost Да, только если это не код микропроцессора например.

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

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

Сообщение от sysghost Если Вы не знаете историю Дракона

Да знаю я.

Но.

https://ru.wikipedia.org/wiki/... 0%B8%D1%8F)

Сообщение от sysghost Ну наверно потому Дракон по большей части приглянулся именно программистам микроконтроллеров.

Здесь я не могу ничего утверждать и тем более спорить. Не программировал микроконтроллеры никогда

0

А что АДАhttps://ru.wikipedia.org/wiki/... %B8%D1%8F)?
То-же язык программирования, а тема про построение алгоритмов.
То, что этот алгоритм впоследствии можно будет преобразовать в код программы или наоборот, это уже функционал самой программы.

0

Кстати примером блочного моделирования есть LabVIEW от National Instruments.
https://ru.wikipedia.org/wiki/LabVIEW
И очень интенсивно развивается между прочим. Дракону просто не дали шанса.

0

Сообщение от sysghost Кстати примером блочного моделирования есть LabVIEW от National Instruments.

Насколько я понял, там функциональный язык для параллельной обработки данных. Фактически, они строят сети. На Си такое (такой алгоритм) не напишешь. Можно написать, например, на Oz.
А Дракон пытается кодировать императивные блок-схемы - с циклами и переменными. Такое проще на Си написать.

0

Сообщение от Shamil1 Насколько я понял, там функциональный язык для параллельной обработки данных. Фактически, они строят сети. На Си такое (такой алгоритм) не напишешь.

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

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

Сообщение от Shamil1 А Дракон пытается кодировать императивные блок-схемы - с циклами и переменными. Такое проще на Си написать.

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

0

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

Для императивной парадигмы легко написать компилятор, так как инструкции языка примерно соответствуют инструкциям процессора. Именно поэтому она стала доминировать. Декларативная парадигма гораздо удобнее для выражения своих мыслей (для создания алгоритмов), но сложнее написать компилятор (он должен обладать "интеллектом"). Например, можно сформулировать правило "X старше Y, если есть Z такой, что X старше Z и Z старше Y" и предоставить компилятору самому превратить это в машинные инструкции.

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

0

Сообщение от Shamil1 Декларативная парадигма гораздо удобнее для выражения своих мыслей (для создания алгоритмов), но сложнее написать компилятор (он должен обладать "интеллектом"). Например, можно сформулировать правило "X старше Y, если есть Z такой, что X старше Z и Z старше Y" и предоставить компилятору самому превратить это в машинные инструкции.

Да-же если такой инструкции еще нет, то можно дать возможность пользователю её создать самому, так и поступили National Instruments, то есть создавать пользовательские инструкции. Один раз создать нужный блок и проверить его функциональность что бы затем просто его использовать как черный ящик не так уж сложно, это то-же что и копировать блоки кода но с меньшей вероятностью ошибки при копировании.

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

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

0