Автор этого сообщения Сергей Ефанов (город Липецк)

Сергей Ефанов программирует только на ДРАКОНе

Программирование микроконтроллеров на ДРАКОНе

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

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

Медленно и со вкусом прочитал.

И — понял! Это просто клад!

По возвращении уже думал только об одном: где бы найти инструмент для работы?
К счастью, такой инструмент нашелся.
Попробовал небольшие примерчики — вроде какой то код генерится. Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.

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

В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!

С тех пор прошло чуть больше года. Я программирую только на ДРАКОНе.
Попытаюсь сказать несколько слов о том, что это мне дало, и как выглядит процесс.

Написание программы распалось на два этапа — проработка алгоритма, и собственно программирование.

Главное в любой программе — алгоритм. В ДРАКОНе он рисуется, точнее — составляется из графических элементов. Очень похожих на элементы блок-схем.

Но есть несколько строгих правил, которые не позволяют схеме превратиться в запутанный клубок линий, квадратов и ромбиков.
Правила, на первый взгляд, простые. Но эффект от их применения — колоссальный!

На ДРАКОНЕ запутанный и непонятный алгоритм нарисовать просто нельзя. И наоборот, любой сложный алгоритм, нарисованный согласно этим правилам, становится очень понятным.

При разработке алгоритма теперь его не надо держать в голове при написании текста программы. Работа сводится к визуальному конструированию алгоритма. Это гораздо легче. Не требуется такое сосредоточение, как обычно. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент, потом легко вернутся к её продолжению.

И только когда весь алгоритм «отлизан» — переходим к собственно программированию. В чём оно теперь заключается? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка. На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.

В этом месте, наверняка, у многих вырвется вопрос: — «Ну и зачем весь этот огород, если код всё равно надо писать самому?!».

Не торопитесь!

В чём сложность программирования? (с тем, что программирование — сложная работа, думаю, никто спорить не будет?).

Разве в написании строчек типа printf(«Hello, Word»);?
Станет ли сложной программа от того, что мы напишем 1000 подобных строчек? А 10000?
Нет, она не станет от этого сложной. Сложной программу делают сложные взаимосвязи между её частями.

Так вот, на этапе программирования икон об этом думать уже не надо.

Совсем. Вообще. Никак. Не надо, и всё тут!

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

Программирование на этом этапе превратилось в чисто техническую процедуру. Несложную.

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

=======

Как начать использовать ДРАКОН?

Нужно потрудится. Нужно прочитать книгу «Язык Дракон».

Прочитать неспеша и вдумчиво.

Мне помогло, что я её читал в поезде, где не было отвлекающих факторов. Книга написана очень хорошо, просто, доходчиво, интересно.
http://drakon-practic.ru/

Если по прочтении возникло желание попробовать ( а я не сомневаюсь, что возникнет ) — тогда скачивайте ИС ДРАКОН, и начинайте.
http://drakon-practic.ru/is_drakon.zip

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

Дело в том, что сегодня за пределами РосКосмоса почти нет инструментов, пригодных для практической работы с языком ДРАКОН. «ИС ДРАКОН» пишется на голом энтузиазме одним человеком, в свободное время.

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

Понятно же, что программа, которая в процессе этих уроков создаётся, может быть написана в текстовом редакторе за пару минут без всех этих хлопот. Делать на основе этого урока заключение о языке — это тоже самое, что писать рецензию на «Война и Мир» по «Мама мыла раму».

Но конечно же, Вы начнёте с видеороликов! Ну что же. Имеющий уши — услышит, имеющий глаза — увидит.
http://drakon-practic.ru/is_drakon_part1.zip
http://drakon-practic.ru/is_drakon_part2.zip
http://drakon-practic.ru/is_drakon_part3.zip
http://drakon-practic.ru/is_drakon_part4.zip

Видеоролики уроков теперь размещены и на youtube:

Сообщение Сергея Ефанова взято отсюда
http://we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html

За этим сообщением следуют 276 комментариев.
Рекомендую прочитать комментарии.
http://we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html#comment39416

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование
Чем это подтверждено?
ВП>Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат.
Чем это подтверждено? В чем выражена эта трудность?
ВП>Это обстоятельство ставит непреодолимый барьер для многих специалистов, работа которых связана с алгоритмами, но которые не имеют резерва времени, чтобы научиться выражать свои профессиональные знания в форме алгоритмов и программ.
WTF??? MathCAD, Mathematica, LabVIEW, .....

ВП>Можно ли устранить этот недостаток? Можно ли облегчить жизнь алгоритмистов и программистов? И поднять производительность их труда? Да, можно.
Какой ещё недостаток? Трудность для понимания и неоправданно большие затраты — ну лично я не вижу никакой трудности. Языки сейчас есть на любой вкус.
Алгоритмистов, это кто?

ВП>Дракон использует новую эргономичную нотацию — дракон-схемы. В итоге ТРУДНЫЕ для понимания способы записи алгоритмов и программ заменяются на более ЛЕГКИЕ. Вследствие этого работники быстро овладевают дракон-схемами и успешно создают алгоритмы и прикладные программы без программистов или с их минимальным участием.
Нет пояснения в чем же её эргономичность.

ВП>Изюминка в том, что Дракон — очень легкий язык. Необыкновенно легкий. Прочитав книгу, вы без труда убедитесь, что управляющая графика Дракона является мощным инструментом, причем ее мощь легка в освоении и легко применима на практике.
Легкость то в чем. Я вот бегло пробежался по книге и пришел к выводу о огромных схемах. Текстовая форма более компактна.

ВП>Даю ссылку на Краткое описание языка ДРАКОН. Всего 124 страницы. Много рисунков.
ВП>О космических кораблях нет ни слова. Все примеры очень простые, бытового характера.
ВП>http://drakon-practic.ru/drakon.pdf
А можно с практическими, а не бытовыми примерами? Обычно программы не копают червей и не покупают яхты.

Здравствуйте, LaptevVV, Вы писали:

LVV>Речь не о голове, а о методике обучения. При любой методике будут умные головы и будут глупые головы. Но подходящая методика может помогатть обучению, а неподходящая — будет мешать
Ну так а почему вы здесь рекламируете заведомо проигрышные методики? Методика обучения по картинкам хороша для младенцев или идиотов. Методика аля Кормен, Седжвик и Ко с предельно короткими мат. описаниями и алгоритмами позволяет эффективно выделить адекватного специалиста.
Объясните для чего мне как CS-инженеру рисовать картинки алгоритмов, ума не приложу?
А то до смешного доходит — приходит молодой парень, ты его просишь просто объяснить смысл балансировки дерева и перечислить основные классы сб. деревьев, а он говорит что деревья видел только в парке. Но зато рисует картинки и прочел экспресс-курс по с++ от академического! автора

.

LVV>1. В США знают, ибо книга о Драконе в этом году будет выпущена в Америке на английском языке.
Еще на китайском выпустите и можете четверть населения планеты записать в дракон-программисты

.

LVV>2. Один из разработчиков Дракон-редактора (см. сообщение Паронджанова) — норвежец...
Один из двух разработчиков

. Неужели вы серьезно

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование

Да? И как же выделенное облегчает "алгоритмизацию"? Повторенье мать ученья?

Запостите лучше сюда алгоритм балансировки AVL-дерева, пожалуйста. А то все эти "Обед в ресторане" и "Покрасить забор" как-то не тянут на типичные задачи.

1>Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>>Дракон использует новую эргономичную нотацию — дракон-схемы. В итоге ТРУДНЫЕ для понимания способы записи алгоритмов и программ заменяются на более ЛЕГКИЕ. Вследствие этого работники быстро овладевают дракон-схемами и успешно создают алгоритмы и прикладные программы без программистов или с их минимальным участием.

1>Нет пояснения в чем же её эргономичность.

Вы не правы. Пояснение есть. Чтобы понять суть дела, надо внимательно прочитать 124 страницы.

Я ввел понятие "эргономичный алгоритм". Это принципиально новое фундаментальное научное понятие.

Понятие "эргономичный алгоритм" раскрывается через новые определения, новые правила и иллюстрирующие их примеры.

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, LaptevVV, Вы писали:

LVV>>Речь не о голове, а о методике обучения. При любой методике будут умные головы и будут глупые головы. Но подходящая методика может помогатть обучению, а неподходящая — будет мешать
__>Ну так а почему вы здесь рекламируете заведомо проигрышные методики? Методика обучения по картинкам хороша для младенцев или идиотов. Методика аля Кормен, Седжвик и Ко с предельно короткими мат. описаниями и алгоритмами позволяет эффективно выделить адекватного специалиста.
Вы давно преподавали в вузе, чтобы так БЕЗАПЕЛЛЯЦИОНННО судить о качестве преподавательских технологий?
Знает тот, кто делает (с)
__>Объясните для чего мне как CS-инженеру рисовать картинки алгоритмов, ума не приложу?
Вам — не надо.
__>А то до смешного доходит — приходит молодой парень, ты его просишь просто объяснить смысл балансировки дерева и перечислить основные классы сб. деревьев, а он говорит что деревья видел только в парке. Но зато рисует картинки и прочел экспресс-курс по с++ от академического! автора

.
Значит, так учили. Или сам учился.

LVV>>2. Один из разработчиков Дракон-редактора (см. сообщение Паронджанова) — норвежец...
__>Один из двух разработчиков

. Неужели вы серьезно

?
UML вначале тоже только три человека делали.

«Если вы не можете своему ребенку за пять минут объяснить, чем вы занимаетесь, значит, вы занимаетесь какой-то ерундой».

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

ВП>Я ввел понятие "эргономичный алгоритм". Это принципиально новое фундаментальное научное понятие.
Как выглядит эргономичная быстрая сортировка?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>>Язык Дракон значительно облегчает алгоритмизацию и программирование
WH>Дракон-схема задает конечный автомат.

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

Не совсем, как я понял, но где-то рядом. Дракон задает ГСА — графическую схему алгоритма. Ну, а дальше уже дело техники — преобразовать в машинный код. У нас на теории автоматов мы такие же рисовали, как исходное данное. Обозначали операторные вершины состояниями, рисовали автомат Мура/Мили, минимизировали число состояний, потом делали комбинационную схему и определяли, сколько ячеек памяти нужно для Блока Памяти.
В принципе, при наличии иструмента, который все этапы автоматизирует, можно попробовать использовать, но мне кажется, что ГСА намного дольше рисовать, чем писать код. Хотя для понимания, что там в программе происходит, ГСА наверно более удобны. Но лучше ГСА по коду генерит, чем наоборот. Хотя генерацию кода по схеме реализовать думаю проще.
Честно говоря, для embedded софта, где еще надо иногда вылизывать — Дракон имеет шанс, плюс, можно бэкэнд поменять и генерить не машинный или C код, а vhdl например, для аппаратной реализации. Можно прототипы на чем-то программируемом делать, а при необходимости запустить большую серию имеет смысл в железе реализовать.
Но, повторюсь, рисовать ГСА гораздо медленнее, чем писать код на ЯВУ. На Драконе можно пять лет рисовать совершенную систему, а на тех же плюсах можно сделать за полгода рабочее решение, и допиливать его, если понадобится. А может и не понадобится, с большой вероятностью.
Имхо, для некоторых достаточно узких ниш, если будет годный инструментарий, и при наличии толкового и думаю, небесплатного продвижения, часть рынка можно занять.

Но надо не забывать, что есть такие языки (как текстовые, так и графические), как:
Structured Text (ST) — язык программирования для программирования промышленных контроллеров и операторских станций
LD — Релейно-Контактные Схемы (вроде графический)
FBD — Функциональные Блоковые Диаграммы (тоже вроде графический)
IL — Список Инструкций (типа дотнетовского IL для )
SFC — Последовательностные Функциональные Диаграммы

За деталями можно отсюда начать.

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

Я просто увлекался (да и сейчас все подмывает заняться) автоматным программированием, у нас это Шалыто (ИТМО) популяризирует (Switch-технологии), наваял такую штуку. С ее помощью довольно много по мелочам сделал, было в принципе удобно, но из-за убого редактора statechart'ов (Dia, я написал только кодогенератор по ее файлам) пользоваться не очень удобно. Вернее удобно, если пользоваться постоянно, но когда я через год вернулся что-то подправить, было не слишком просто. В мелких вещах без проблем, но я как-то налабал автоматы лексера и парсера для языка типа IDL, вот в них правки было не слишком просто вносить.

WH>Если задача не сводится к конечному автомату, то дракон работать перестает.
А какая задача не сводится к конечному автомату? Если дополнить его стеком состояний? У меня в генераторе (см выше) как раз в парсере IDL был случай, когда нужна была рекурсия. классический автомат не мог это обработать, я просто добавил генерацию стека состояний в генератор и ввел способ вызова подавтоматов с сохранением состояния на стеке, и все заработало. В местах, где не было рекурсии, я просто делал подстановку подавтомата в объемлющий автомат.

Здравствуйте, batu, Вы писали:

B>Во-во.. Об чем я и говорю.. Системы реального времени с прерываниями и обработкой телеметрии вносят долю недерминированности
А что не так? Тут вполне автоматность как раз и работает — внешние запросы это просто входные воздействия для автомата. Собственно, это как раз конек автоматного программирования. Но что-то сложное в таком ключе написать тяжело.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП> Автор этого сообщения Сергей Ефанов (город Липецк)

ВП>Сергей Ефанов программирует только на ДРАКОНе

Хочу порекомендовать Сергею Ефанову открыть для себя
LD — Релейно-Контактные Схемы
FBD — Функциональные Блоковые Диаграммы
SFC — Последовательностные Функциональные Диаграммы

Пытаюсь не ерничать, но вы не могли бы рассказать, что нового по сравнению с этими, уже очень широко используемыми языками вы привносите? Сейчас каждый уважающий себя производитель микроконтроллеров почти полный комплект инструментов для этих языков предоставляет. Более того, многие промышленные контроллеры сейчас уже не программируются в машинных кодах, ассемблере или на C — а только при помощи перечисленных языков, ну или еще при помощи IL или ST.
Вам надо искать инвестиции, в Сколково податься, что ли. Можно попытаться сделать универсальный инструмент, который поддерживает как МК с IL/ST, так и те, которые программируются на своем ассемблере или на C. Другой вариант — взять свою команду и пойти в Сименс или еще куда, может они заинтересуются вашими наработками.

Здравствуйте, minorlogic, Вы писали:

M>«Если вы не можете своему ребенку за пять минут объяснить, чем вы занимаетесь, значит, вы занимаетесь какой-то ерундой».
Только что хотел сам написать, но решил глянуть ветку дальше

Здравствуйте, Mazay, Вы писали:

M>Запостите лучше сюда алгоритм балансировки AVL-дерева, пожалуйста. А то все эти "Обед в ресторане" и "Покрасить забор" как-то не тянут на типичные задачи.

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

Здравствуйте, Marty, Вы писали:

WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.
M>А какая задача не сводится к конечному автомату? Если дополнить его стеком состояний? У меня в генераторе (см выше) как раз в парсере IDL был случай, когда нужна была рекурсия. классический автомат не мог это обработать, я просто добавил генерацию стека состояний в генератор и ввел способ вызова подавтоматов с сохранением состояния на стеке, и все заработало. В местах, где не было рекурсии, я просто делал подстановку подавтомата в объемлющий автомат.
Меня полнота по Тьюрингу не волнует.
Совсем.

Просто пойми одну простую вещь: Решения задачи в терминах предметной области, которая не имеет ничего общего с КА будет раз в 100 меньше чем то, что ты напишешь на этих своих КА со стеком состояний.

Ссылку на пример я дал в том сообщении, на которое ты отвечал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, TimurSPB, Вы писали:

ВП>>Я ввел понятие "эргономичный алгоритм". Это принципиально новое фундаментальное научное понятие.
TSP>Как выглядит эргономичная быстрая сортировка?
Элементарно:

Всё просто и эргономично!

Здравствуйте, Mazay, Вы писали:

M>Да? И как же выделенное облегчает "алгоритмизацию"? Повторенье мать ученья?
M>

Кстати, даже этот детский пример — неправильный.

К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.

Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.

Здравствуйте, WolfHound, Вы писали:

WH>Просто пойми одну простую вещь: Решения задачи в терминах предметной области, которая не имеет ничего общего с КА будет раз в 100 меньше чем то, что ты напишешь на этих своих КА со стеком состояний.

WH>Ссылку на пример я дал в том сообщении, на которое ты отвечал.

Ок, глянул, и, думаю, понял. Я сам вообще любитель писать DSL, есть грешок, бывает и не совсем к месту в плане трудозатрат на разработку DSL и выгод от его использования. Когда ясно, что надо одну шестую часть суши перепахать при помощи предполагаемого DSL — тут вопросов нет, а когда это на текущий момент три дачных огорода, правда в планах работодателя прикупить еще то ли 10, то ли 1000 тыщ гектар, тут сложно решить, как быть.

Ну а свой КА со стеком состояний я как раз и использовал для написания IDL, то есть некоторым образом DSL. Из того IDL генерились интерфейсы для С/C++, что было приятно для межмодульного взаимодйствия — приятно было то, что можно было использовать только то, что поддерживает IDL, который сам по себе, если его знать, как и во что он преобразует, является документацией. Можно было написать coding std, потратив наверно еще и больше времени, и получив бумагу, которая ничего не гарантирует.
Ну а КА также хороши как для создания DSL, так и для создания программ на этом DSL. Был бы хороший расширяемый инструмент, а новый бэкэнд всегда можно присунуть.

Здравствуйте, Cyberax, Вы писали:

C>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.

C>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.

State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов. Топик-стартер отстал от жизни лет на 10, видимо он так плотно занимался Драконом, что некогда было по сторонам смотреть. Такое бывает, в этом нет ничего странного или зазорного. Сам с таким возился (и таки лелею мечту продолжить — скрестить C,C++,D и динамические языки типа Питона и Lua через пачку интерфесов). Я пока правда отложил это занятие — за паровозами индустрии тяжело успевать, подустал лабать, решил отдышаться и посмотреть, куда дальше двигаться.
Ну я отвлекся. ТС'у надо по сторонам оглядеться, я уже пару раз тут писал, что следовало бы посмотреть. Человек не побоялся озвучить свои мысли — это плюс. Человек сильно отстал от жизни — это минус. Хочу пожелать ему удачи, и надеюсь, что в следующий раз он выйдет более подготовленным.

Здравствуйте, Marty, Вы писали:

C>>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.
C>>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.
M>State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов.
Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.

Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").

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

Здравствуйте, Cyberax, Вы писали:

C>>>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.
M>>State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов.
C>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
Так дефолтный переход по необрабатываемым событиям — "Послать нах"

А где жену можно обработать — так обрабатывем явно

C>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
Тут да, согласен. Нужен удобный язык для state-машин, как текстовый, так и графический, и желательна возможность редактирования как текста, так и графики, со сведением в один текстовый и читабельный исходник.

C>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
Ну, структуры могут быть либо частью состояния машины, либо параметрами event'а для state-машины. А вообще, конечно, всю программу целиком нельзя или очень сложно описать стейт-машиной, но реакция машины на события обычно не тривиальная, и подразумевает вызов метода обработчика, который может и со структурами работать.
Связанный список или хэш-мэп — это проблемы пользователя state-машины, который должен переопределить метод save_to_hash_map или save_to list, или более обще — save_to_storage, если такой заявлен в машине.
Автоматное программирование и концепция state-machine, и их развитие мне стало интересно после того, как мне удалось сделать при помощи автоматов вполне функциональный http-сервер, с которым работали ie, chrome, opera и firefox для веб-настройки девайса на x86, где под программу и данные было около 100Кб, и большую часть занимал код 10ти или 15ти страничек, которые надо было выводить, а также код, обрабатывающий запросы. Не то чтобы я хвалюсь, но это был вин, ну по крайней мере для меня

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Marty, Вы писали:

C>>>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.
C>>>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.
M>>State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов.
C>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.

Если новые состояния переключаются event`ом будет только одна точка входа wait_events -> process.
Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.

C>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").

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

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

Вот не надо, установить tcp соединение это уже стейт-машина примитивная.

Здравствуйте, LaptevVV, Вы писали:

LVV>Вы давно преподавали в вузе, чтобы так БЕЗАПЕЛЛЯЦИОНННО судить о качестве преподавательских технологий?
Я слава господу не преподавал. Я просто периодически наблюдаю разницу в людях вышедших из ВУЗ-ов, т.е. получивших образование определенного качества. И вывод очень прост — те люди которые получали классическое математическое или CS-образование имеют гораздо более высокий уровень компетентности и адекватности.
LVV>Знает тот, кто делает (с)
Кто умеет, делает; кто не умеет, учит других. (с)

LVV>Значит, так учили. Или сам учился.
Система учила и получился возможно умный но не образованный человек. А мог бы быть образованным.

LVV>UML вначале тоже только три человека делали.
UML прошел полный путь от идеи до международного признания и стандартизации за 10 лет. А известность получил через 5 лет после старта. А сколько вы говорите дракон жив? 20-30 лет?

Уважаемые коллеги!

Предлагаю вашему вниманию Заключение по книге 2012 года.

АЛГОРИТМЫ ДОЛЖНЫ БЫТЬ ПОНЯТНЫМИ
(вместо заключения)

ЗАЧЕМ НАПИСАНА ЭТА КНИГА?

В этой книге мы попытались:

• провести четкую грань между алгоритмизацией и программированием;
• сосредоточить внимание на алгоритмах, оставив программирование за рамками книги;
• изложить основы алгоритмизации;
• создать средства, обеспечивающие максимально возможную понятность алгоритмов. И за счет этого сделать алгоритмы доступными для «народа».

КРИТИКА ТРАДИЦИОННЫХ ПОДХОДОВ

Прежние способы записи алгоритмов устарели. Они слишком трудны для понимания и требуют неоправданно больших трудозатрат.

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

Традиционные формы представления алгоритмов отжили свой век и должны сойти со сцены. Именно они несут ответственность за господствующую на нашей планете алгоритмическую неграмотность.

КАКИЕ РЕЗУЛЬТАТЫ ПОЛУЧЕНЫ?

• Предложен новый способ записи алгоритмов – дракон-схемы.

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

• Использование дракон-схем позволяет повысить производительность труда при разработке, анализе и проверке алгоритмов (возможно, в несколько раз).

• Дракон-схемы облегчают и ускоряют обучение алгоритмизации.

• Новый способ записи дает возможность коренным образом изменить систему образования в области алгоритмизации. И познакомить с алгоритмами более широкие слои населения;

Можно предположить, что внедрение дракон-схем в массовую практику поможет обеспечить ликвидацию алгоритмической неграмотности.

ПОНЯТНОСТЬ АЛГОРИТМОВ

При разработке языков для записи алгоритмов (алгоритмических языков) обычно выдвигается ряд требований. К сожалению, среди них, как правило, отсутствует самое важное для человека:

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

Слово «понятны» следует пояснить. Нужны не просто понятные, а в высшей степени понятные алгоритмы. Это значит, что должен выполняться принцип: «Взглянул – и сразу понял!», «Посмотрел – и мигом во всем разобрался!».

С учетом этих пояснений вводится термин «критерий сверхвысокой понятности».

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

Чтобы выполнить указанное требование, одной математики мало. Наряду с математикой, необходимо использовать когнитивную эргономику.

КОГНИТИВНАЯ ЭРГОНОМИКА

Язык ДРАКОН имеет две опоры. Первая – математика. Вторая – психология, точнее, когнитивная эргономика. Именно эргономика позволяет сделать дракон-схемы изящными и доступными. При создании ДРАКОНа был использован научный подход к эргономизации конструкций языка.

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

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

С появлением дракон-схем разработка алгоритмов существенно облегчается.
ДРАКОН – качественно новый этап работы с алгоритмами.

СТАНЕТ ЛИ ДРАКОН ЧЕМПИОНОМ МИРА
ПО КРИТЕРИЮ «ПОНЯТНОСТЬ АЛГОРИТМОВ»?

Претензия ДРАКОНа на «мировое господство» ограничена. Он вступает в конкурентную борьбу только с императивными и процедурными языками (точнее, с императивно-процедурными частями языков). И только в том случае, когда понятность алгоритмов является главным требованием к языку. Тем, кто желает писать непонятные или трудные для понимания алгоритмы, ДРАКОН не нужен.

Требование удобопонятности алгоритмов все чаще выходит на передний план. Поэтому шансы ДРАКОНа на победу в конкурентной борьбе с другими языками растут.

ДРАКОН-КОНСТРУКТОР

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

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

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

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

ГДЕ СКАЧАТЬ ДРАКОН-КОНСТРУКТОР?

Ответ дан на стр. 414.

Не исключено, что к моменту выхода этой книги на сайтах «Визуальный язык ДРАКОН» http://drakon.su/,
«Алгоритмический язык ДРАКОН»
http://drakon-practic.ru/ и форуме http://forum.oberoncore.ru/viewforum.php?f=77

появится новая информация о разработке общедоступных инструментальных программ языка ДРАКОН.

См. также электронную энциклопедию «Википедия», статья ДРАКОН.

Как связаться с автором?
Электронная почта: vdp2007@ bk.ru
Тел. 8 (495) 331-50-72
8 (495) 535-34-13

Здравствуйте, a_g_99, Вы писали:

LVV>>Знает тот, кто делает (с)
__>Кто умеет, делает; кто не умеет, учит других. (с)
Вот именно!
Учить вы не умеете, а беретесь судить о преподавании.
А писать программы в 60 лет вы умеете?
LVV>>Значит, так учили. Или сам учился.
__>Система учила и получился возможно умный но не образованный человек. А мог бы быть образованным.
У нас таких нет. Наши — все умеют и образованные.
LVV>>UML вначале тоже только три человека делали.
__>UML прошел полный путь от идеи до международного признания и стандартизации за 10 лет. А известность получил через 5 лет после старта. А сколько вы говорите дракон жив? 20-30 лет?
Проектирование Бурана — секретность была большая.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Уважаемые коллеги!
Все же мне хочется получить ответ на свой вопрос.
Re: Язык ДРАКОН — новая идея в программировании

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, LaptevVV, Вы писали:

LVV>Учить вы не умеете, а беретесь судить о преподавании.
Вы абсолютно правы учить я не умею, тут каждому свое. Но я сталкиваюсь с современным продуктом образования и могу судить о его качестве, а следовательно о качестве преподавания этого образования. И когда преподающий мне, как человеку из индустрии, для которой готовится этот продукт (специалист), сообщает что рисование это хорошо, это приоритет, мне становится смешно. Специалист должен понимать суть мат. аппарата и основные cs-алгоритмы, он должен выражать их куцым математическим языком формул и алгоритмов. А блок-схемы и подобные рисуночки пусть чертят на кафедре художников.
Меня кстати поражает тот факт, как в своем подавляющем большинстве (не касается нескольких вузов и пары мат. институтов) российская система образования упорно пытается превратить студента в идиота. Креативный подход.
LVV>А писать программы в 60 лет вы умеете?
Мне не 60 лет, но писать программы я умею. Надеюсь, что хорошо. Уверен когда мне будет 60 я буду делать это еще лучше.

LVV>У нас таких нет. Наши — все умеют и образованные.
Чьи это ваши? Прямо интересно стало

LVV>Проектирование Бурана — секретность была большая.
Ну да. Кровавая гэбня зарубила такой язычище. Просто плакать от смеха хочется

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, LaptevVV, Вы писали:

LVV>>Учить вы не умеете, а беретесь судить о преподавании.
__>Вы абсолютно правы учить я не умею, тут каждому свое. Но я сталкиваюсь с современным продуктом образования и могу судить о его качестве, а следовательно о качестве преподавания этого образования. И когда преподающий мне, как человеку из индустрии, для которой готовится этот продукт (специалист), сообщает что рисование это хорошо, это приоритет, мне становится смешно. Специалист должен понимать суть мат. аппарата и основные cs-алгоритмы, он должен выражать их куцым математическим языком формул и алгоритмов. А блок-схемы и подобные рисуночки пусть чертят на кафедре художников.
1. Насчет приоритета — вы передергиваете.
2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...

И это составляет ЧАСТЬ профессиональных знаний разработчика.
Так же как теория графов — тоже ЧАСТЬ тех же самых знаний.
__>Меня кстати поражает тот факт, как в своем подавляющем большинстве (не касается нескольких вузов и пары мат. институтов) российская система образования упорно пытается превратить студента в идиота. Креативный подход.
Система может и пытается, а мы, наоборот, стараемся из идитота сделать специалиста...

LVV>>А писать программы в 60 лет вы умеете?
__>Мне не 60 лет, но писать программы я умею. Надеюсь, что хорошо. Уверен когда мне будет 60 я буду делать это еще лучше.
Если только вам не надоест и вы не уйдете в управленцы...

LVV>>У нас таких нет. Наши — все умеют и образованные.
__>Чьи это ваши? Прямо интересно стало

Наши выпускники — нашей каферы.
LVV>>Проектирование Бурана — секретность была большая.
__>Ну да. Кровавая гэбня зарубила такой язычище. Просто плакать от смеха хочется
Попалчьте — это иногда бывает сильно полезно...

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

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

Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.

On 23/05/12 23:31, Владимир Паронджанов wrote:

> Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат.

Мне все таки кажется, что будущее — за дешкомпьютерами

https://www.google.com/search?q=%D0%B4%D0%B5%D1%88%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80

Posted via RSDN NNTP Server 2.1 beta

C>Всё просто и эргономично!
Внимательно почитал. Там в стандартной библиотеке Turbo Dragoon Ergonomic Lib есть расширение:

ИМХО, так эргономичнее.

Здравствуйте, LaptevVV, Вы писали:

LVV>1. Насчет приоритета — вы передергиваете.
Нисколько. Просмотрите свои предыдущие посты. Вы там пытались доказать что рисуночки студент воспримет лучше чем мат. аппарат, а следовательно мертворожденное дряхлое дитя советской околонаучной деятельности именуемой дракон (что за бредовое название ))?) имеет смысл, будет расти и пахнуть.
LVV>2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...

Угу, и PowerPaint и фотошоп. И лист бумаги. Вы только не прояснили чем лист бумаги хуже дракона.
LVV>Наши выпускники — нашей каферы.
Самое страшное для выпускников вашей кафедры, это то что они будут знать слово "дракон", но не будут знать классический курс CS. И когда они придут устраиваться на работу, над ними просто посмеются.

Салют

Здравствуйте, vl690001x, Вы писали:

V>Почему многие сразу принимаются за критику, толком не разобравшись?
Почему многие что-то придумавшие сразу принимаються за пропаганду, толком не разобравшись (чё же придумали)?
V>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
Причина банальна — человеку которому лень изучать что то уже существующее, проще придумать что то свою. Ведь когда это что то свою — то его не надо изучать, понимать что оно из себя представляет, оценивать насколько может конкурировать с аналогами и т.д.
V>Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию говном, а тех кто ее продвигают — недоучками.
Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию прорывов и будущем, а тех кто ее не продвигает — недоучками.
Но это нерационально с точки зрения здравого смысла, потому что разумно сначала изучить аналоги, выделить их недостатки и положительные черты, а уже потом делать что то новое, имеющее преимущества перед уже существующими технологиями.

V>Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык будет очень хорош для планшетов. А в дальнейшем я думаю появятся еще более революционные интерфейсы чем сенсорные пальце-ориентированные.
Не знаю ничего насчет именно языка ДРАКОН, слышал где-то (тут), подумал что это что-то ~~детское~~ бессмысленное, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык очень похож на обычные блок схемы. По ГОСТу. Которые придумали ещё до первых языков программирования. И от которых отказались. Для которых есть не одна реализация. И все реализации провалились. Что преимущества языка описаны детскими фразами "ввел термин эргономичность", "проще", "легче" и что это язык программирования для НЕпрограммистов.
И на планшеты мне кстати пофиг. И программировать в будущем я хочу не пальцами а мыслями. Ну или хотя бы голосом.

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

V>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
Так что я думаю, что язык ДРАКОН вероятно не имеет будущего, уже потому, что у него нет настоящего.

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, LaptevVV, Вы писали:

LVV>>1. Насчет приоритета — вы передергиваете.
__>Нисколько. Просмотрите свои предыдущие посты. Вы там пытались доказать что рисуночки студент воспримет лучше чем мат. аппарат, а следовательно мертворожденное дряхлое дитя советской околонаучной деятельности именуемой дракон (что за бредовое название ))?) имеет смысл, будет расти и пахнуть.
Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.
LVV>>2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...

__>Угу, и PowerPaint и фотошоп. И лист бумаги. Вы только не прояснили чем лист бумаги хуже дракона.
Не хуже. На листе бумаги можно нарисовать Дракон-схему, и UML-диаграмму...

LVV>>Наши выпускники — нашей каферы.
__>Самое страшное для выпускников вашей кафедры, это то что они будут знать слово "дракон", но не будут знать классический курс CS. И когда они придут устраиваться на работу, над ними просто посмеются.
Опять же — вы нифига не знаете про то, что изучают наши студенты, а делаете безапелляционные выводы.
Привет вашей логике...

Она даже на женскую не похожа...

Здравствуйте, WolfHound, Вы писали:

WH>Дракон-схема задает конечный автомат.

Да, это правильно. Дракон-схема задает конечный автомат. Но не только.

WH>Если задача не сводится к конечному автомату, то дракон работать перестает.

Нет, это неправильно. ДРАКОН позволяет описывать любые алгоритмы.

Уважаемый модератор WolfHound!

Если интересно, я могу переслать Вам по мейлу следующий материал (48 страниц, pdf):

Часть VII. Теоретические основы языка ДРАКОН ....................................425

Глава 34. Исчисление икон .......................................................427

Глава 35. Метод Ашкрофта-Манны и алгоритмическая структура «силуэт» .............436

Глава 36. Визуальный структурный подход к алгоритмам и программам (шампур-метод) 449

Здравствуйте, Cyberax, Вы писали:

C>Кстати, даже этот детский пример — неправильный.

C>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.

C>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.

Дык это потому, что всё на одной картинке. Вы мысленно переведите в текст (с которым мы привыкли), такое же безобразие получится. Далее вы разделите на разные функции и вуаля. Ну так и тут можно перерисовать в "иди на рыбалку, рыбачь, иди домой", где "рыбачь" — "проверь наживку, кидай, жди" ну и так далее.
Правда, смысла я в этом всём всё равно не вижу, но ваши придирки все не потому, что ДРАКОН не тот, а потому что пример уродливый.

Здравствуйте, LaptevVV, Вы писали:

LVV>Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.

Это неверный вывод. Правильно будет — в опросах, девушки отвечают, что лучше воспринимают схемы, а парни отвечают, что лучше воспринимают псевдокод. Это далеко не то же самое.

Здравствуйте, Владимир Паронджанов, Вы писали:

WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.
ВП>Нет, это неправильно. ДРАКОН позволяет описывать любые алгоритмы.
Это правильно. Теоретически можно всё на brainfuck'е написать — так как он Тьюринг-полный. Но практически — достаточно посмотреть на его название.

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

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, LaptevVV, Вы писали:

LVV>>Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.

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

Но опрос был спонтанным, никтьо о нем заранее не знал. Просто в один день пришла в голову такая мысль — спросить, кому как проще воспринимать объяснение алгоритма.

Здравствуйте, LaptevVV, Вы писали:

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

LVV>Но опрос был спонтанным, никтьо о нем заранее не знал. Просто в один день пришла в голову такая мысль — спросить, кому как проще воспринимать объяснение алгоритма.

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

Здравствуйте, Курилка, Вы писали:

К>проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?

Да, есть. В драконе есть аналоги структурных диаграмм UML (диаграмм поведения). Если говорить более точно:

Аналогом дракон-схем служат диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).

Другим аналогом дракон-схем являются блок-схемы алгоритмов, диаграммы Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.

Здравствуйте, Cyberax, Вы писали:

C>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?
Я помню. Помню, что роза рациональная, и что она синоним абракадабрской жопы. У жопы и розы общее то, что количество букв одинаково

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, LaptevVV, Вы писали:

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

LVV>>Но опрос был спонтанным, никтьо о нем заранее не знал. Просто в один день пришла в голову такая мысль — спросить, кому как проще воспринимать объяснение алгоритма.

DR>Без исследования, опрос это всего лишь опрос. Другой вывод, который из него можно сделать, это что девушки больше склонны отвечать то, что преподаватель хочет услышать (experimenter's bias). Или, что девушки более внушаемы и после курса по схематическому программированию уверены, что нашли серебряную пулю. Или, что студенты отвечают согласно сложившимся стереотипам.
1. Про девушек — это все понятно.
2. У нас нет курса по схематическому программированию.

Здравствуйте, roro, Вы писали:

C>>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
R>Если новые состояния переключаются event`ом будет только одна точка входа wait_events -> process.
R>Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.
Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.

C>>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
R>Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
Чем нагляднее? Я тут не увидел ни одной реальной диаграммы кроме кривых детских примеров.

C>>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
R>Вот не надо, установить tcp соединение это уже стейт-машина примитивная.
И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?

Здравствуйте, WolfHound, Вы писали:

WH>Просто пойми одну простую вещь: Решения задачи в терминах предметной области, которая не имеет ничего общего с КА ...

Я согласен с Вами, что решение задачи в терминах предметной области — это хорошо.

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

Здравствуйте, Владимир Паронджанов, Вы писали:

WH>>Дракон-схема задает конечный автомат.
ВП>Да, это правильно. Дракон-схема задает конечный автомат. Но не только.
За счет вызовов она умеет задавать КА со стеком. А что еще?

WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.
ВП>Нет, это неправильно. ДРАКОН позволяет описывать любые алгоритмы.
Еще раз. Полнота по Тьюрингу меня не волнует.
Меня волнует решение задачи в терминах предметной области.
Ибо только так можно достичь максимальной выразительности.

ВП>Если интересно, я могу переслать Вам по мейлу следующий материал (48 страниц, pdf):
Не интересно. Ибо КА приемлемы в очень малом наборе задач.
Мне интересно как на драконе будет выглядеть аналог кода на даталоге.
Или аналог EBNF грамматики.
Или SQL запрос.
Я могу продолжать этот список очень долго.

Поймите я не против ДРАКОНА. И возможно буду использовать его, если мне понадобится, чтобы не программисты описывали что-то что сводится к КА.
Но вы должны понять, что область применения ДРАКОНА очень узкая. И он не может быть эффективен в очень широком классе задач.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>На Драконе задачи прекрасно решаются в терминах предметной области. На работе я организую работу именно таким образом.
Только если предметная область сводится к КА.
А если нет, то все становится печально.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Cyberax, Вы писали:

V>>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
C>Имеет — в качестве посмешища.

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

Здравствуйте, vl690001x, Вы писали:

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

V>Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык будет очень хорош для планшетов. А в дальнейшем я думаю появятся еще более революционные интерфейсы чем сенсорные пальце-ориентированные.
V>В конечном итоге, возможно что управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд. При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах.

Уже сейчас всё гораздо круче: большая часть идей, которые зарождаются у людей в голове, заранее существует в виде формальных схем, инсталируемых в головы через зомбоящик.

V>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.

Хороший стёб

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, roro, Вы писали:

C>>>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
R>>Если новые состояния переключаются event`ом будет только одна точка входа wait_events -> process.
R>>Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.
C>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.

Можно пример, в каком месте вывернет?

C>>>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
R>>Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
C>Чем нагляднее? Я тут не увидел ни одной реальной диаграммы кроме кривых детских примеров.

Диаграммы тут обобщенные, но хорошо иллюстрируют подход к проблеме.

Например так создают AI и постановочные сцены в популярных игровых движках.

Kismet редактор в Uneral Engine.
Flow Graph Editor редактор в CryEngine 3.

Вообще, прочитав статью у меня прошла ассоциация с комбинациями в Го и сохранением рисунка игры (захватом территории).

Знаю что без фреймворка или dsl писать сложные поведения и fsm на c/c++/java/c# то еше удовольствие. А ревьюить без знания кода практически невозможно, только в случае если кто-то будет подсказывать что делает тот или другой кусок кода.

Некоторое время баловался Debugger Canvas, достаточно удобно. Если в таком-же стиле сделать редактор дракона, да с отладкой схем.
И еше добавить уровни:
1 Большие логические модули
2 Подпрограммы
3 Низкоуровневые алгоритмы

И придумать как это все сгруппировать и отобразить )

C>>>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
R>>Вот не надо, установить tcp соединение это уже стейт-машина примитивная.
C>И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?

Тут наверно недопонимание, имел ввиду что простая установка соединения уже требует отслеживания состояния сокета. тоесть работать с сокетом можно только в connected состоянии, при состоянии error нужно переподключится итд..., я в этом вижу стейт машину

Здравствуйте, vl690001x, Вы писали:

V>Почему многие сразу принимаются за критику, толком не разобравшись?
Опытны.
V>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
Или просто уже знают, что это.

V>Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию говном, а тех кто ее продвигают — недоучками.
V>Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское,
Это не детское. Это очень похожи на блок схемы которые я изучал в школе. Задания были домашние: нарисовать блок схему такого-то алгоритма. Такие схемы подходят для написания коротких и не очень сложных программ и алгоритмов. Полезны в самом начале изучения программирования. Ну, может и не в самом начале, не в третьем классе, когда ученикам дают задание нарисовать путь черепашки в тетради в клеточку диктуя сколько шагов в какую сторону света сделала черепашка, но где-то после этого...

Теперь смотрим, что пишут счастливые пользователи:

И только когда весь алгоритм «отлизан» — переходим к собственно программированию. В чём оно теперь заключается? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка. На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.

Вот я сейчас подсчитал, в одном небольшом проекте, над которым я работаю сейчас 254845 строчек кода. Ну а теперь представьте себе схему с таким количеством иконок. Как думаете их среда разработки выдержит размер поля в 50400х35280 пикселей? (примерно столько понадобится для отрисовки такого количества иконок)

Ну да, большие программы нужны не везде. Но может ли, к примеру, эта разработка выдавать код на JavaScript ? Сомневаюсь.

Вот что нужно современному программисту здесь:

существует ли софт, который умеет эмулировать выполнение некоторого кода в многопоточной среде так, чтоб была возможность задать кол-во потоков/точки_входа, и по финалу, создавать граф вызовов или еще какую-нить диаграмму ?

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.
Как быстро Вы сдали назад. Я освежу вашу весьма короткую преподавательскую память вашей первой цитатой:
"Как препод могу сказать, что некоторым студентам и почти всем студенткам гораздо проще посмотреть на картинку алгоритма, чем на текст алгоритма. Для рисования сложных алгоритмов Дракон подходит как нельзя лучше."

LVV>Привет вашей логике...

Она даже на женскую не похожа...

У вас не осталось аргументов и вы решили перейти к оскорблениям? Достойное поведение для преподавателя

, продолжайте в том же духе

. Так вы привлечете просто массы неистовых поклонников к Дракону

.

Смотришь на все это, а потом безучастно читаешь на CNN ньюса о том, что очередной спутник Третьего Рима (а четвертому как известно не быть

) бороздит просторы океана, или устраивает фейерверк в атмосфере. Наверное также чьи студенты познали Новые Идеи В Программировании от мастеров-преподавателей

Уважаемые коллеги!

В этом сообщении речь пойдет о семействе ДРАКОН-языков.
То есть о гибридных языках.
А также о структурах данных.

ГИБРИДНЫЕ ЯЗЫКИ ДРАКОН-СЕМЕЙСТВА

ГРАФИЧЕСКИЙ И ТЕКСТОВЫЙ СИНТАКСИС ДРАКОНА

ДРАКОН – графический (визуальный) язык, в котором используются два типа элементов:

• графические фигуры (иконы),
• текстовые надписи, расположенные внутри или снаружи икон (текс-
тоэлементы).

Следовательно, синтаксис ДРАКОНа распадается на две части.

Графический (визуальный) синтаксис охватывает алфавит икон, правила их размещения в поле чертежа и правила связи икон с помощью соединительных линий. Графический синтаксис описан в главе 33.

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

Оператор языка ДРАКОН — это икона или комбинация икон, взятые вместе с текстовыми надписями.

Одновременное использование графики и текста говорит о том, что ДРАКОН адресуется не только к словесно-логическому мышлению автора и читателя алгоритма. Сверх того, он активизирует интуитивное, образное, правополушарное мышление, стимулируя его не написанным, а именно нарисованным алгоритмом, то есть алгоритмом-картинкой.

§12. СЕМЕЙСТВО ДРАКОН-ЯЗЫКОВ

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

Каждый гибридный язык семейства отличается тем, что имеет свой собственный текстовый синтаксис.

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

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

§13. КАК ПОСТРОИТЬ ГИБРИДНЫЙ ЯЗЫК
ПРОГРАММИРОВАНИЯ В ОБЩЕМ СЛУЧАЕ?

Чтобы построить гибридный язык, нужно выполнить 5 шагов.

Шаг 1. Выбрать целевой язык (например, язык Си).

Шаг 2. Использовать графический синтаксис языка Дракон в качестве графического синтаксиса гибридного языка Дракон-Си.

Шаг 3. Использовать синтаксис целевого языка (синтаксис языка Си) в качестве текстового синтаксиса гибридного языка Дракон-Си.

Шаг 4. Удалить из текстового синтаксиса гибридного языка Дракон-Си все элементы, которые заменяются управляющей графикой ДРАКОНа.

Шаг 5. Создать транслятор из дракон-схемы в исходный код языка Си.

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

При использовании гибридных языков исходным текстом программы считается дракон-схема и только она.

Пример. Предположим, пользователь работает в связке Дракон-конструктор – Транслятор Дракон-Си – Keil. Понятно, что исходником служит дракон-схема. При отладке программы не следует вносить исправления в промежуточные текстовые Си-файлы. Все исправления нужно вносить в исходный код, то есть в дракон-схему.

Петр Приклонский сообщает:

«Я уже больше года работаю на связке Дракон-конструктор – DrakonToC – Keil. И ни в коем случае не позволяю себе править промежуточные текстовые Си-файлы. Исходник – это дракон-схема!» [1]
§14. ДВА ЭТАПА РАЗВИТИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

С точки зрения человеческого фактора, в истории развития языков программирования можно выделить два этапа.

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

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

Это позволит отказаться от текстовых управляющих структур, используемых в языках высокого уровня, и заменить их на управляющую графику Дракона.

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

§15. ПЛАН РАЗВИТИЯ И ЧАСТИЧНОЙ УНИФИКАЦИИ
ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

Опыт использования языка Дракон и гибридных языков позволяет предложить план развития и частичной унификации языков высокого уровня из трех пунктов.

1. Использовать графический синтаксис языка Дракон в качестве
стандарта, позволяющего осуществить частичную унификацию
языков высокого уровня.

2. Текстовый синтаксис следует заимствовать из целевого языка. При
этом следует удалить все элементы текстового синтаксиса, которые
заменяются управляющей графикой Дракона.

3. Преобразовать языки высокого уровня в гибридные языки.
Как показывают первые опыты подобной работы, переход от языков
высокого уровня к гибридным языкам программирования свидетельствует о заметном повышении производительности труда программистов.

§16. ВЫВОДЫ

1. Язык Дракон можно присоединить к некоторым языкам программирования и получить так называемые гибридные языки:

язык Дракон + язык Си = гибридный язык Дракон-Си

язык Дракон + язык Дельфи = гибридный язык Дракон-Дельфи

язык Дракон + язык Джава = гибридный язык Дракон-Джава

язык Дракон + язык Си# = гибридный язык Дракон-Си#

язык Дракон + язык Питон = гибридный язык Дракон-Питон

язык Дракон + язык Перл = гибридный язык Дракон-Перл

язык Дракон + язык Руби = гибридный язык Дракон-Руби

язык Дракон + язык Ада = гибридный язык Дракон-Ада

язык Дракон + язык Tcl = гибридный язык Дракон-Tcl

язык Дракон + язык Оберон = гибридный язык Дракон-Оберон

язык Дракон + язык Ассемблер = гибридный язык Дракон-Ассемблер

и т. д.

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

> Что это даст? Исходный код программы станет еще более понятным и удобным для человека. И, следовательно, еще больше увеличится производительность труда программистов.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>фух, дело бредогенераторов живет и процветает, так и хочется взять канделябр и отдубасить этого кулибина легко и непринужденно... тьфу...

Уважаемый grosborn!

У меня просьба. Если Вас не очень затруднит, изложите Ваши возражения более подробно и желательно с аргументацией.

Спасибо.

Здравствуйте, roro, Вы писали:

C>>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.
R>Можно пример, в каком месте вывернет?
Предлагается линейный императивный алгоритм переписать в событийно-управляемый. Читать про сопрограммы и прочее.

R>>>Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
C>>Чем нагляднее? Я тут не увидел ни одной реальной диаграммы кроме кривых детских примеров.
R>Диаграммы тут обобщенные, но хорошо иллюстрируют подход к проблеме.
Да.

R>Например так создают AI и постановочные сцены в популярных игровых движках.
Не так. AI в играх пишется на старом добром С++ или других языках. Графически только расставляются всякие инициаторы и прочее (дык, а как это делать по-другому?).

R>Kismet редактор в Uneral Engine.

Ага.

R>Flow Graph Editor редактор в CryEngine 3.
И?

R>Вообще, прочитав статью у меня прошла ассоциация с комбинациями в Го и сохранением рисунка игры (захватом территории).
И?

R>Знаю что без фреймворка или dsl писать сложные поведения и fsm на c/c++/java/c# то еше удовольствие. А ревьюить без знания кода практически невозможно, только в случае если кто-то будет подсказывать что делает тот или другой кусок кода.
И?

R>Некоторое время баловался Debugger Canvas, достаточно удобно. Если в таком-же стиле сделать редактор дракона, да с отладкой схем.
R>И еше добавить уровни:
R>1 Большие логические модули
R>2 Подпрограммы
R>3 Низкоуровневые алгоритмы
Это всё умели делать Rational Rose и Together. Оба сдохли заслуженной смертью.

C>>И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?
R>Тут наверно недопонимание, имел ввиду что простая установка соединения уже требует отслеживания состояния сокета. тоесть работать с сокетом можно только в connected состоянии, при состоянии error нужно переподключится итд..., я в этом вижу стейт машину
И дальше что? Возьми реальный код TCP-стека (я даже помогу — вот он: http://lxr.free-electrons.com/source/net/ipv4/tcp.c ) и посмотри на объём кода в нём. State-машина там теряется в объёме реальной работы, которую надо делать при установке соединения.

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

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

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

Posted via RSDN NNTP Server 2.1 beta

> У меня просьба. Если Вас не очень затруднит, изложите Ваши возражения более подробно и желательно с аргументацией.

Вызов на демагогическую дуэль? Как ожидаемо.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Что ж, 124 страницы это фигня, можно сказать начало, старт проекта. Видимо это кропотливая ручная работа, поэтому ждем трехтомника всяческих новых фундаментальных понятий. А если наскучит, можете заказать у меня в этом стиле стотомник, я когда студентом был баловался генераторами.

Корчеватель — тоже ты?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Здравствуйте, Курилка, Вы писали:

К>>проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?

ВП>Да, есть. В драконе есть аналоги структурных диаграмм UML (диаграмм поведения). Если говорить более точно:

ВП>

ВП>Аналогом дракон-схем служат диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).

ВП>Другим аналогом дракон-схем являются блок-схемы алгоритмов, диаграммы Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.

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

> G>Что ж, 124 страницы это фигня, можно сказать начало, старт проекта. Видимо это кропотливая ручная работа, поэтому ждем трехтомника всяческих новых фундаментальных понятий. А если наскучит, можете заказать у меня в этом стиле стотомник, я когда студентом был баловался генераторами.
>
> Корчеватель — тоже ты?

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, LaptevVV, Вы писали:

LVV>>Передергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.
__>Как быстро Вы сдали назад. Я освежу вашу весьма короткую преподавательскую память вашей первой цитатой:
__>"Как препод могу сказать, что некоторым студентам и почти всем студенткам гораздо проще посмотреть на картинку алгоритма, чем на текст алгоритма. Для рисования сложных алгоритмов Дракон подходит как нельзя лучше."
И где здесь сдача назад?

Мы провели опрос — результаты я озвучил. Разве что в первом сообщении не написал, что мы спрашивали.

LVV>>Привет вашей логике...

Она даже на женскую не похожа...

__>У вас не осталось аргументов и вы решили перейти к оскорблениям? Достойное поведение для преподавателя

, продолжайте в том же духе

. Так вы привлечете просто массы неистовых поклонников к Дракону

.
Прошу извинить, если чем обидел.
Но на женскую логику ваша абсолютно не похожа...

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Даю ссылку на Краткое описание языка ДРАКОН. Всего 124 страницы. Много рисунков.
ВП>О космических кораблях нет ни слова. Все примеры очень простые, бытового характера.
ВП>http://drakon-practic.ru/drakon.pdf
Предположим, Драконом пользуются для написания реальных программ
Несколько вопросов:
1) Системы контроля версий. Насколько удобно сделать diff между произвольными ревизиями кода?;
2) Насколько удобно закомментировать какую ветку или часть кода, насколько легко это все вынести в отдельную процедуру?;
3) Книгу я просмотрел очень мельком, все примеры там бытового характера. А вот в реальности насколько удобно рисовать эти диаграмки? Отображают ли эти диаграмки полностью структуру программы с полной детализацией, или же за детализацией нужно нажимать кучу клавиш, переменные скрыты и размазаны, и чтоб реально понять что как работает, придется очень сильно потрудиться?

Спрашиваю это все потому, что визуальными средствами написания программ я пользовался на практике и в реальных проектах. И могу сказать, что обплевался. Простейшие рефакторинги делать крайне затруднительно. На диаграмме не все, чтобы увидеть детали, надо нажимать на прямоугольник и смотреть проперти. А если детализация ого-го, то схема крайне перегружена и ее хрен разберешь. Дополнительно, пока какой управляющий блок набьешь, проклянешь все на свете. diff ни хрена ни сделать — если что работало, кто то что то поменял, и работать перестало, хрен докопаешься до причины. Перед использованием всего этого требуется проходить черти какой инструктаж, ибо куча неочевидных моментов.
Я видел кучу рекламных роликов о том, что вот, наконец то, появился новый язык, программисты не нужны, специалисты в предметной области сами все напишут. И в 100 процентах случаев заканчивалось тем, что приходится привлекать программистов, несмотря на наглядность читаемого представления, эти программисты страшно матерятся, тратят в 10 раз больше времени, а также программистов требуется в 10 раз больше. Ибо кроме того, что это все крайне неудобно использовать на практике, еще и среда разработки страшно глючит, а также при малейшем отклонении от идеального эталонного сценария приходится делать такие извраты и макароны, что появляется желание уйти в запой с горя. А если в самом начале в какой либо переменной допустил орфографическую ошибку — все, это уже практически не исправить. Средств рефакторинга нет, чтобы выделить процедуру, нужно ее рисовать с нуля. Даже переменную переименовать проблема, приходится реплейсить внутреннее представление этой схемки, никому не говоря, ибо это запрещено. В результате, учитывая то, что рефакторить крайне затруднительно, на практике код очень быстро превращается в черти какие макароны, когда на одной схеме тысячи стрелочек и блоков, налезающих друг на друга.

PS Относительно новых идей в программировании — мне понравилось вот это. Это действительно то, чтобы мне хотелось видеть. Но рисование программы визуально в виде аналогов блок схем (неважно — UML это, DFD или дракон схемы) — это очень старая идея, которая себя не оправдала, а пытались это реализовать наверно тысячи фирм.

Здравствуйте, Трололоша, Вы писали:

Т>Мммм. Будет вкусно!

Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

Здравствуйте, vdimas, Вы писали:

Т>>Мммм. Будет вкусно!
V>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.
Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.

Здравствуйте, a_g_99, Вы писали:

__>А вот в штатах бедолаги не знают и все на UML рисуют. И инструментов там — тьма тьмущая. И все довольны.

У них до UML вообще единых стандартов графических обозначений для ПО не было. Наш ГОСТ их обгонял на десятилетия.

__>И как это так получилось что какой-то там дракон вдруг стал лучше uml-кубиков?

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

Здравствуйте, Cyberax, Вы писали:

C>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?
Розу я до конца жизни не забуду. Помню как поставил, мне в результате перетерлись все MSXML библиотеки, в результате полсистемы перестало работать. Когда то (больше 10 лет назад) верил, что типа такие мегафирмы не могут сделать лажу, а за визуальным программированием действительно будущее. Ладно б одна фирма и единичный случай, а я таких мегавизуальных средств с генерацией кода из сверхпонятнейших диаграмм видел минимум 5. А то и все 10 и более, если считать случаи, когда предоставляют сверхпонятный язык, позволяющий программировать просто аналитикам, а всех программистов поувольнять. По мне, так лучше уж на брейнфаке все писать, для него хоть кодогенератор можно написать с нормального языка и забыть про все ужасы этой визуальщины.

Здравствуйте, WolfHound, Вы писали:

WH>Дракон-схема задает конечный автомат.
WH>Если задача не сводится к конечному автомату, то дракон работать перестает.

При наличии рекурсий — в магазинный, т.е. превращается в машину Тьюринга.

Здравствуйте, WolfHound, Вы писали:

WH>Если задача не сводится к конечному автомату, то дракон работать перестает.

И кстати, конечные автоматы, по моему наблюдению, даются современным программистам сложнее всего. А тут такая "халява".

Здравствуйте, WolfHound, Вы писали:

ВП>>На Драконе задачи прекрасно решаются в терминах предметной области. На работе я организую работу именно таким образом.
WH>Только если предметная область сводится к КА.
WH>А если нет, то все становится печально.

По твоей ссылке предметной областью являлся компилятор с DSL. Разработка такого компилятора — вполне себе автоматная задача.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>У меня просьба. Если Вас не очень затруднит, изложите Ваши возражения более подробно и желательно с аргументацией.
Я уже излагал.
Но их проигнорировали.
Datalog, SQL, EBNF,... и много что еще на дракон не ложатся. Совсем.
Что делает дракон применимым только в очень ограниченном классе задач, которые решаются конечными автоматами.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, мы исходим из того, что они говорят правду. Конечно, можно наворотить целое психологическое исследование...

Простите, но вы собственно психологическое исследование и провели. Никакого ответа про понятность видов представления

Правильный вариант был бы такой: разделить студентов на N групп и дать им ознакомиться с неким алгоритмом (например, балансировка AVL-дерева). Каждой из N групп дают алгоритм в одном из видов:
— текстовое описание
— псевдокод
— блок-схема
— схема на Драконе

Затем все группы сдают какой-нибудь тупой тест на понимание описанного алгоритма. Строго один и тот же. Ну там — воспроизвести алгоритм для конкретных входных данных, или ответить на вопрос типа "в каких случаях алгоритм делает то-то", или "какова сложность алгоритма в терминах O-нотации относительно размера входных данных".
Так, чтобы можно было убедиться, что студент реально понял алгоритм.

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

А вы ничего не измерили.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, roro, Вы писали:

C>>>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.
R>>Можно пример, в каком месте вывернет?
C>Предлагается линейный императивный алгоритм переписать в событийно-управляемый. Читать про сопрограммы и прочее.

В случае монопольного использования процесса не вижу проблем.
Если имитировать конкурентное исполнение то да

но тут больше вопросов к реализации чем к представлению

R>>Например так создают AI и постановочные сцены в популярных игровых движках.
C>Не так. AI в играх пишется на старом добром С++ или других языках. Графически только расставляются всякие инициаторы и прочее (дык, а как это делать по-другому?).

Можно сделать вполне достойный "умный" уровень, описать его на тригерах и bahvaior tree, все необходимые компоненты доступны из редактора.

В CryEngine допустим добавляем солдата на карту.
У него есть события "вижуВрага", "слышуВрага" вешаем на них тригер "включить серену" и "бежать в координату X,Y,Z".
На событие "сработала сирена" вешаем "spawn 10 десантников в координате X,Y,Z".
Присваиваем десантникам group id и если один из членов групы "вижуВрага" -> оповестить("group id","атаковать врага id").

Собственно таким способом можно сделать не хуже чем на С++.

В менее мощных редакторах MOD-мэйкеры, умудряются имитировать массивы и переменные.
Расставляют невидимые объекты на карте, кодируют адрес обьекта координатами (X,Y), значения типом объекта (танк=1 мотоцикл=2)
Не исключено что какой нибудь умелец таким образом небольшой автомат или граф закодировал.

R>>Вообще, прочитав статью у меня прошла ассоциация с комбинациями в Го и сохранением рисунка игры (захватом территории).
C>И?

В коде этого не видно. Конечно callgraph в проекте бывает откроешь на проблемной функции и "емана*от" ассоциация, но это совсем не то.

C>Это всё умели делать Rational Rose и Together. Оба сдохли заслуженной смертью.
С продуктами Rational вообще печальный опыт работы. Это какие-то рабские галеры а не серебряные пули.

C>>>И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?
R>>Тут наверно недопонимание, имел ввиду что простая установка соединения уже требует отслеживания состояния сокета. тоесть работать с сокетом можно только в connected состоянии, при состоянии error нужно переподключится итд..., я в этом вижу стейт машину
C>И дальше что? Возьми реальный код TCP-стека (я даже помогу — вот он: http://lxr.free-electrons.com/source/net/ipv4/tcp.c ) и посмотри на объём кода в нём. State-машина там теряется в объёме реальной работы, которую надо делать при установке соединения.

Меньший процент относительно общего кода не делает state-машину ненужной или менее важной. По мне так это даже хорошо, чем меньше логики тем проще и надежнее.

C>Я понимаю, у наивных авторов, которые не писали ни строчки реального кода, установка TCP соединения, видимо, будет в виде диаграмки в полстранички.

И это хорошо

Тема case программирования и ее роль в обществе меня если честно мало интересует.
Более интересно создание графических DSL-ей и описание алгоритмов визуально.

Здравствуйте, roro, Вы писали:

C>>Предлагается линейный императивный алгоритм переписать в событийно-управляемый. Читать про сопрограммы и прочее.
R>В случае монопольного использования процесса не вижу проблем.
R>Если имитировать конкурентное исполнение то да

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

R>>>Например так создают AI и постановочные сцены в популярных игровых движках.
C>>Не так. AI в играх пишется на старом добром С++ или других языках. Графически только расставляются всякие инициаторы и прочее (дык, а как это делать по-другому?).
R>Можно сделать вполне достойный "умный" уровень, описать его на тригерах и bahvaior tree, все необходимые компоненты доступны из редактора.
И?

R>Собственно таким способом можно сделать не хуже чем на С++.
Нельзя.

R>В менее мощных редакторах MOD-мэйкеры, умудряются имитировать массивы и переменные.
R>Расставляют невидимые объекты на карте, кодируют адрес обьекта координатами (X,Y), значения типом объекта (танк=1 мотоцикл=2)
R>Не исключено что какой нибудь умелец таким образом небольшой автомат или граф закодировал.
Тут кое-кто сделал эмулятор процессора 6502 в Майнкрафте.
http://hackaday.com/2012/05/20/building-a-6502-in-minecraft/
И графический калькулятор там же: http://www.youtube.com/watch?v=wgJfVRhotlQ

Что неудивительно — сделать Тьюринг-полную систему элементарно. Вопрос о том, чтобы сделать её УДОБНОЙ для программиста.

R>В коде этого не видно. Конечно callgraph в проекте бывает откроешь на проблемной функции и "емана*от" ассоциация, но это совсем не то.
Прекрасно видно. Я нажимаю Find Usage и вижу кто там меня вызывает — в виде простого списка.

Callgraph реально неудобен, если в нём хотя бы пара уровней вложенности.

C>>Это всё умели делать Rational Rose и Together. Оба сдохли заслуженной смертью.
R>С продуктами Rational вообще печальный опыт работы. Это какие-то рабские галеры а не серебряные пули.
И так со ВСЕМИ графическими средами.

C>>И дальше что? Возьми реальный код TCP-стека (я даже помогу — вот он: http://lxr.free-electrons.com/source/net/ipv4/tcp.c ) и посмотри на объём кода в нём. State-машина там теряется в объёме реальной работы, которую надо делать при установке соединения.
R>Меньший процент относительно общего кода не делает state-машину ненужной или менее важной.
Делает. Так как в РЕАЛЬНОЙ жизни получится или 5 квадратиков с 10 килобайтами кода в каждом, или 1000 квадратиков, образующих Ктулху.

R>По мне так это даже хорошо, чем меньше логики тем проще и надежнее.
Ага. Потому никаких реальных программ на ДРАКОНе и не было написано. И не будет.

Здравствуйте, LaptevVV, Вы писали:

LVV>2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...

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

Здравствуйте, Курилка, Вы писали:

К>>>проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?

ВП>>Да, есть. В драконе есть аналоги ~~структурных~~ диаграмм UML (диаграмм поведения). Если говорить более точно:
Уважаемый Курилка, Вы правы. Слово "структурный" я зачеркнул.

ВП>>Аналогом дракон-схем служат диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).

ВП>>Другим аналогом дракон-схем являются блок-схемы алгоритмов, диаграммы Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.

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

К>Интересно всё ж услышать ответ на мой вопрос

1. Слово "структурный" я удалил.

2. Прошу прощения, в Ваш текст вкралась опечатка. Вы пишите: "диаграммы поведения ~~НЕ являются структурными диаграммами, а~~ являются одним из вариантов диаграмм взаимодействия". В действительности все наоборот: диаграммы взаимодействия являются одним из вариантов диаграмм поведения.

3. В драконе есть средства для работы в реальном времени, поэтому упомянута диаграмма синхронизации (timing diagram).

Здравствуйте, LaptevVV, Вы писали:

LVV>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
И какой из этого следует вывод, учитывая, что в разработке 99% мужчин? Типа заставим мужчин помучиться, чтоб одному проценту жилось получше? Как по мне, эта только что приведенная статистика — хороший аргумент за то, чтобы ни при каких обстоятельствах не заниматься визуализацией алгоритмов, ибо визуализация наоборот будет затруднять понимание для тех, кто реально будет этим заниматься. Или кто думает, что переход на блок схемы привлечет в отрасль женский пол? Спешу огорчить — не привлечет, для привлечения нужно не на блок схемы переходить, а подход к воспитанию мадемуазелей менять.

Здравствуйте, roro, Вы писали:

R>В CryEngine допустим добавляем солдата на карту.
R>У него есть события "вижуВрага", "слышуВрага" вешаем на них тригер "включить серену" и "бежать в координату X,Y,Z".
R>На событие "сработала сирена" вешаем "spawn 10 десантников в координате X,Y,Z".
R>Присваиваем десантникам group id и если один из членов групы "вижуВрага" -> оповестить("group id","атаковать врага id").

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

Здравствуйте, Cyberax, Вы писали:

C> До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?

Я розу помню, у меня сертификат. Такой ужас трудно забыть

avalon 1.0rc3 build 428, zlib 1.2.3

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Здравствуйте, Курилка, Вы писали:

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

К>>Интересно всё ж услышать ответ на мой вопрос

ВП>1. Слово "структурный" я удалил.

Если вы это сделали в уме (т.к. на форуме никакого удаления НЕТ) и пытаетесь при этом вести диалог, то я пас

ВП>2. Прошу прощения, в Ваш текст вкралась опечатка. Вы пишите: "диаграммы поведения ~~НЕ являются структурными диаграммами, а~~ являются одним из вариантов диаграмм взаимодействия". В действительности все наоборот: диаграммы взаимодействия являются одним из вариантов диаграмм поведения.

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

ВП>3. В драконе есть средства для работы в реальном времени, поэтому упомянута диаграмма синхронизации (timing diagram).

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

ЧЕТЫРЕ ВИДЕОУРОКА НА YOUTUBE
по 15 минут каждый

Программирование на языке Дракон для микроконтроллеров

Автор ИС Дракон Геннадий Тышов
Автор уроков Сергей Ефанов

К каждому уроку прилагается курс молодого бойца

Урок 1

Программа управления дверным замком.
Разработка алгоритма и программы. Простейший случай.
http://www.youtube.com/watch?v=Ua9dUUONjdk&feature=related

Урок 2

Программа управления дверным замком.
Функции нижнего уровня. Проект. Компиляция. Прошивка процессора.
http://www.youtube.com/watch?v=zeIq_JQhYSI&feature=related

Урок 3

Программа управления дверным замком.
Редактирование алгоритма
http://www.youtube.com/watch?v=Sp6AMGzTM78&feature=related

Урок 4

Программа управления дверным замком.
Настройка таймеров. Производственный алгоритм
http://www.youtube.com/watch?v=1PWDuPeJ_bk&feature=related

Здравствуйте, Cyberax, Вы писали:

R>>Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.
C>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот я сейчас подсчитал, в одном небольшом проекте, над которым я работаю сейчас 254845 строчек кода. Ну а теперь представьте себе схему с таким количеством иконок. Как думаете их среда разработки выдержит размер поля в 50400х35280 пикселей? (примерно столько понадобится для отрисовки такого количества иконок)

А что мешает организовать иерархию?

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

Здравствуйте, Cyberax, Вы писали:

V>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.
C>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.

Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Можно ли устранить этот недостаток? Можно ли облегчить жизнь алгоритмистов и программистов? И поднять производительность их труда? Да, можно.

ВП>Изюминка в том, что Дракон — очень легкий язык. Необыкновенно легкий.

здесь ?

Здравствуйте, elmal, Вы писали:

E>Предположим, Драконом пользуются для написания реальных программ
E>Несколько вопросов:
E>1) Системы контроля версий. Насколько удобно сделать diff между произвольными ревизиями кода?;

Это вопрос не к языку, а к реализации. Существующие реализации этого пока не умеют.

E>2) Насколько удобно закомментировать какую ветку или часть кода, насколько легко это все вынести в отдельную процедуру?;

Это возможно и удобно.

E>3) Книгу я просмотрел очень мельком, все примеры там бытового характера. А вот в реальности насколько удобно рисовать эти диаграмки?

Сами диаграммки высокого качества. Удобство рисования зависит от реализации (инструментальных средств). Сегодня доступны две реализации: Тышова и Митькина. К ним у пользователей есть претензии. Но они постоянно совершенствуются.

E>Отображают ли эти диаграмки полностью структуру программы с полной детализацией, или же за детализацией нужно нажимать кучу клавиш, переменные скрыты и размазаны, и чтоб реально понять что как работает, придется очень сильно потрудиться?

Посмотрите видео и составьте свое мнение. Язык позволяет, а реализация пока не всегда совершенна.

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

Понимаю Вас.

E>А если детализация ого-го, то схема крайне перегружена и ее хрен разберешь.

На Драконе перегрузки нет. Используется продуманная система декомпозиции.

E>Дополнительно, пока какой управляющий блок набьешь, проклянешь все на свете. diff ни хрена ни сделать — если что работало, кто то что то поменял, и работать перестало, хрен докопаешься до причины. Перед использованием всего этого требуется проходить черти какой инструктаж, ибо куча неочевидных моментов.

E>Я видел кучу рекламных роликов о том, что вот, наконец то, появился новый язык, программисты не нужны, специалисты в предметной области сами все напишут. И в 100 процентах случаев заканчивалось тем, что приходится привлекать программистов, несмотря на наглядность читаемого представления, эти программисты страшно матерятся, тратят в 10 раз больше времени, а также программистов требуется в 10 раз больше. Ибо кроме того, что это все крайне неудобно использовать на практике, еще и среда разработки страшно глючит, а также при малейшем отклонении от идеального эталонного сценария приходится делать такие извраты и макароны, что появляется желание уйти в запой с горя. А если в самом начале в какой либо переменной допустил орфографическую ошибку — все, это уже практически не исправить. Средств рефакторинга нет, чтобы выделить процедуру, нужно ее рисовать с нуля. Даже переменную переименовать проблема, приходится реплейсить внутреннее представление этой схемки, никому не говоря, ибо это запрещено. В результате, учитывая то, что рефакторить крайне затруднительно, на практике код очень быстро превращается в черти какие макароны, когда на одной схеме тысячи стрелочек и блоков, налезающих друг на друга.

На Драконе никакие макароны В ПРИНЦИПЕ не возможны.

Я четко сознаю, что не ответил на Ваши вопросы. На такие вопросы нельзя ответить словами.
Надо предъявлять рабочий инструмент. Так что могу сказать одно — посмотрите видео.

В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА), то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.

Здравствуйте, vdimas, Вы писали:

V>>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.
C>>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.
V>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.

Никаких независимых подтверждений его слов нет. Так же как и вообще известного софта или работающих реализаций самого языка.

Здравствуйте, Владимир Паронджанов, Вы писали:

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Программирование на языке Дракон для микроконтроллеров
Что следующее?

"Программирование светофора"?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Посмотрите видео и составьте свое мнение. Язык позволяет, а реализация пока не всегда совершенна.
Посмотрел. Как я и ожидал — диаграмки являются по существу комментариями, отражающими структуру кода, а не детали. А чтобы посмотреть детали — нужно нажимать на прямоугольничек и откроется область кода. Напомнило все до боли Rational Rose. Соответственно — на диаграмке может все казаться правильно, а в реализации можно элементарно ошибиться. А чтоб реально быть уверенным, что все правильно, нужно долго и очень внимательно смотреть именно что результирующий код. Который несколько далек от идеала благодаря автогенерации.

ВП>На Драконе перегрузки нет. Используется продуманная система декомпозиции.
Угу, самые важные детали (а как же именно мы реализовываем отключение компаратора, как пример) скрываются и на диаграмме не видны. А на практике при рефакторинге мы можем случайно в реализации вместо отключения компаратора послать команду на запуск маршевых двигателей. А если их там показывать — схема разрастется до огромных размеров, либо потребуется делать дикую декомпозицию и постоянно переключать внимание между различными диаграммами.

ВП>На Драконе никакие макароны В ПРИНЦИПЕ не возможны.
Макароны возможны всегда! Это не зависит от языка, от методологии! Или просто сложность одной процедуры ограничена определенными размерами? Все равно не спасет, ибо можно что угодно запутать глобальными переменными, связями все со всем.

ВП>Надо предъявлять рабочий инструмент. Так что могу сказать одно — посмотрите видео.
Видео посмотрел. До боли напомнило все Rational Rose. Точнее даже не ее, а какое то другое CASE средство 1998 года.

ВП>В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА), то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.
Во первых, сложный алгоритм из 100 000 строк составлять не нужно никогда! Ибо это явно для гениев с IQ под 1000. Люди же со скромным IQ 200 делают декомпозицию и составляют набор простых слабо связанных алгоритмов. По поводу понятности. Хорошо — пусть будут Дракон схемы для визуализации алгоритмов! Непонятно, чем он лучше других подобных языков, вроде UML, но ладно — предположим что по наглядности визуализации Дракон лучший. Так вот, чтоб этой понятностью реально пользоваться, нужно наоборот все делать! Нужно сначала реализовывать алгоритм на любом языке, помечать его соответствующими комментариями, и на основании комментариев и исходного текста путем реверс инжинеринга визуализировать Дракон схемы, добиваясь того, чтобы было все читабельно. Делать такую поддержку для всех языков и всех известных сред разработки через плагины. В этом случае какие то перспективы есть.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот я сейчас подсчитал, в одном небольшом проекте, над которым я работаю сейчас 254845 строчек кода. Ну а теперь представьте себе схему с таким количеством иконок. Как думаете их среда разработки выдержит размер поля в 50400х35280 пикселей? (примерно столько понадобится для отрисовки такого количества иконок)

Я, хоть и не вникал в Дракон вовсе, но почему0то уверен, что там среду делали не идиоты, и предусмотрели иерархию детализации а-ля IDEF.

Здравствуйте, elmal, Вы писали:

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

Не могу с Вами согласиться. По моему мнению, оптимальным является путь: сначала графика — потом преобразование в код.
Я опираюсь на свой производственный опыт.

Язык ДРАКОН используется в НПЦАП в виде Технологии разработки алгоритмов и программ "Графит-Флокс". Технология используется во многих крупных ракетно-космических проектах с 1996 года:
http://drakon.su/_media/biblioteka/grafit_a4.pdf

Слева — работают инженеры. Справа — программисты.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Не могу с Вами согласиться. По моему мнению, оптимальным является путь: сначала графика — потом преобразование в код.
ВП>Я опираюсь на свой производственный опыт.
Если это опыт в виде космических проектов — возможно именно для таких проектов это и оптимально. Но космическая отрасль весьма и весьма специфична. Например там требования не меняются, сначала идет составление документации, и очень подробное, затем реализация (не работал в этой отрасли, но по крайней мере про подобное слышал неоднократно, причем эта отрасль даже у буржуев весьма и весьма специфична). Соответственно такие вещи, как рефакторинг, не очень актуальны. Но в 99% случаев программирование предполагает совершенно другую методологию разработки, когда требования постоянно меняются прямо во время реализации, когда время выхода на рынок крайне критично, когда документация и техзадание весьма скудная, часто к моменту начала разработки вообще никто не знает что реально нужно сделать, и к требуемому результату приходят методом проб и ошибок. И постоянное изменение требований — это неизбежность, от этого невозможно отказаться! Если откажешься, то пока сделаешь — продукт будет уже не нужен со старыми требованиями. И вот для таких проектов подход, когда сначала графика, а потом преобразование в код, является полностью не применимым. Вернее даже так — многие пытаются такое применять. Но итог у всех один — многократное затягивание времени разработки и раздутие штатов в результате такого подхода.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Не могу с Вами согласиться. По моему мнению, оптимальным является путь: сначала графика — потом преобразование в код.
ВП>Я опираюсь на свой производственный опыт.
Позвольте охарактеризовать его как отставший минимум на 30 лет от современного состояния индустрии.

ВП>Язык ДРАКОН используется в НПЦАП в виде Технологии разработки алгоритмов и программ "Графит-Флокс". Технология используется во многих крупных ракетно-космических проектах с 1996 года:
ВП>http://drakon.su/_media/biblioteka/grafit_a4.pdf
ВП>Слева — работают инженеры. Справа — программисты.
"Передача дискеты в отдел программистов". Мда. Я бы постеснялся такие слайды показывать вообще (кроме как при обсуждении истории).

Здравствуйте, rusted, Вы писали:

R>Здравствуйте, roro, Вы писали:

R>>В CryEngine допустим добавляем солдата на карту.
R>>У него есть события "вижуВрага", "слышуВрага" вешаем на них тригер "включить серену" и "бежать в координату X,Y,Z".
R>>На событие "сработала сирена" вешаем "spawn 10 десантников в координате X,Y,Z".
R>>Присваиваем десантникам group id и если один из членов групы "вижуВрага" -> оповестить("group id","атаковать врага id").

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

Я привел примерный порядок действий которые нужно выполнить.
Создавать такие скрипты в редакторе не райское удовольствие, но для пользователя который не знаком с lua/angelscipt и sdk, других вариантов нету.

CryEngine позорно падает когда редактирую AIPath, привожу пример на UE3

Здравствуйте, Владимир Паронджанов, Вы писали:

Помимо неоднократно уже озвученной критики графического представления алгоритмов по сравнению с текстовой, хочется вставить и свои 5 копеек.

1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции, управления сложностью и пр. оставлено за кадром.

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

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

3) Обучаемость и преемственность. Все хорошие специалисты учились писать и читать код и алгоритмы текстом. Все признанные "классики" (Кнут, Ахо-Ульман, и др) пишут свои примеры на псевдокоде, и не графическими средствами. Подрастающее поколение, которые через 5-10 лет вырастут в "ведущие", сейчас пишут и читают код традиционными средствами. И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.

Ну и на-последок

4) Традиционный подход доказал свою состоятельность. Написаны миллионы программ и алгоритмов, подчас сложнейших. Может ли "ДРАКОН" похвастать сложными программами, разработанными с применением его парадигмы? Как буду выглядеть на нем классические алгоритмы, в тексте записываемые в 10-15 строчек? (Сортировки, LZ, балансировки деревьев)?

Уважаемый Евгений Пасынков!

X>1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции ... оставлены за кадром.

Это не так. Вопросы декомпозиции проработаны очень подробно и тщательно.

Даю выдержку из книги 2012 года. Книга доступна. В ней 520 страниц. Все изложено подробнейшим образом.

§8. ВЫВОДЫ

1. Головной алгоритм – это алгоритм самого верхнего уровня на лест-
нице декомпозиции.

2. Головной алгоритм может содержать вставки (вызываемые проце-
дуры). Но сам он не может быть вставкой для алгоритма более вы-
сокого уровня.

3. Головной алгоритм – это всегда силуэт. Он не может быть прими-
тивом или системой примитивов.

4. Для создания головного алгоритма используют:

• метод эргономичной декомпозиции;
• метод многостраничного силуэта.

5. Головной алгоритм может быть:

• одностраничным силуэтом;
• многостраничным силуэтом.

6. Одностраничный силуэт размещается на одном листе бумаги (на
одном экране).

7. Многостраничный силуэт размещают на нескольких листах бума-
ги. При работе с экраном силуэт прокручивают по горизонтали.

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

9. Силуэт – главное достоинство языка ДРАКОН. Он обладает мощ-
ными выразительными средствами.

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

11. На практике силуэт используют в подавляющем большинстве слу-
чаев.

12. Примитив применяют редко, скорее как исключение.

13. Тем не менее, отказываться от примитива не следует, так как он ну-
жен для описания малых алгоритмов.

14. Кроме того, примитив полезен из педагогических соображений.
Основные понятия и правила ДРАКОНа удобно объяснять на самой простой модели.
То есть на примитиве. И только после этого
переходить к рассказу о силуэте.

Здравствуйте, vdimas, Вы писали:

V>На разбор чужого кода в тексте запросто могут уйти часы, а в графике — всегда считанные минуты.

Да, да, конечно.

Здравствуйте, Ops, Вы писали:

Давайте подумаем вместе. Что именно доказывает Ваша графика?

1. Графика бывает хорошая и плохая.

2. Вы привели привер ПЛОХОЙ графики.

3. Дракон-схема — это ХОРОШАЯ графика.

4. Так что Ваш пример "не стреляет".

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование
Больше подходит название: Язык Динозавр. Как раз для тех кто из старой советской школы, не смог переучиться вовремя и перейти от блок-схем и чертежей, на языки программирования.

Здравствуйте, elmal, Вы писали:

ВП>>В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА, то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.

E>Во первых, сложный алгоритм из 100 000 строк составлять не нужно никогда! Ибо это явно для гениев с IQ под 1000.

Так было вчера, когда еще не было Дракона. Дракон коренным образом меняет ситуацию. Дракон без труда превращает НЕПОНЯТНОЕ в ПОНЯТНОЕ.
Ваш тезис говорит о том, что до появления Дракона Человечество не имело средств для изображения ПОНЯТНЫХ сложных алгоритмов.

E>Люди же со скромным IQ 200 делают декомпозицию и составляют набор простых слабо связанных алгоритмов.

Дракон помогает Вам в этом. И заодно снижает требования к IQ с 200 до 120 или даже до 100.

Здравствуйте, Ops, Вы писали:

Тут приводили пример составления программы для контроллера замка. Была показана схема контроллера замка. Схема элементарная в графическом виде, вопринимается в среднем за 1-5 мин. Не покажешь пример записи этой схемы в текстовом виде? В общем, это будет нечитаемый нет-лист на полторы сотни строк, который просто описывает компоненты и связи. Прямо как в типичной бизнес-логике программы. Т.е. обычный, плоховоспринимаемый текстовый мусор. Разбираться в таком — от часа. Искать ошибки — от дня.

Здравствуйте, Cyberax, Вы писали:

C>>>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.
V>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.

С чего ты взял?

C>Никаких независимых подтверждений его слов нет.

Пол-но и уже относительно давно.

C>Так же как и вообще известного софта или работающих реализаций самого языка.

Что такое "работающая реализация"?

Здравствуйте, Курилка, Вы писали:

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

Будет ошибкой сравнивать неполноценный UML, с полноценным языком. Тут высказался.

К>Если есть проблемы с тем, что есть структурные диаграммы, можно посмотреть хотяб вики.

Детсад как он есть.

Здравствуйте, xvost, Вы писали:

X>1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции, управления сложностью и пр. оставлено за кадром.

Ровно наоборот. Любой набор схем — это в первую очередь декомпозиция, иерархия и описание связей м/у уровнями.

X>2) Предложенный подход, по сути, является еще одной записью императивного подхода. Оно с той или иной степенью "хорошести" ложится на алгоритмические проблемы, однако никак не подходит к функциональному-, компонентному-,

Замечательно подходит. Курить dataflow.

X>мета-программированию,

Дракон — это мета-программирование само по себе. Другое мета-программирование будет другим, иногда принципиально другим. В том-то и дело, что метапрограммирование — это всегда некий трюк по выходу на новую степень абстракций. Графика — это лишь один из таких трюков, работающий из-за "врожденной" иерархичности элементов.

X>и пр., т.е. всему тому что составляет разработку современного ПО "в большом".

Современый мейнстрим — это императив и ничего кроме имератива. Остальное существует постольку-постольку.

X>Но все это можно было бы пережить. и применять для разработки конкретных алгоритмов, если бы не

X>3) Обучаемость и преемственность. Все хорошие специалисты учились писать и читать код и алгоритмы текстом.

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

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

и ты это как-то сдавал... Экзамен же не покупал, надеюсь?

X>Все признанные "классики" (Кнут, Ахо-Ульман, и др) пишут свои примеры на псевдокоде, и не графическими средствами.

У Кнута и Фаулера непрофильное образование.

У Кнута понятно почему, непонятно почему у Фаулера...

X>Подрастающее поколение, которые через 5-10 лет вырастут в "ведущие", сейчас пишут и читают код традиционными средствами.

Подрастающее поколение выходит из ВУЗов все менее и менее образованным, т.е. разговор ни о чем.

X>И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.

Ерунда. Современный программист не видит своей работы без элементов графического представления, таких как:
— иерархия проекта (пакетов/неймспейсов)
— иерархия классов
— статистика вызовов и использований
— диаграммы вызовов (графы) профайлеров
— графы веток систем контроля версий
— и т.д. до бесконечности.

Никакое текстовое представление графа не заменит графическое. А деревья — это лишь разновидность графов.

X>4) Традиционный подход доказал свою состоятельность.

Традиционный подход — это графика и текст совместно в любой документации:

Не понимаю, почему у некоторых чешется обязательно противопоставлять одно другому. Графические среды — это лишь попытка заполнить пропасть м/у документацией и целевым продуктом. Нормальное, ИМХО, желание.

Здравствуйте, vdimas, Вы писали:

V>Потому что UML — это НЕ язык программирования. Это язык абстракций. На нем не напишешь полноценную программу. А на Драконе — напишешь.
Как это не напишешь? Ты Rational Rose видел? Тоже самое, рисуем диаграмки, внутри квадратиков набираем код (тоже скрытый), нажимаем generate — и вуаля, если все правильно то, что нагенерил, даже скомпилится. У меня в студенческие годы получалось. Дракон — крайне похожая концепция, только диаграмки другие. А если брать LabView — там даже генерить ничего не надо, там с помощью квадратиков можно написать полноценную программу. И там тоже есть средства декомпозиции, если что. Еще есть Scratch и BYOB.
Вот на нишу Scratch в принципе замахнуться можно попробовать, то есть применять язык в обучении студентов. Возможно даже выйдет что толковое из этого, ибо Дракон, насколько я видел, поощряет так называемое wishful thinking — если этому наконец будут учить студентов с первых курсов, наконец студенты будут учиться программированию в институте, а не на работе (а многие и на работе так и не осиливают все это). Только надо так среду дорабатывать, чтобы его можно было использовать в качестве первого языка, чтоб что то осмысленное вроде hello world или пляски каких либо спрайтов под музыку можно было написать интуитивно, не читая документацию и не просматривая видео.
Да, кстати — очень бы хотелось увидеть пример реализации быстрой сортировки на Драконе. Крайне хочется оценить понятность.

Здравствуйте, Владимир Паронджанов, Вы писали:

X>>1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции ... оставлены за кадром.

ВП>Это не так. Вопросы декомпозиции проработаны очень подробно и тщательно.

Структурная декомпозиция — вещь, известная примерно 50 лет. Это был прорыв в разработке ПО тех лет.

Однако индустрия не стоит на месте. И экспериментально давно доказано, что структурная декомпозиция работает хорошо ТОЛЬКО на микро-уровне, т.е. в пределах одного алгоритма или связки 2-3 алгоритмов.

А дальше — ООП, аспекты, компоненты, мета-... и прочее.

ВП>Даю выдержку из книги 2012 года. Книга доступна. В ней 520 страниц. Все изложено подробнейшим образом.

Ничего нового

Здравствуйте, vdimas, Вы писали:

X>>2) Предложенный подход, по сути, является еще одной записью императивного подхода. Оно с той или иной степенью "хорошести" ложится на алгоритмические проблемы, однако никак не подходит к функциональному-, компонентному-,
V>Замечательно подходит. Курить dataflow.

И что — кто-то в графическом виде оперирует с dataflow больше чем 20-30 узлов? Не верю.

V>Дракон — это мета-программирование само по себе. Другое мета-программирование будет другим, иногда принципиально другим. В том-то и дело, что метапрограммирование — это всегда некий трюк по выходу на новую степень абстракций. Графика — это лишь один из таких трюков, работающий из-за "врожденной" иерархичности элементов.

Слова знакомые, а мысль от меня ускользает....

Я, по свей наивности, всегда считал мета-программированием то, что выполняется на этапе компиляции.

X>>и пр., т.е. всему тому что составляет разработку современного ПО "в большом".
V>Современый мейнстрим — это императив и ничего кроме имератива. Остальное существует постольку-постольку.

Да ну. JavaBeans — классический компонентный подход.
Stateless servlets — классическая функциональщина, хоть и записываемая в императивном стиле

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

Я этого не учил

Непрофильное образование

0101 — Мат.Анализ.

X>>Подрастающее поколение, которые через 5-10 лет вырастут в "ведущие", сейчас пишут и читают код традиционными средствами.
V>Подрастающее поколение выходит из ВУЗов все менее и менее образованным, т.е. разговор ни о чем.

Я говорил не про ВУЗы. Я говорил про обучение в сильных командах.

X>>И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.
V>Ерунда. Современный программист не видит своей работы без элементов графического представления, таких как:
V>- иерархия проекта (пакетов/неймспейсов)
V>- иерархия классов
V>- статистика вызовов и использований
V>- диаграммы вызовов (графы) профайлеров
V>- графы веток систем контроля версий
V>- и т.д. до бесконечности.

МОЛОДЕЦ!
Все твои примеры — это СЛЕДСТВИЕ кода (т.е. взгляд на код под разными углами), но ни как не его ПРИЧИНА.

Я очень даже поддерживаю различные диаграммы и графики. Но, посмотрев на них и сделав выводы, возвращаюсь к ТЕКСТУ для изменения.

X>>4) Традиционный подход доказал свою состоятельность.
V>Традиционный подход — это графика и текст совместно в любой документации:
V>Не понимаю, почему у некоторых чешется обязательно противопоставлять одно другому. Графические среды — это лишь попытка заполнить пропасть м/у документацией и целевым продуктом. Нормальное, ИМХО, желание.

До тех пор пока графы и диаграммы помогают понять код — "you'r welcome"!
Как только пытаются в эти графы запихать ВСЮ программу,и обязать ее модифицировать тоже через графическое представление — fail.

Здравствуйте, elmal, Вы писали:

E> ... применять язык в обучении студентов. Возможно даже выйдет что толковое из этого, ибо Дракон, насколько я видел, поощряет так называемое wishful thinking — если этому наконец будут учить студентов с первых курсов ...

Применение языка ДРАКОН в системе высшего образования

В 1996 году Государственный комитет по высшему образованию Российской Федерации включил изучение языка ДРАКОН в программу курса «Информатика» для направлений:

510000 — Естественные науки и математика
540000 — Образование
550000 — Технические науки
560000 — Сельскохозяйственные науки

Даю ссылку на официальный документ
http://drakon.su/_media/biblioteka/progr_drakon.pdf

В официальном документе Госкомвуза «Примерная программа дисциплины „Информатика“» имеется раздел, посвященный языку ДРАКОН и использующий его понятийный аппарат:

Раздел 3. АЛГОРИТМЫ И АЛГОРИТМИЗАЦИЯ. ВИЗУАЛИЗАЦИЯ АЛГОРИТМОВ

Понятие алгоритма и алгоритмической системы. Визуализация алгоритмов и блок-схемы. Недостатки традиционных блок-схем. Формализация и эргономизация блок-схем. Язык визуального представления алгоритмов ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность).

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

Понимаемость алгоритмов и методы её улучшения. Понятие эргономичного алгоритма. Равносильные преобразования визуальных алгоритмов, позволяющие улучшить их понимаемость: рокировка, подстановка, вертикальное и горизонтальное объединение, визуализация логических формул в условных операторах.

Две формы представления алгоритмов: визуальная и текстовая. Визуальные и текстовые языки и псевдоязыки. Преобразование алгоритмов из визуальной формы в текстовую и обратно. Преимущества визуальной формы. Анализ визуальных алгоритмов методом застывших условий. Язык абстрактных ДРАКОН-схем как инвариант класса процедурных языков.

В документе Госкомвуза «Примерная программа дисциплины „Информатика“» содержится обоснование концепции и структуры учебного курса информатики и, в частности, дается обоснование использования языка ДРАКОН:

1. Среди требований, предъявляемых к современным алгоритмическим языкам, на первое место все чаще выходит понимаемость (comprehensibility) алгоритмов и программ, которая определяется как «свойство программы минимизировать интеллектуальные усилия, необходимые для её понимания»[16] Это объясняется тем, что «в современных условиях качественная программа должна обладать, помимо надежности и эффективности, ещё и такими важнейшими качествами как понимаемость и сопровождаемость»[70]

Наиболее мощным средством для улучшения понимаемости является визуализация алгоритмов и программ: «общепризнанно, что человеческий мозг в основном ориентирован на визуальное восприятие, и люди получают информацию при рассмотрении графических образов быстрее, чем при чтении текста»[71]…

2. … В связи с этим тема «алгоритмы и алгоритмизация» (см. раздел 3 программы) излагается в рамках визуальной парадигмы, что позволяет получить ряд преимуществ: облегчить изучение темы, улучшить эргономические характеристики алгоритмов и т. д.

3. Синтез идей информатики и эргономики полезен тем, что процесс алгоритмизации (который во многих случаях требует значительных трудозатрат) становится менее трудоемким и более ясным. Для этого вводится понятие «эргономичный алгоритм». Излагаются равносильные преобразования алгоритмов, способные улучшить их эргономические характеристики. При этом алгоритмизация и программирование рассматриваются как частный случай более общей проблемы — систематизации, структуризации, представления и формализации человеческих знаний[72]

4. Сближение понятий «алгоритм» и «процедурное знание» дает возможность расширить понятие алгоритма и распространить его на любые технологии (промышленные, сельскохозяйственные, медицинские, образовательные и т. д.[73] Это позволяет в эргономически разумных пределах формализовать описание технологий с помощью визуального алгоритмического языка. В результате описание техпроцессов становится более наглядным и четким, освобождается от пробелов и двусмысленностей. Такой подход обещает заметный выигрыш. Во-первых, благодаря наглядности сокращаются сроки и трудоемкость изучения современных технологий, что особенно важно в рамках концепции непрерывного образования. Во-вторых, формализация и полнота описания техпроцесса может содействовать укреплению технологической дисциплины на производстве и в других областях.

5. Для решения столь масштабных задач нужен универсальный язык представления процедурных знаний в любой предметной области. Это должен быть язык нового типа: общедоступный, человечный, предельно легкий в изучении и удобный в работе, создающий наиболее комфортные условия для человеческого мозга, позволяющий решать проблемы ценою минимальных интеллектуальных усилий, удовлетворяющий самым строгим эргономическим и дидактическим требованиям. Анализ показывает, что в наибольшей степени этим требованиям соответствует процедурный язык визуального представления знаний и визуального программирования ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность), являющийся обобщением опыта, накопленного при создании космического корабля «Буран»[74][75] ДРАКОН задуман как «один из самых легких языков представления знаний и самый первый язык, с которого нужно начинать обучение алгоритмическому мышлению и программированию»[76]

6. При коллективной интеллектуальной работе важную роль играет интеллектуальное взаимопонимание и интеллектуальное взаимодействие между специалистами. Для улучшения взаимопонимания необходимо иметь общую языковую основу. Благодаря своей человечности (эргономичности) язык ДРАКОН относительно легко устраняет барьеры взаимного непонимания (в части процедурных знаний) между работниками различных специальностей: врачами и физиками, математиками и конструкторами, биологами и экономистами, программистами и технологами и т. д. Тем самым ДРАКОН создает универсальную языковую основу для процедурного интеллектуального взаимодействия между людьми, в частности, между участниками многопрофильных проектов. В результате этот «язык взаимопонимания» заметно упрощает междисциплинарное и иное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий, отчасти играя роль «производственного эсперанто».

7. Бакалавр любой специальности должен уметь формализовать свои процедурные профессиональные знания самостоятельно, то есть без помощи профессиональных программистов или когнитологов (инженеров по знаниям). Программа предусматривает приобретение навыков автоформализации знаний на языке ДРАКОН.[77]

О дальнейшем развитии событий расскажу в отдельном сообщении.

Здравствуйте, vdimas, Вы писали:

V>>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.
V>С чего ты взял?
По его же слайдам. Тут уже выясняется, что ДРАКОН использовался не для создания кода, а спецификации, которая "на дискете" потом передавалась
реальным программистам.

C>>Никаких независимых подтверждений его слов нет.
V>Пол-но и уже относительно давно.
Неа. Я специально поискал. Они все либо ссылаются на ДРАКОНистов или не имеют никаких вторичных подтверждений.

Что как бэ намекает.

C>>Так же как и вообще известного софта или работающих реализаций самого языка.
V>Что такое "работающая реализация"?
Т.е. что-то, что не является картинкой на сайте.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>2. Вы привели привер ПЛОХОЙ графики.
ВП>3. Дракон-схема — это ХОРОШАЯ графика.
В 101 раз просим привести пример реального кода на ДРАКОНе.

Хотя бы в виде аналога десяти тысяч строк обычного кода. Это несколько месяцев работы обычного программиста на типичном коде.

А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, WolfHound, Вы писали:

WH>>Дракон-схема задает конечный автомат.
WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.

V>При наличии рекурсий — в магазинный, т.е. превращается в машину Тьюринга.

А с каких пор pushdown automaton эквивалентен машине Тьюринга?

Здравствуйте, xvost, Вы писали:

X>И что — кто-то в графическом виде оперирует с dataflow больше чем 20-30 узлов? Не верю.

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

V>>Дракон — это мета-программирование само по себе. Другое мета-программирование будет другим, иногда принципиально другим. В том-то и дело, что метапрограммирование — это всегда некий трюк по выходу на новую степень абстракций. Графика — это лишь один из таких трюков, работающий из-за "врожденной" иерархичности элементов.

X>Слова знакомые, а мысль от меня ускользает....
X>Я, по свей наивности, всегда считал мета-программированием то, что выполняется на этапе компиляции.

Нет, само мета-программирование выполняется на этапе его программирования программистом.

Метапрограммирование — это процесс расширения семантики имеющегося инструмента, чтобы программировать затем целевую задачу (нас же целевая задача в итоге интересует, правда?) в терминах этой расширенной семантики. Как пример — макросы Лиспа, immediate слова Форта или шаблоны С++ при использовании специализаций (частичных в т.ч.). А в графике — это определение новых графических примитивов, в том числе параметрических, которые можешь считать полными аналогами макросов. Т.е. инструментарий библиотек/модулей и инструментарий макросов в случае графического инструмента сливается в один и тот же инструментарий иерархических определений. Мы делали аналогичное еще на P-CAD почти 20 лет назад, определяя такие блоки-макросы частоиспользуемых сценариев.

X>>>и пр., т.е. всему тому что составляет разработку современного ПО "в большом".
V>>Современый мейнстрим — это императив и ничего кроме имератива. Остальное существует постольку-постольку.

X>Да ну. JavaBeans — классический компонентный подход.

Как это противоречит императивности Джавы?

X>Stateless servlets — классическая функциональщина, хоть и записываемая в императивном стиле

Это уж слишком с натяжкой, фактически с высоты птичьего полета. Просто состояние не выходит за рамки методов. Но это состояние описывается и изменяется явно именно в императивном стиле.

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

X>Я этого не учил

Непрофильное образование

0101 — Мат.Анализ.

Графы учили обязательно.

X>>>И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.
V>>Ерунда. Современный программист не видит своей работы без элементов графического представления, таких как:
V>>- иерархия проекта (пакетов/неймспейсов)
V>>- иерархия классов
V>>- статистика вызовов и использований
V>>- диаграммы вызовов (графы) профайлеров
V>>- графы веток систем контроля версий
V>>- и т.д. до бесконечности.

X>МОЛОДЕЦ!
X>Все твои примеры — это СЛЕДСТВИЕ кода (т.е. взгляд на код под разными углами), но ни как не его ПРИЧИНА.

Мде? А я думал, что код — это следствие того, как человек себе представляет решение проблемы. Т.е. мне казалось, что иерархия классов и пакетов не "получается сама собой из кода", а именно человек так иерархически разбивает решаемую задачу, что она превращается в итоге в графы, описывающие иерархию и связи своих составных частей.

Просто некий реверс-инженерный тул, типа вашего Решарпера, генерирует эти графы исключительно как СЛЕДСТВИЕ имеющегося кода, это дааа... сие неоспоримо. ))

X>Я очень даже поддерживаю различные диаграммы и графики. Но, посмотрев на них и сделав выводы, возвращаюсь к ТЕКСТУ для изменения.

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

X>>>4) Традиционный подход доказал свою состоятельность.
V>>Традиционный подход — это графика и текст совместно в любой документации:
V>>Не понимаю, почему у некоторых чешется обязательно противопоставлять одно другому. Графические среды — это лишь попытка заполнить пропасть м/у документацией и целевым продуктом. Нормальное, ИМХО, желание.

X>До тех пор пока графы и диаграммы помогают понять код — "you'r welcome"!
X>Как только пытаются в эти графы запихать ВСЮ программу,и обязать ее модифицировать тоже через графическое представление — fail.

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

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

Просто по сегодняшнему состоянию дел, графическое представление удобнее редактировать в тексте, но просматривать заетм таки в графике. Даже взять процесс банальной набивки HTML — 90% работы идет в исходнике, но 99% ревью — в результирующей графике.

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

Даже форматирование и отступы в исходниках — это натуральная графика для бедных. ))
Но эту графику уже давно делают графикой "для богатых": из блоков кода делают натуральный tree-view, который можно сворачивать/разворачивать, выделяют блоки текста цветом и т.д.

=====
Ну и ваши ГУИ-дизайнеры тоже не зря хлеб едят. Выделение кода не в виде строк, а в виде многогранной фигуры, где заливка и границы отличаются цветом (например, выделение текста в dotPeek) — это отличное графическое подспорье. А всего-навсего кусок текста превратили в натуральную графическую фигуру.

Здравствуйте, xvost, Вы писали:

X>Структурная декомпозиция — вещь, известная примерно 50 лет. Это был прорыв в разработке ПО тех лет.

Ничего новее в плане декомпозиций не придумали.

X>Однако индустрия не стоит на месте. И экспериментально давно доказано, что структурная декомпозиция работает хорошо ТОЛЬКО на микро-уровне, т.е. в пределах одного алгоритма или связки 2-3 алгоритмов.
X>А дальше — ООП, аспекты, компоненты, мета-... и прочее.

Вот это:

компоненты, мета-

Это и был результат "прорыва" еще 50 лет назад.
Про микро-уровень ты придумал. Структурная декомпозиция работает на любом уровне. Курить модульность.

А вот это:

ООП, аспекты

Абсолютно тоже самое, вид в профиль.
ООП/КОП — развитие модулей, аспекты — вообще не развитие ничего, на макросах делалось и так всегда, еще со времен ассемблера (для целей отладочной печати).

X>Ничего нового

Согласен. Вас надули.

Надули с "новизной" ООП и прочих ископаемых аспектов.

Здравствуйте, elmal, Вы писали:

V>>Потому что UML — это НЕ язык программирования. Это язык абстракций. На нем не напишешь полноценную программу. А на Драконе — напишешь.
E>Как это не напишешь? Ты Rational Rose видел? Тоже самое, рисуем диаграмки, внутри квадратиков набираем код (тоже скрытый), нажимаем generate — и вуаля, если все правильно то, что нагенерил, даже скомпилится. У меня в студенческие годы получалось.

Видел, делал, получалось неплохо только для объявления иерархий классов, т.е. для статики. Полноценный код так никто и не научился генерить. Искать ошибки в самом коде ДО генерения — тоже. Потому что UML не умеет. Есть несколько ОЧЕНЬ узких сценариев, где, например, по state chart что-то генерят... Но с таким колв-ом предопределенных соглашений, что похуже даже, чем в бизоне.

Ну и ты ерунду смотрел какую-то, дальше всех продвинулся в этом деле PD (Power Designer). Даже такая "мелочь" как обявление своих/произвольных паттернов в PD vs исопльзование встроенных в Розе, делает последнюю унылым Г. Роза хороша была лишь как подсказка к этапам RUP. Ну и Clear Case у них весчь, это да... А как генератор из UML в код — редкостный отстой. Малоизвестный Together на порядок мощнее был... Если бы он так безбожно не тормозил (что практически невозможно работать уже на проектах средней величины), то он мог бы стать популярным... а так не стал...

E>Дракон — крайне похожая концепция, только диаграмки другие.

Они богаче и полностью покрывают императивное программирование. Такие, казалось бы, мелочи. Отсутствующие в UML.

E>А если брать LabView — там даже генерить ничего не надо, там с помощью квадратиков можно написать полноценную программу.

Ну дык, смотря какую программу. Просто уже есть относительно много квадратиков-заготовок. Но ты можешь определять свои, аналогичные. ИМХО, это главное. Просто LabView не столько для программирования писался, сколько для макетирования. Ты можешь прогнать этот "код" в квадратиках и натравить кучу инструментов анализа на результаты. Начиная от любого сигнального анализа до статистики и даже ИИ.

E>И там тоже есть средства декомпозиции, если что.

А в графике без декомпозиции вообще никак. Иначе это будет каша.

E>Да, кстати — очень бы хотелось увидеть пример реализации быстрой сортировки на Драконе. Крайне хочется оценить понятность.

Императивная быстрая сортировка нетривиальная, в отличие от однострочных примеров на ML. Зато действительно быстрая. ))
Почему бы тебе не скачать среду и не построить эту блок-схему самому, в кач-ве небольшой разминки?

=============
Ей-богу уже стыдно за "студенческий" уровень обсуждения во всей этой теме.

Здравствуйте, WolfHound, Вы писали:

WH>Datalog, SQL, EBNF,... и много что еще на дракон не ложатся. Совсем.

Блин, ну ты даааал...

Как это SQL не ложится, если есть мильон существующих тулзов графического редактирования SQL?

Далее.
EBNF имеет графического близнеца — т.н. синтаксические диаграммы.

Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm
Похоже, ты ни разу в жизни не читал их документаций...

Пример синтаксической диаграммы:

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

Здравствуйте, WolfHound, Вы писали:

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

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

Здравствуйте, Cyberax, Вы писали:

C>"Передача дискеты в отдел программистов". Мда. Я бы постеснялся такие слайды показывать вообще (кроме как при обсуждении истории).

А чего тут стесняться? Бывают конторы, в которых радиусы сетевых соединений ограничены специально.

Здравствуйте, _DAle_, Вы писали:

_DA>А с каких пор pushdown automaton эквивалентен машине Тьюринга?

Ровно с тех пор, с каких машина Тьюринга эквивалентна PDA при подаче на нее заведомо конечной программы.

If we allow a finite automaton access to two stacks instead of just one, we obtain a more powerful device, equivalent in power to a Turing machine.

Фактически современные архитектуры оперируют 2-мя стеками: стеком возврата и стеком данных. Просто они размещаются физически вперемешку в одной области памяти. И дракон так же описывает вызов подпрограмм с параметрами. Выделенное курсивом оно и есть — машина Тьюринга.

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

Здравствуйте, vdimas, Вы писали:

V>Пример синтаксической диаграммы:
А можно то же самое в виде нормального EBNF?

V>Ну и я уже давным давно предлагал тебе скачать хотя бы два-три десятка тулзов для разработки компиляторов... просто посмотреть, где сейчас народ находится, а то вы малость застряли на сравнении с бизоном из 80-х... Во многих тулзах идет такое же или похожее редактирование синтаксических диаграмм.
Можно эти "многие тулзы"?

Здравствуйте, vdimas, Вы писали:

C>>"Передача дискеты в отдел программистов". Мда. Я бы постеснялся такие слайды показывать вообще (кроме как при обсуждении истории).
V>А чего тут стесняться? Бывают конторы, в которых радиусы сетевых соединений ограничены специально.
Я про всю методологию разработки.

Здравствуйте, Cyberax, Вы писали:

C>Я про всю методологию разработки.

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

Здравствуйте, Cyberax, Вы писали:

C>Я про всю методологию разработки.

А вообще, использование формального языка для постановки задачи — это на самом деле 5 баллов! Вы просто малость не в ту сторону смотрите и не то желаете там увидеть.

Здравствуйте, Cyberax, Вы писали:

C>А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.

Почему мучать? Свою первую более-менее сложную программу я расписал на 3-х листах в блок-схемах когда-то. И она сразу заработала. Просто у меня не было достаточно машинного времени на тот момент, чтобы позволить себе ее отладку часами... Я ее просто набил, исправил ошибки набора и она сразу заработала. А опыту было — 2 простых программы до этого (9-й класс, компы только несколько дней как в глаза увидел). В течении одного 45-минутного урока как раз успел набить программу по блок-схеме и поиграть в игру с друзьями. (это была игра Питон, которую случайно увидел на EC-терминале на экскурсии и захотелось в нее поиграть). Учитель информатики как увидел такой фокус... в общем, с тех пор у меня было неограниченное машинное время... ))

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП> ЧЕТЫРЕ ВИДЕОУРОКА НА YOUTUBE
ВП>по 15 минут каждый

Посмотрел 10 минут ролика. В чем отличие этой программы от LabView?

> ВП>2. Вы привели привер ПЛОХОЙ графики.
> ВП>3. Дракон-схема — это ХОРОШАЯ графика.
> В 101 раз просим привести пример реального кода на ДРАКОНе.
>
> Хотя бы в виде аналога десяти тысяч строк обычного кода. Это несколько месяцев работы обычного программиста на типичном коде.
>
> А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.

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

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

E>>Дракон — крайне похожая концепция, только диаграмки другие.
V>Они богаче и полностью покрывают императивное программирование. Такие, казалось бы, мелочи. Отсутствующие в UML.
Одно только но. Современное программирование давно не императивно. Оно является комбинацией ООП, функционального подхода, АОП, императивного, а также метапрограммирования.

V>А в графике без декомпозиции вообще никак. Иначе это будет каша.
Не в графике тоже без декомпозиции никак. Однако практика показывает, что даже в графике на декомпозицию часто забивают, предпочитая сделать ASAP, но жить с кашей. Кроме всего прочего — при реальном жизненном цикле программ постоянно требуется вносить изменения, доработки, которые не запланированы изначально и на которые не закладывались — и здесь тоже при типичной квалификации программистов получается каша, ибо быстро рефакторить мало кто умеет. Рефакторить на графических языках сложнее на порядок!

V>Императивная быстрая сортировка нетривиальная, в отличие от однострочных примеров на ML. Зато действительно быстрая. ))
V>Почему бы тебе не скачать среду и не построить эту блок-схему самому, в кач-ве небольшой разминки?
Даже нашел реализацию сам:
http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png
Куча состояний, внимание расфокусировано, рекурсию хрен заметишь.
Лично я никакого ускорения понимания не заметил. По сравнению с нормальной реализацией:
Псевдокод:

  function quicksort('array')
      if length('array') ≤ 1
          return 'array'  // an array of zero or one elements is already sorted
      select and remove a pivot value 'pivot' from 'array'
      create empty lists 'less' and 'greater'
      for each 'x' in 'array'
          if 'x' ≤ 'pivot' then append 'x' to 'less'
          else append 'x' to 'greater'
      return concatenate(quicksort('less'), 'pivot', quicksort('greater')) // two recursive calls

Реализация:

def quicksort(list, p, r)
    if p < r then
        q = partition(list, p, r)
        quicksort(list, p, q-1)
        quicksort(list, q+1, r)
    end
end
 
def partition(list, p, r)
    pivot = list[r]
    i = p - 1
    p.upto(r-1) do |j|
        if list[j] <= pivot
            i = i+1
            list[i], list[j] = list[j],list[i]
        end       
    end
    list[i+1],list[r] = list[r],list[i+1]
    return i + 1
end

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

Здравствуйте, elmal, Вы писали:

E>Даже нашел реализацию сам:
E>http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png
E>Куча состояний, внимание расфокусировано, рекурсию хрен заметишь.
Она еще и не по месту сортирует

Здравствуйте, elmal, Вы писали:

E>Лично для меня псевдокод и реализация читается и понимается на порядок легче.

Ничего для тебя не понимается вообще, в графике и в псевдокоде приведены разные реализации.

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

В твоем случае, хуже в бесконечное кол-во раз, бо деление на 0 дает бесконечность. Заплутать в 3-х соснах, это пять. ))

E>Те, кто блок схемы понимают лучше — те разработчиками не становятся обычно, они идут в тестеры, аналитики, менеджеры, HRы или вообще в домохозяйки.

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

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

Здравствуйте, vdimas, Вы писали:

C>>Я про всю методологию разработки.
V>Ну дык аналитеги рисуют постановку, требования и прочие умыльные юз-кейзы и передают разработчикам на условных дискетах... Та же фигня, вид в профиль. Слухи об устаревании подобной методологии, поверь, крайне преждевременны. От артефактов внутренней документации программисты не избавятся никогда, как бы им порой не хотелось обратного.
Дело в том, что ДРАКОН — это не язык разработки use-case'ов и для описания формальных требований он тоже не очень подходит.

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

Т.е. я совсем не против методологии, где инжинеры описывают формальные требования, по которым потом создаётся код. Но для этого надо иметь соответствующие инструменты. И самый главный из них — старый добрый текст. Диаграммы имеют смысл, но только для:
1) Иллюстрации общей структуры (т.е. иерархические диаграммы).
2) Диаграммы для КА (в различных формах).

Здравствуйте, grosborn, Вы писали:

G>Вообще-то на уровне школы это было бы нормально преподавать. Так сказать для базового уровня понимания. Однозначно лучше чем блок-схемы, даст понимание декомпозиции, раз уж это в драконе идея фикс. Ну и псевдоакадемические бездари в школе как бэ пусть себе будут, не страшно

Нет-нет-нет.

Как раз это прекрасный способ привить отвращение к программированию. Нас на первом курсе как-то заставляли рисовать диаграммы кода по ГОСТу, когда несколько строк кода превращаются в несколько страниц A4 с диаграммами. От этого плевались буквально все.

Здравствуйте, vdimas, Вы писали:

C>>А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.
V>Почему мучать? Свою первую более-менее сложную программу я расписал на 3-х листах в блок-схемах когда-то. И она сразу заработала. П\росто у меня не было достаточно машинного времени на тот момент, чтобы позволить себе ее отладку часами...
Сочуствую. Тяжело жилось в каменном веке, с деревянными компьютерами прибитыми к полу.

Но сейчас ситуация немного другая.

V>Да и сейчас, если чувствую нутром во время ревью чужого кода, что "здесь что-то не то", беру блокнот и рисую квадратики и стрелочки и сразу вижу это "не то" или
что напрасно сомневался.
Прекрасно. А теперь то же самое попробуй на формальном ДРАКОНе.

Здравствуйте, vdimas, Вы писали:

V>Это ты себя, любимого, выгородить решил. Те, кто не в состоянии понимать блок-схемы, вообще на технические специальности не годятся по складу ума. Как тебе юз-кейз дадут читать, если ты его прочесть не сумеешь? Получается, над тобой нужен старший смотрящий, который разжует и в рот положит.
Замечательно. Итого делаем вывод, что программирование — это чисто женская профессия. Ибо у мужчин просто нет необходимого склада ума для этого дело — они хуже понимают блок-схемы. Увольняем всех мужчин нахрен, оставляем 1% женщин — и вперед, наконец поднимем ИТ до нужного уровня.
Юз кейсы всю жизнь пишутся и писались текстом! Из графического — только дизайн. Конечные автоматы, если они есть, задаются просто табличками. По крайней мере сколько не видел буржуйские спеки, никаких диаграмм там не было. Графические юз кейсы я первый и последний раз видел в институте, когда надо мной UMLом измывались и заставляли из этих диаграмок код генерить. В православных конторах, где все по ГОСТу, работать к счастью не доводилось. Рисование юзкейсов диаграмками — это напрасная трата времени и денег. Я конечно понимаю, что в Севастополе процесс разработки на порядок выше поставлен, чем в Москве, да и ИТ там гораздо сильнее развито, и зарплаты там наверно тысяч под 500 у джуниоров, но как то пока севастопольские работодатели не оказывали мне чести у них поработать.

Здравствуйте, vdimas, Вы писали:

V>Блин, ну ты даааал...
Это ты в очередной раз дал.
1)В каком месте это дракон?
2)Засунуть слова в прямоугольники и заменить операторы на стрелочки много ума не надо.
И эта махинация ухудшила восприятие.
Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.

V>Как это SQL не ложится, если есть мильон существующих тулзов графического редактирования SQL?
На основе дракона?

V>Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF:
Да плевать мне на IBM.

V>http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm
Феерический ужОс.

V>Ну и я уже давным давно предлагал тебе скачать хотя бы два-три десятка тулзов для разработки компиляторов... просто посмотреть, где сейчас народ находится, а то вы малость застряли на сравнении с бизоном из 80-х... Во многих тулзах идет такое же или похожее редактирование синтаксических диаграмм.

Ты даже не понял, какие у меня претензии к бизонам.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, elmal, Вы писали:

V>>Почему бы тебе не скачать среду и не построить эту блок-схему самому, в кач-ве небольшой разминки?
E>Даже нашел реализацию сам:
E>http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png
E>Куча состояний, внимание расфокусировано, рекурсию хрен заметишь.
E>Лично я никакого ускорения понимания не заметил. По сравнению с нормальной реализацией:

Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша.
Но в сложных случаях дело обстоит иначе.

Давайте рассмотрим сложный случай, например, проектирование атомного реактора (на драконе).
Сейчас я дам ссылку. Но перед этим пояснения:

1. Прочитайте раздел ВИЗУАЛИЗАЦИЯ МЕТОДОЛОГИЙ (стр. 201-212).

2. Это старая книга (2001 год). Я давно отказался от термина "методология",
который я использовал под дурным влиянием Джеймса Мартина.

3. Таким образом, название следует читать ВИЗУАЛИЗАЦИЯ АЛГОРИТМОВ.

4. Я отказался также от термина "алгоритм-концепция". Следует читать "алгоритм".

5. Но это мелочи. Главное в том, что в данном примере (атомный реактор) не следует употреблять термин "состояние".
Никаких состояний там нет. Это не конечный автомат. То, что на первый взгляд, кажется состоянием, это СТРУКТУРНЫЙ ЭЛЕМЕНТ алгоритма.
http://www.e-reading.org.ua/bookreader.php/135509/Kak_uluchshit'_rabotu_uma.pdf

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша.
ВП>Но в сложных случаях дело обстоит иначе.
Так, уже достало враньё слушать.

Пример сложного алгоритма в студию, хотя бы аналог 10000 строк кода. Иначе всё про ДРАКОН считаем банальным враньём и фрикачеством.

У ваших оппонентов (WolfHound, к примеру) есть действительно интересные разработки, которые подкреплены заметным объёмом кода. Я несогласен с их идеями, но воспринимаю их вполне серьёзно. Возможно, что это я ошибаюсь, а не они.

А ваши поделки не тянут даже на это. В общем, "Code talks bullshit walks" (c) Linus Torvalds.

Здравствуйте, vdimas, Вы писали:

V>Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF:
V>http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm
V>Похоже, ты ни разу в жизни не читал их документаций...
Замечательно, что сам привел пример IBM. Прочитай отзывы об их продуктах. Например по поводу Lotus Notes. Прочитай отзывы программистов, которые там работают. Могу сам даже написать про их мегабиблиотеку связи, которая плодит по потоку на каждое обращение, а в интерфейсах не предусмотрено даже метода закрыть соединение. Или про приколы, когда дергаешь метод получения данных, в результате удаленный сервер, на котором работает куча пользователей, перезагружается. Слишком часто будешь забирать данные — тоже часто перезагружается. Замечательная система, как так можно писать, я не представляю. Эта IBM такими темпами скоро загнется. Ибо работать на них, это настоящий ад. Там такая бюрократия, что любой НИИ советских времен сказкой покажется. Я один раз к ним чуть не попал на проект. А потом со мной работал коллега, который имел счастье к ним попасть. Ему потом очень страшный адский проект сказкой казался, он такое рассказывал, что волосы дыбом вставали.
Так вот, IBM — это пример того, как не надо делать продукты.

Здравствуйте, elmal, Вы писали:

V>>Это ты себя, любимого, выгородить решил. Те, кто не в состоянии понимать блок-схемы, вообще на технические специальности не годятся по складу ума. Как тебе юз-кейз дадут читать, если ты его прочесть не сумеешь? Получается, над тобой нужен старший смотрящий, который разжует и в рот положит.
E>Замечательно. Итого делаем вывод, что программирование — это чисто женская профессия. Ибо у мужчин просто нет необходимого склада ума для этого дело — они хуже понимают блок-схемы.

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

E>Юз кейсы всю жизнь пишутся и писались текстом! Из графического — только дизайн. Конечные автоматы, если они есть, задаются просто табличками. По крайней мере сколько не видел буржуйские спеки, никаких диаграмм там не было.

Значит, ты не видел ещё ничего или тебе просто не показывали, зная бесполезность для тебя лично.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>5. Но это мелочи. Главное в том, что в данном примере (атомный реактор) не следует употреблять термин "состояние".
ВП>Никаких состояний там нет. Это не конечный автомат. То, что на первый взгляд, кажется состоянием, это СТРУКТУРНЫЙ ЭЛЕМЕНТ алгоритма.
ВП>http://www.e-reading.org.ua/bookreader.php/135509/Kak_uluchshit'_rabotu_uma.pdf
Итого, для реактора ок, предположим что язык подходит лучше, чем конкуренты. Если мне нужно будет делать документацию — ок, возможно когда нибудь попробую. Но на том примере перечислена не полная программа, там только верхушка айсберга, служащая для иллюстрации. Я в курсе, что можно продолжать спускаться и постепенно увеличивать детализацию. Я даже готов признать, что для управления реактором оптимально сначала нарисовать высокоуровневый алгоритм, тщательно его проверить, а далее на его основе сгенерить текст.
А теперь перечисляю но:
1) Реакторы, космические корабли, сложное медицинское оборудование вроде томографов — это весьма узкая область. В этой области до сих пор царит царство waterfall methodology, сначала полная и подробная документация, затем реализация, требования не меняются. И скорее всего так и будет водопад царствовать в этой области, так как для своих задач он вполне подходит;
2) В современном мире в 99% случаев правят AGILE методологии, требования меняются постоянно, сделать нужно быстро, на документирование нет времени, ибо неизвестно, нужна новая фича или нет. Ты делаешь фичу, тебе говорят молодец, но мы передумали;
3) Итого, я готов допустить, что для waterfall методологии дракон довольно хорошо подходит (правда там пилить еще и пилить его нужно). У вас большой опыт в этом — я даже спорить не буду, ибо именно в waterfall некомпетентен. Но я могу сказать точно, что подход — сначала рисуем, а потом генерим, в современных Agile методологиях полностью не применим. Ибо тут уже у меня хороший опыт, и здесь я вполне компетентен.
4) На этом форуме найдется крайне мало людей, использующих водопад, и работающих в областях, где он применим. Соответственно именно в этом форуме вряд ли у вас будет большая поддержка. А вот критики будет очень и очень много, ибо все будут рассматривать язык применительно к своим задачам и своему весьма немалому опыту работы по другим методологиям.

Здравствуйте, WolfHound, Вы писали:

V>>Блин, ну ты даааал...
WH>Это ты в очередной раз дал.
WH>1)В каком месте это дракон?

В таком, что здесь походя утверждают о неприменимости графического представления как такового. Дык, остыньте малость на фактах.

WH>2)Засунуть слова в прямоугольники и заменить операторы на стрелочки много ума не надо.

Это спор с самим собой?

WH>И эта махинация ухудшила восприятие.

Эта "махинация" позволяет составлять запросы даже тем, кто плохо владеет языком SQL или только начинает его изучать. Я наблюдал как девочки оперативно накидывали в MS Access полезные запросы в графике буквально на 2-3-й день его изучения, не зная языка SQL. И видел, как они постепенно изучали тем самым этот SQL до приемлимого уровня, видя во что именно преобразуется графическое представление.

WH>Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.

Это в любом случае надо понять, даже в виде БНФ или любой другой нотации.

V>>Как это SQL не ложится, если есть мильон существующих тулзов графического редактирования SQL?
WH>На основе дракона?

По кругу.

V>>Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF:
WH>Да плевать мне на IBM.
V>>http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm
WH>Феерический ужОс.

Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.

V>>Ну и я уже давным давно предлагал тебе скачать хотя бы два-три десятка тулзов для разработки компиляторов... просто посмотреть, где сейчас народ находится, а то вы малость застряли на сравнении с бизоном из 80-х... Во многих тулзах идет такое же или похожее редактирование синтаксических диаграмм.
WH>

Ты даже не понял, какие у меня претензии к бизонам.

Да пообщался я с вами в той фейерической ветке про БНФ. Поржал, спасибо. Редкостная каша в голове.

Здравствуйте, elmal, Вы писали:

E>Я один раз к ним чуть не попал на проект. А потом со мной работал коллега, который имел счастье к ним попасть. Ему потом очень страшный адский проект сказкой казался, он такое рассказывал, что волосы дыбом вставали.
E>Так вот, IBM — это пример того, как не надо делать продукты.

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

Здравствуйте, elmal, Вы писали:

E>4) На этом форуме найдется крайне мало людей, использующих водопад, и работающих в областях, где он применим.

Боже, сколько нубства... Водопад ВСЕГДА применим, когда идет реализация заведомо известных требований (спецификаций, протокола, и т.д. и т.п.). В этих условиях ему нет равных. И опять же — водопад не отменяет RUP, то бишь итеративный характер разработки. Это просто движение вектора декомпозиции сложности и ничего более.

Здравствуйте, vdimas, Вы писали:

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

V>Значит, ты не видел ещё ничего или тебе просто не показывали, зная бесполезность для тебя лично.
Я говорю еще раз — в православных конторах я не работал! И куда мне до великих специалистов исключительно по императивному программированию. Не сомневаюсь, что в конторах, где царит ГОСТ, исключительно императивный подход, а также многое другое тяжелое наследие прежних времен, мне не заплатят даже 5000 рублей в месяц.

Здравствуйте, Cyberax, Вы писали:

C>Дело в том, что ДРАКОН — это не язык разработки use-case'ов и для описания формальных требований он тоже не очень подходит.

Use-case тоже описывают лишь крохи формальных требований. Но на драконе можно описать юз-кейзы. Я сильно его не смотрел, но даже на что посмотрел: "силуэт" — это полный аналог диаграмм use-case по своим выразительным возможностям. Не зря алгоритмы верхнего уровня имеют "силуэт".

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

C>Получается непонятная шизофрения — с одной стороны инжинеры должны описывать алгоритм на некотором почти-формальном языке,

Описание ПРИКЛАДНОГО алгоритма — это и есть ТЗ. И это очень хорошее ТЗ в отличие от уже ставших привычным "да ты не выё, ты рукой покажи..." и прочих монологов брата Нибэнимэда.

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

C>а с другой стороны программисты должны по этому намалёванному непотребию потом делать что-то работающее. Я прямо отсюда слышу их матюки.

Ну вон из профессии, марш на вебку, делов-то...

Кто-то же пишет реализации протоколов TCP? (Упрощенную реализацию ваш покорный слуга тоже когда-то сделал для контроллера). А там спецификаций в сумме — мама не горюй. И никто не умер...

ИМХО, формальные описания делают две полезные вещи:
— краткость самого описания; (можно пользоваться преопределенными примитивами, составляющими язык описания и его семантику)
— полнота и однозначность.

Все-таки в RFC много отcебятины, воды и что самое досадное — недоговоренностей. Надо "проникаться" и делать прочие эзотерическо-загадочные вещи. Без спецификаций оставлен целый класс ситуаций в TCP, пришлось по другим местам по крохам собирать информацию о "правилах хорошего тона" в поведении ендпоинтов, т.ч. числе через реакцию ответной части из работающей операционки. Прямо оттуда ты мог слышать мои матюги. Я бы предпочел однозначные и полные спецификации вместо этого бредового этапа разработки.

C>Т.е. я совсем не против методологии, где инжинеры описывают формальные требования, по которым потом создаётся код. Но для этого надо иметь соответствующие инструменты. И самый главный из них — старый добрый текст. Диаграммы имеют смысл, но только для:
C>1) Иллюстрации общей структуры (т.е. иерархические диаграммы).
C>2) Диаграммы для КА (в различных формах).

Блок схемы — это считай разновидность автомата. Просто автомат магазинный. ИМХО, для огромного класса алгоритмов магазинный удобнее конечного. Ну и магазинные включают в себя все остальные классы автоматов.

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

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, vdimas, Вы писали:

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

Ну а я опираюсь на многолетний опыт работы с женщинами и мужчинами в области разработки электроники. Различия в подходе к работе увидел довольно быстро, заинтересовался и одно время читал много материала об этих различиях, подтверждающего мои наблюдения. Например:
http://www.medinfo.ru/sovety/psi/33.phtml

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

Тут в первй строчке немного не согласен: мужчины не понимают, что есть "интуиция". На самом деле это очень далеко зашедшая в подробностях логика. ИМХО, мужская логика проще гораздо. Еще от себя добавлю, что мужчина легко рассуждает о параллельном взаимодействии сразу нескольких алгоритмов, зато женщине проще уследить за всеми деталями одного, даже очень сложного и глубокого, что мужчинам бывает сложно, и наверно от этого — всегда скучно.

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

E>Я говорю еще раз — в православных конторах я не работал! И куда мне до великих специалистов исключительно по императивному программированию. Не сомневаюсь, что в конторах, где царит ГОСТ, исключительно императивный подход, а также многое другое тяжелое наследие прежних времен, мне не заплатят даже 5000 рублей в месяц.

Самое время спросить о возрасте, но че-то нелюбопытно. Итак понятно.. ))

Здравствуйте, Cyberax, Вы писали:

C>Сочуствую. Тяжело жилось в каменном веке, с деревянными компьютерами прибитыми к полу.

C>Но сейчас ситуация немного другая.

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

V>>Да и сейчас, если чувствую нутром во время ревью чужого кода, что "здесь что-то не то", беру блокнот и рисую квадратики и стрелочки и сразу вижу это "не то" или
C>что напрасно сомневался.
C>Прекрасно. А теперь то же самое попробуй на формальном ДРАКОНе.

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

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

Здравствуйте, vdimas, Вы писали:

C>>Сочуствую. Тяжело жилось в каменном веке, с деревянными компьютерами прибитыми к полу.
C>>Но сейчас ситуация немного другая.
V>Дык, сейчас всё хуже, насколько я вижу. Посади даже 15-тилетнего ребенка за комп и попроси написать аналогичную программу и засеки время. Ответ я знаю заранее.
В 15 лет я уже писал программы в тысячи строк кода (на С++). Первую программу я написал в 9 лет (на Бэйсике).

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

> Я говорю еще раз — в православных конторах я не работал! И куда мне до великих специалистов исключительно по императивному программированию. Не сомневаюсь, что в конторах, где царит ГОСТ, исключительно императивный подход, ...

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Не нужно унижать императивный подход. Видишь ли, есть такая проблема, на космическую станцию нельзя послать специалиста в командировку для отладки, сбора требований, исправления бага и смены прошивки в микроконтроллере.
Так я что — спорю? Я ни грамма не унижаю. Более того, наряду с прочими подходами, я вполне использую и императивный, и ни грамма этого не стыжусь. Вот только во первых, кроме императивного, есть еще куча других подходов. Которые вполне применимы и на космической станции. Космическая индустрия уникальна тем, что там несоизмеримо выше цена ошибки. В результате там несоизмеримо выше затраты на документирование и тестирование.
Кстати про космос — занятная статья:
http://c2.com/cgi/wiki?MarsSpiritSoftwareProblem

Здравствуйте, vdimas, Вы писали:

WH>>1)В каком месте это дракон?
V>В таком, что здесь походя утверждают о неприменимости графического представления как такового. Дык, остыньте малость на фактах.

Ты посмотри, на что ты отвечаешь.

V>Эта "махинация" позволяет составлять запросы даже тем, кто плохо владеет языком SQL
И где тут SQL?
Может хватить прыгать по темам.
Или сказать совсем нечего?

V>или только начинает его изучать. Я наблюдал как девочки оперативно накидывали в MS Access полезные запросы в графике буквально на 2-3-й день его изучения, не зная языка SQL.
А я видел девочек которые на С++ пишут лучше многих тут присутствующих.

V>И видел, как они постепенно изучали тем самым этот SQL до приемлимого уровня, видя во что именно преобразуется графическое представление.
А с чего ты взял, что за те же 2-3 дня они бы SQL не осилили?

WH>>Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.
V>Это в любом случае надо понять, даже в виде БНФ или любой другой нотации.
Сравнил блин.
В нормальной нотации нужно запомнить всего один оператор.

Кстати как в твоей графике будет выглядеть запись того что правило нужно повторить от 5 до 10 раз?

V>Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
Причем тут немерле? Совсем аргументов нет?

V>Да пообщался я с вами в той фейерической ветке про БНФ. Поржал, спасибо. Редкостная каша в голове.
Сказал адепт секты, которая, не смотря на свою многочисленность, за 50 лет не смогла создать ни одного алгоритма годного для промышленного применения.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Справка

ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

Язык ДРАКОН успешно используется во многих космических программах:

• разгонный блок космических аппаратов ДМ-SL (проект «Морской старт»);

• разгонный блок космических аппаратов «Фрегат» (включая Фрегат-СБ, Фрегат-МТ, Фрегат с модернизированной системой управления);

• модернизированная ракета-носитель тяжелого класса «Протон-М»;

• разгонный блок космических аппаратов ДМ-SL-Б (проект «Наземный старт»);

• разгонный блок космических аппаратов ДМ-03;

• первая ступень для южнокорейской ракеты-носителя легкого класса KSLV-1 (Korean Space Launch Vehicle);

• ракета-носитель легкого класса Ангара 1,2;

• ракета-носитель тяжелого класса Ангара-А5;

• разгонный блок космических аппаратов КВТК (кислородно-водородный тяжелого класса) и др.

Космодромы:

Плавучий космодром, производящий пуски с экватора в Тихом океане (экваториальная зона вблизи острова Рождества Республики Кирибати (с координатами 154 градуса западной долготы и 0 градусов широты)),

Байконур,

Плесецк,

Европейский космический центр во Французской Гвиане "Kuru" (Южная Америка),

Южнокорейский космодром "Naro".

Нет, ну совести совсем нет, зачем же так бессовестно вводить людей в заблуждение.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Cyberax, Вы писали:

V>>Дык, сейчас всё хуже, насколько я вижу. Посади даже 15-тилетнего ребенка за комп и попроси написать аналогичную программу и засеки время. Ответ я знаю заранее.
C>В 15 лет я уже писал программы в тысячи строк кода (на С++). Первую программу я написал в 9 лет (на Бэйсике).

Охотно верю. Все-равно, ты бы не вложился в 20-30 мин, даже имея такой опыт на тот момент. Ответ я знаю заранее, потому что вижу "молодых и одаренных" в компьютерных кружках и вижу как они пишут программы: добавили несколько строк — запускают смотрят. Поправляют. Потом опять. Фактически процесс написания программы состоит из исправления багов в каждой 5-й строчке или даже чаще. Откровенная печаль.

А у меня опыт был — 2 раза урока информатики до этого.. И скорость печатанья, прямо скажем, отличается от нынешней. Просто потратил около 30 мин на диаграмму дома и чуть более 20 мин на ее набивку на уроке. И всё заработало сразу.

V>>Т.е. даже берем один графический язык — схем электрических принципиальных, и видим кучи редакторов разной степени удобства.
C>Электрические схемы — это по своей сути графическая вещь. Но вот сложные схемы всё как-то сейчас в виде текста описывают.

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

Здравствуйте, grosborn, Вы писали:

G>Нет, ну совести совсем нет, зачем же так бессовестно вводить людей в заблуждение.

У тебя есть информация, подтверждающая твои инсинуации? Поделись.

Здравствуйте, Cyberax, Вы писали:
C>Получается непонятная шизофрения — с одной стороны инжинеры должны описывать алгоритм на некотором почти-формальном языке, а с другой стороны программисты должны по этому намалёванному непотребию потом делать что-то работающее. Я прямо отсюда слышу их матюки.
А то. Ад как он есть. Тем не менее, подозрительно популярная тема: bpmn/bpel таки продаются за большие бабки, MS в своем шарепоинте тоже предписывает всем срочно садиться рисовать согласование документов в визио.

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

Ну и тут вот еще из геймдева примеры приводились.

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Справка
ВП> ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ
Не верю. Попрошу ссылку, скажем, с сайта РКК "Энергия" о том, где конкретно используется ДРАКОН.

А то я тоже много чего написать могу.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Справка

ВП> ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

<skipped>

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша.
ВП>Но в сложных случаях дело обстоит иначе.
Кстати о сложных случаях. Со всей этой декомпозицией мы забыли спросить одну интересную вещь — а как делается обработка ошибок? Я не увидел обработки ошибок ни на одной из диаграмм. Итак, предположим мы пишем софт управления атомной станцией. И хотим следующее — чтобы в случае абсолютно любых ошибочных ситуаций заглушать реактор. Это настолько важно, что это все требуется на на диаграмме верхнего уровня! Что любая непредвиденная ситуация — заглушаем реактор. Эта любая непредвиденная ситуация может вылететь откуда угодно из нижестоящего сабалгоритма. То есть интересует в языке такая полезная вещь, как исключения. Итого — как это будет на Драконе? Я приблизительно догадываюсь, что на главной диаграмме сверху будет состояние ошибка, в которую мы можем переходить из других состояний. Но ... любой прямоугольничек может у нас выкинуть исключение. Даже функция проверки условия может выкинуть исключение (предположим, там датчик какой оказывается неисправным). Как будем поступать? Более того, обработчик ошибки очень интересуется деталями, в зависимости от того, что за ошибка, он захочет принять решение, стопать ли реактор или нет, или попытаться переключиться на резервный контур и проверить все еще раз. Как будет выглядить алгоритм в этом случае? Что то мне подсказывает, что будет очень неслабое усложнение схемы на ровном месте. И если исключения поддерживаются — очень интересует, как будет генерироваться программа на фортране, где на момент последнего с ним знакомства исключениями и не пахло?

Здравствуйте, WolfHound, Вы писали:

V>>Эта "махинация" позволяет составлять запросы даже тем, кто плохо владеет языком SQL
WH>И где тут SQL?
WH>Может хватить прыгать по темам.
WH>Или сказать совсем нечего?

Ты спросил об SQL, я напомнил.

V>>или только начинает его изучать. Я наблюдал как девочки оперативно накидывали в MS Access полезные запросы в графике буквально на 2-3-й день его изучения, не зная языка SQL.
WH>А я видел девочек которые на С++ пишут лучше многих тут присутствующих.

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

V>>И видел, как они постепенно изучали тем самым этот SQL до приемлимого уровня, видя во что именно преобразуется графическое представление.
WH>А с чего ты взял, что за те же 2-3 дня они бы SQL не осилили?

Потому что было показано как переключаться в SQL и как опльзоваться справкой, по SQL в т.ч. Не получается за 2-3 дня выдавать правильно работающие запросы. Зато переключают в MS Access из текста в режим дизайна и моментально находят ошибки.

Не боись, именно языку SQL и учил, бо возможности дизайнера в MS Access ограничены. С 0-ля — это месяцы, чтобы полноценно пользоваться SQL, и то только у двух получалось. Остальные дальше графики не прошли. Так что, я наблюдал тот самый "порог вхождения" воочию.

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

WH>>>Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.
V>>Это в любом случае надо понять, даже в виде БНФ или любой другой нотации.
WH>Сравнил блин.
WH>В нормальной нотации нужно запомнить всего один оператор.

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

WH>Кстати как в твоей графике будет выглядеть запись того что правило нужно повторить от 5 до 10 раз?

А бывают такие правила?
В БНФ подобное делается через иерархическое выражение одних правил через другие. Т.е. Повторить8 может быть определено через Повторить7 и целевое тело.

V>>Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
WH>Причем тут немерле? Совсем аргументов нет?

На "мне плевать на IBM"? Ес-но нет и не будет. Не понравился пример — я не при чем.

V>>Да пообщался я с вами в той фейерической ветке про БНФ. Поржал, спасибо. Редкостная каша в голове.
WH>Сказал адепт секты, которая, не смотря на свою многочисленность, за 50 лет не смогла создать ни одного алгоритма годного для промышленного применения.

Алгоритмов море, бери любой. Странной была попытка взять один из алгоритмов и претендовать с ним на универсальность. Это же просто язык описания работы конкретного низлежащего автомата разбора. Пусть даже очень хорошего автомата, но конкретного. Какая тут нафик универсальность? Именно необходимость объяснять это и повеселила.

Здравствуйте, vdimas, Вы писали:

V>Твоя фраза ничего не подтверждает, а моя подтверждает, что в 100% наблюдений за одним и тем же сценарием видно, что людям удобней было начать знакомиться с языком SQL через его графическое отображение в дизайнере запросов.
А я изучил SQL за день по MSDN.
А от дизайнера запросов всегда плевался.

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

WH>>Кстати как в твоей графике будет выглядеть запись того что правило нужно повторить от 5 до 10 раз?
V>А бывают такие правила?
Любые.

V>В БНФ подобное делается через иерархическое выражение одних правил через другие. Т.е. Повторить8 может быть определено через Повторить7 и целевое тело.
И получаем 10 правил на ровном месте.
При однозначной трансляции в граф получи гору квадратиков.

V>>>Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
WH>>Причем тут немерле? Совсем аргументов нет?
V>На "мне плевать на IBM"? Ес-но нет и не будет. Не понравился пример — я не при чем.
А что мне должно вот в этом понравиться?

Создание задания без преобразования
 
>>-onpladm create job--задание--+-------------+-- -n------------>
                                '- -p--проект-'
 
>-- -d--устройство-- -D--база данных-- -t--таблица-------------->
 
   .---------------------------------------------------------------------------.
   V                                                                           |
>----+-----------------------------------------------------------------------+-+-><
     |                                                                  (1)  |
     '-+-------------+--+-----------------+--| Задание режима запуска |------'
       '- -S--сервер-'  '- -T--назначение-'

Это трудно читать.
Трудно писать.
И озвереешь при написании компилятора.

V>Алгоритмов море, бери любой.
Все говно.

V>Странной была попытка взять один из алгоритмов и претендовать с ним на универсальность. Это же просто язык описания работы конкретного низлежащего автомата разбора. Пусть даже очень хорошего автомата, но конкретного. Какая тут нафик универсальность? Именно необходимость объяснять это и повеселила.
Ни один из этих алгоритмов не используется в больших компиляторах и ИДЕ.
И это факт.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Cyberax, Вы писали:

C>Не верю. Попрошу ссылку, скажем, с сайта РКК "Энергия" о том, где конкретно используется ДРАКОН.

Выше совершенно правильно перечислены проекты системы управления которых делал ФГУП «НПЦАП» (Центр Пилюгина). Все следы использования этого Дракона в ракетно-космической отрасли ведут туда. А вот в какой степени и с какой целью этот Дракон используется там действительно интересно было бы узнать. Пока складывается ощущение что исключительно для документирования ТЗ.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, novitk, Вы писали:

N>Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>> ЧЕТЫРЕ ВИДЕОУРОКА НА YOUTUBE
ВП>>по 15 минут каждый

N>Посмотрел 10 минут ролика. В чем отличие этой программы от LabView?

Тем, что Вы о Драконе узнали только что. Или чуть раньше.
Однако, хотя за давностью лет их можно считать ровесниками, Дракон будет постарше. Годика этак на 3-4.

Здравствуйте, batu, Вы писали:

B>Здравствуйте, LaptevVV, Вы писали:

LVV>>ИМХО потому, что Владимир Даниэлович практически 25 лет с языком работает. На этом зыке проектировалась управляющая система Бурана.
LVV>>А в 90-х он, наконец, вышел из под секретности.
LVV>>Как препод могу сказать, что некоторым студентам и почти всем студенткам гораздо проще посмотреть на картинку алгоритма, чем на текст алгоритма. Для рисования сложных алгоритмов Дракон подходит как нельзя лучше.
B>Я работал разработчиком системы старта и технического обслуживания Бурана. (конкретно пульт управления моя разработка). Ни сном ни духом про Дракон. У нас был свой язык ЭЛИДО. Так это такое говно. Макросы обычные. Про существование синтаксиса и терии трансляторов наше техническое руководство тогда просто не доходило уровнем. Хотя были и в Подлипках и у Пилюгина по пол года не вылазили с полигонов..

А я как раз работал у Пилюгина. В аккурат с 80 по 89. И про Дракон, и про использование его в проектировании ИСУ слышал неоднократно. Хотя сам не пользовал, бо с другого конца был — автоматизация обработки ТМИ.
А отец у меня работал у Рязанского. Они для Бурана стряпали БИТЦ. Про Дракон если и слышали, то только в пол уха. Бо в каждой конторе в тем времена свои порядки и законы.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, vdimas, Вы писали:

V>>>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.
C>>>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.
V>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.

Ну и зря

C>Никаких независимых подтверждений его слов нет. Так же как и вообще известного софта или работающих реализаций самого языка.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, vl690001x, Вы писали:

V>>Почему многие сразу принимаются за критику, толком не разобравшись?
V>>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
C>У нормальных специалистов нет проблем с изучением очередной рвотной массы типа ДРАКОНа. В нём нового — ровно ноль. Обычный простой императивный язык, коих десятки тысяч.

C>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?

Это ты думаешь, то ДО. А на самом деле — ПОСЛЕ.

V>>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
C>Имеет — в качестве посмешища.

Здравствуйте, kig, Вы писали:

V>>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.
kig>Ну и зря
Так, а теперь для чего конкретно он использовался. Я всё ещё не верю, что на нём писали сколь-либо заметное количество (если вообще) работающего кода.

Здравствуйте, kig, Вы писали:

C>>У нормальных специалистов нет проблем с изучением очередной рвотной массы типа ДРАКОНа. В нём нового — ровно ноль. Обычный простой императивный язык, коих десятки тысяч.
C>>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?
kig>Это ты думаешь, то ДО. А на самом деле — ПОСЛЕ.
Пофиг. Ключевое слово здесь — "были".

Они пиарились на всю индустрию, но люди быстро их выкинули, когда до всех дошло, что неправильные картинки неправильно работают.

Здравствуйте, WolfHound, Вы писали:

WH>Это трудно читать.
WH>Трудно писать.
WH>И озвереешь при написании компилятора.

Это потому что в псевдографике. В чистой графике поприличнее. Смотрел ANTLRWorks?

И никто не пишет компиляторы прямо по ТЗ. А где же стадия анализа? А где стадия преобразования эквивалентных синтаксических граф-схем? А как же регуляризация грамматики? ))

V>>Алгоритмов море, бери любой.
WH>Все говно.

Есть разная степень подходящести алгоритма под класс грамматики. Просто ты всячески пытаешься отнекиваться от объективного фактора — разделения грамматик на классы. Пытаешь делать вид, что такого в природе не существует. А ведь LL(1) или LR(1) работают фактически со скоростью лексера. Т.е. там, где достаточно этих классов грамматики, нет смысла применять что-то другое. А GLR, помимо того, что полностью покрывает КС-грамматики, дык еще является "оперативным", выполняющим максимум работы на каждом символе и без откатов, что делает его очень удобным для грамматик огромных по размерам документов (на многие мегабайты). Парсеры с откатами на таких сценариях не взлетают.

V>>Странной была попытка взять один из алгоритмов и претендовать с ним на универсальность. Это же просто язык описания работы конкретного низлежащего автомата разбора. Пусть даже очень хорошего автомата, но конкретного. Какая тут нафик универсальность? Именно необходимость объяснять это и повеселила.
WH>Ни один из этих алгоритмов не используется в больших компиляторах и ИДЕ.
WH>И это факт.

Используется нейтральное БНФ для описания спецификаций независимо от подробностей реализации компилятора. А ты собрался эти подробности вытащить на уровень спецификаций. Тем самым ты собрался прибить гвоздями спецификацию к реализации... Это конфуз, коллега. Неужели история с ПЕГ тебя не научила, что всегда может найтись чуть лучшее решение, чем было использовано до этого?

Здравствуйте, kig, Вы писали:

kig>Тем, что Вы о Драконе узнали только что. Или чуть раньше.
kig>Однако, хотя за давностью лет их можно считать ровесниками, Дракон будет постарше. Годика этак на 3-4.

Я о нем узнал вчера, но мы не в политике и меня слабо интересуют вопросы исторического первенства. Какие преимущества дает Дракон по сравнению с LabView сегодня?

Здравствуйте, kig, Вы писали:

(конкретно пульт управления моя разработка). Ни сном ни духом про Дракон. У нас был свой язык ЭЛИДО. Так это такое говно. Макросы обычные. Про существование синтаксиса и терии трансляторов наше техническое руководство тогда просто не доходило уровнем. Хотя были и в Подлипках и у Пилюгина по пол года не вылазили с полигонов..

kig>А я как раз работал у Пилюгина. В аккурат с 80 по 89. И про Дракон, и про использование его в проектировании ИСУ слышал неоднократно. Хотя сам не пользовал, бо с другого конца был — автоматизация обработки ТМИ.
kig>А отец у меня работал у Рязанского. Они для Бурана стряпали БИТЦ. Про Дракон если и слышали, то только в пол уха. Бо в каждой конторе в тем времена свои порядки и законы.
Во.. Может даже и встречались

Ну, а про слухи это дело такое. Наши тоже щеки надували на свои разработки..А было все тупо как двери. Но работало..

Здравствуйте, vdimas, Вы писали:

V>И никто не пишет компиляторы прямо по ТЗ.
Я пишу.

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

V>Используется нейтральное БНФ для описания спецификаций независимо от подробностей реализации компилятора. А ты собрался эти подробности вытащить на уровень спецификаций. Тем самым ты собрался прибить гвоздями спецификацию к реализации... Это конфуз, коллега. Неужели история с ПЕГ тебя не научила, что всегда может найтись чуть лучшее решение, чем было использовано до этого?
Открываем стандарт C# и смотрим как там заданы приоритеты операторов и понимаем что EBNF не подходит даже для спецификации.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, pagid, Вы писали:

P>Выше совершенно правильно перечислены проекты системы управления которых делал ФГУП «НПЦАП» (Центр Пилюгина). Все следы использования этого Дракона в ракетно-космической отрасли ведут туда.

Вы совершенно правы. НПЦАП — ведущее предприятие Роскосмоса по автономным СУ ракетно-космической техники.

Сам Пилюгин (1908 — 1982) видел цели так:

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

Я работаю в Пилюгинском центре всю жизнь (с 1961 года).
Участвовал в разработке СУ как баллистических ракет, так и космических проектов.

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

В 1986 года мой начальник Ю.В. Трунов (впоследствии Генеральный конструктор ФГУП "НПЦАП") поручил мне создать единый язык программирования вместо трех (Прол2, Диполь, ЛАКС), использоваавшихся при проектировании СУ Бурана.

Работа длилась примерно 11 лет, в ней участвовало около десяти человек, в частности из ИПМ РАН, и закончилась только в 1996 году.
______________________________

P> ... складывается ощущение что Дракон используется исключительно для документирования ТЗ.

Это не так. Инженеры фактически пишут программы (хотя они не знают об этом).
Посмотрите внимательнее на структуру технологии. Слева написано
«Программирование без программистов». Это не пустые слова.
http://drakon.su/_media/biblioteka/grafit_a4.pdf

Здравствуйте, batu, Вы писали:

B>Здравствуйте, kig, Вы писали:

B> (конкретно пульт управления моя разработка). Ни сном ни духом про Дракон. У нас был свой язык ЭЛИДО. Так это такое говно. Макросы обычные. Про существование синтаксиса и терии трансляторов наше техническое руководство тогда просто не доходило уровнем. Хотя были и в Подлипках и у Пилюгина по пол года не вылазили с полигонов..

kig>>А я как раз работал у Пилюгина. В аккурат с 80 по 89. И про Дракон, и про использование его в проектировании ИСУ слышал неоднократно. Хотя сам не пользовал, бо с другого конца был — автоматизация обработки ТМИ.
kig>>А отец у меня работал у Рязанского. Они для Бурана стряпали БИТЦ. Про Дракон если и слышали, то только в пол уха. Бо в каждой конторе в тем времена свои порядки и законы.
B>Во.. Может даже и встречались

Ну, а про слухи это дело такое. Наши тоже щеки надували на свои разработки..А было все тупо как двери. Но работало.

Ну а у Владимира Даниловича Дракон "взлетел". Сначала в "детском" варианте на Буране. А затем, как я в курсе, в самые голодные годы работа не прекращалась. И сейчас пользуется у Пилюгина.

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kig, Вы писали:

V>>>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>>>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.
kig>>Ну и зря
C>Так, а теперь для чего конкретно он использовался. Я всё ещё не верю, что на нём писали сколь-либо заметное количество (если вообще) работающего кода.

здесь

Или опять будешь брызгать слюной про вранье?

Кстати, а по поводу LabView (здесь уже высказывалось мнение, что это очень похожие разработки), побрызгать не хочешь? Что это отстой ну и т.п. А заодно побрызгать в сторону Apple, ведь первая версия LabView как раз для яблока была зарелийзена?

Здравствуйте, novitk, Вы писали:

N>Здравствуйте, kig, Вы писали:

kig>>Тем, что Вы о Драконе узнали только что. Или чуть раньше.
kig>>Однако, хотя за давностью лет их можно считать ровесниками, Дракон будет постарше. Годика этак на 3-4.

N>Я о нем узнал вчера, но мы не в политике и меня слабо интересуют вопросы исторического первенства.

Вот так и появляются "Иваны, не помниющие родства". Конкретно, в данном случае, в IT.

N>Какие преимущества дает Дракон по сравнению с LabView сегодня?

Тем, что используется у Пилюгина. В чем и как — здесь уже перечисляли.

И потом, на кой хер, я должен, даже сейчас пусть и умозрительно, поддерживать ЧУЖУЮ разработку, если есть НАША?

Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование...
ИМХО, как средство визуализации, это классная вещь. Как инструмент разработки, не очень, т.к. большинство людей мыслят словами, соответственно выражать мысли словами им проще и удобней.

Здравствуйте, kig, Вы писали:

B>>Во.. Может даже и встречались

Ну, а про слухи это дело такое. Наши тоже щеки надували на свои разработки..А было все тупо как двери. Но работало.

kig>

kig>Ну а у Владимира Даниловича Дракон "взлетел". Сначала в "детском" варианте на Буране. А затем, как я в курсе, в самые голодные годы работа не прекращалась. И сейчас пользуется у Пилюгина.

kig>Так многие здесь, вместо того, что бы хотя бы проявить уважение, что не все пошло в корзину, что благодаря и вопреки, не зная, когда это начиналось, не зная, что эта разработка ровесник с LabView, обсирают со всей дури и задают дурацкие вопросы, "почему я labview знаю, а Дракона — нет".
Я сказал что тупо, но работало. Для инженера это и есть уважуха. Наше тоже запустило.. И тоже уважуха.. Но надо же смотреть вперед.. В наше время это уже вчерашний день..Я не задаю дурацкие вопросы у меня уже есть сравнительно умные ответы..
Алгоритмов самих по себе не бывает. Он состоит из шагов. Определяя эти шаги можно сделать из не разрешимого аглоритма разрешимый.. Но это теория.. А практически отсюда следует что алгоритм без определения этих шангов вообще ничто. Заниматься этим "ничто" глупо. Но можно. Можно даже получить практический результат, но я этим заниматься не хочу по вышеуказанным причинам. Занимающимся этим моя не уважуха!
Перевожу на бытовой язык. Когда ребенок произносит слово "мама" это вызывает гордость.. Но если он в 25 лет кроме этого ничего не произносит это дебилизм.

Здравствуйте, kig, Вы писали:

N>>Я о нем узнал вчера, но мы не в политике и меня слабо интересуют вопросы исторического первенства.
kig>Вот так и появляются "Иваны, не помниющие родства". Конкретно, в данном случае, в IT.

ТС вроде апеллировал к техническим преимуществам языка, а не к патриотизму. Впрочем скорее всего в вопросе первенства ты тоже не прав.

kig>И потом, на кой хер, я должен, даже сейчас пусть и умозрительно, поддерживать ЧУЖУЮ разработку, если есть НАША?
Может тогда заодно и "Наше Усе" Эльбрус откопаем? Судя по ролику Дракон отстает от LabView на сравнимое число человеко-лет. И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового.

Выскажусь и я.

Возьмём обычную книгу. Вся книга — текст. Запомнится ли по прочтении весь текст книги дословно? Конечно, нет. Если в книге будет несколько рисунков (или схем, графиков, диаграмм), то как раз они запомнятся.

Возьмём книгу комиксов (или мангу). Вся книгу — рисунки. Запомнятся ли по просмотру все рисунки? Опять же, нет. А вот немногочисленный текст в данном случае запомнится лучше.

Думаю, вывод очевиден: бессмысленно сравнивать небольшую блок-схему, UML-схему, схему Дракона с текстом большой программы.
Следует пояснять код (в текстовом виде) небольшим количеством диаграмм/схем/рисунков — это будет способствовать пониманию. Но абсолютно всё в виде рисунков/схем — затруднит понимание.

P.S.
Хотелось бы задать вопрос апологетам Дракона: если язык так хорош, то где написанный вами софт? Покажите реальные примеры, которые можно запустить и поиметь профит. Ведь по вашим утверждениям процесс программирования упрощается на порядки, значит софт должен клепаться как горячие пирожки на конвейере. Так где он, написанный лично вами?

Здравствуйте, kig, Вы писали:

C>>Так, а теперь для чего конкретно он использовался. Я всё ещё не верю, что на нём писали сколь-либо заметное количество (если вообще) работающего кода.
kig>здесь
kig>Или опять будешь брызгать слюной про вранье?
Не верю. Я так и не дождался ссылок на авторитетные источники.

Тем более, что если работа была закончена в 96-м году.

kig>Кстати, а по поводу LabView (здесь уже высказывалось мнение, что это очень похожие разработки), побрызгать не хочешь? Что это отстой ну и т.п. А заодно побрызгать в сторону Apple, ведь первая версия LabView как раз для яблока была зарелийзена?
Мне на него пофиг — его не пихают как панацею для всего. В своих нишах графические редакторы даже могут быть удобны — с этим никто и не спорит.

Но вот когда устаревшую на 50 лет идеологию пихают как панацею против всего, да ещё и напрямую студентам — нет уж.

Здравствуйте, kig, Вы писали:

kig>обсирают со всей дури и задают дурацкие вопросы, "почему я labview знаю, а Дракона — нет".

Вопрос был другой и без всяких обсираний.

В чем отличие этой программы от LabView?

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

Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат.

Поэтому очень хотелось бы услышать его комментарии. Если Дракон лицензирован под ОSS и имеет нормальную IDE и кодогенератор, возможно он был бы интересен.

Здравствуйте, WolfHound, Вы писали:

V>>И никто не пишет компиляторы прямо по ТЗ.
WH>Я пишу.

Значит, такое ТЗ.

V>>Используется нейтральное БНФ для описания спецификаций независимо от подробностей реализации компилятора. А ты собрался эти подробности вытащить на уровень спецификаций. Тем самым ты собрался прибить гвоздями спецификацию к реализации... Это конфуз, коллега. Неужели история с ПЕГ тебя не научила, что всегда может найтись чуть лучшее решение, чем было использовано до этого?
WH>Открываем стандарт C# и смотрим как там заданы приоритеты операторов и понимаем что EBNF не подходит даже для спецификации.

Приоритеты операторов задают семантику не влияя на синтаксис. EBNF не предназначен для задания семантики.

Здравствуйте, vdimas, Вы писали:

V>Приоритеты операторов задают семантику не влияя на синтаксис. EBNF не предназначен для задания семантики.

И этот человек говорит про кашу в голове.
Если брать полный синтаксический анализ. Включая то, что твоя секта записала в семантический, ибо не смогла формализовать. То станет ясно, что в общем случае (a + b) * c и a + (b * c) могут иметь разные типы. И как следствие одна строка может принадлежать языку, а вторая нет.
Таким образом, приоритеты операторов часть синтаксиса.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Я работаю в Пилюгинском центре всю жизнь (с 1961 года).
ВП>Участвовал в разработке СУ как баллистических ракет, так и космических проектов.

Вызывает совершенно искренний интерес и уважение.

Но вернемся к Дракону.
ВП>Это не так. Инженеры фактически пишут программы (хотя они не знают об этом).
Вы им об этом так и не сказали?

ВП>Посмотрите внимательнее на структуру технологии. Слева написано
ВП>«Программирование без программистов». Это не пустые слова.
ВП>http://drakon.su/_media/biblioteka/grafit_a4.pdf

Первый вопрос из тех что вызвала картинка — программист в процессе отладки может исправлять ошибки, что логично иначе его роль совсем непонятна — транслятор, кодогенератор и компановщик могут быть вызваны без участия человека. И что, после исправления этих ошибок ГРАФИТ и ФЛОКС-данные нужно сгенерировать вновь для их исправления? Тогда в схеме не показаны обратные связи делающие её совсем не такой красивой и простой. То, что не показаны совсем не простые (не поймёшь когда с программистом, а когда с остальными инженерами) обратные связи с этапом отработки программ очевидно.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, WolfHound, Вы писали:

V>>Приоритеты операторов задают семантику не влияя на синтаксис. EBNF не предназначен для задания семантики.
WH>

И этот человек говорит про кашу в голове.
WH>Если брать полный синтаксический анализ. Включая то, что твоя секта записала в семантический, ибо не смогла формализовать.

Смогла, просто отнесла полную грамматику языка к КЗ, но обязательно даже помимо грамматики есть семантика.

WH>То станет ясно, что в общем случае (a + b) * c и a + (b * c) могут иметь разные типы. И как следствие одна строка может принадлежать языку, а вторая нет.

Детсад, сорри. В рамках техники парсинга текста даже на КЗ-парсере это невозможо разрулить в общем случае. Например, имеем некий файл-исходник в C#. Включая его в разные проекты, с разными определениями одних и тех же идентификаторов-типов для упомянутых переменных a, b и c, как в соседних файлах-исходниках проекта, так и через зависимые сборки, мы можем получать разную семантику и как следствие — принадлежность к языку или нет.

(В этом плане С++ более последователен, т.к. должен описывать через #include зависимости конкретной единицы компиляции явно.)

WH>Таким образом, приоритеты операторов часть синтаксиса.

Для C# это не так ввиду того, что типы оперируемых переменных могут быть объявлены "где-то еще" — в зависимых сборках. Т.е. даже фокус с "тупой" склейкой всех файлов проекта, чтобы рассуждать о чисто текстовой стадии разбора — не поможет. В итоге это "где-то еще", этот контекст, не может быть обработан самим парсером ни в одной из техник, весь этот контекст дается "свыше" и называется общим словом "семантика".

Здравствуйте, novitk, Вы писали:

N>И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового.

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

Здравствуйте, vdimas, Вы писали:

V>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

Обращаюсь к vdimas-у, а не к автору топика Владимиру, потому как терминология vdimas-а мне ближе и понятнее, возможно vdimas и меня поймет скорее.

На сколько я понял из топика (а специально не интересовался), в ДРАКОН-е не очень гладко с функциональным программированием. Собственно, оно и понятно, т.к. ФП записывает алгоритмы в терминах преобразования данных, а ДРАКОН записывает шаги/активности и их ветвление, то есть в крайней степени императивен.

Вопрос в том, а где же в ДРАКОН-е хранятся и ходят данные под капотом? Взять тот же факториал. Шаги — оно понятно, из каких шагов состоит вычисление. Как записывается передача данных от шага к шагу? Или это записывается "под" схемой во вставках на языке генерируемых исходников? Если это так, то боюсь, что глядя на схему, может возникнуть непонимание алгоритма. В случае факториала — фиг с ним, т.к. алгоритм тривиален. А в более сложных случаях? Ну например, depth-first-search, или генератор перестановок?

Где же все-таки лежат данные?
Я полагаю что схема в ДРАКОН-е является грубым аналогом объекта в том плане что она является экземпляром, который хранит поля, необходимые для работы. Наверное это не совсем верно, т.к. под капотом схемы данные могут лежать и в глобальных переменных. Возможно схема есть аналог статической функции, которая принимает необходимые данные через набор параметров? Как вообще принято в ДРАКОН-е? Может это остается на откуп подкапотным программистам?

Здравствуйте, pagid, Вы писали:

P>Первый вопрос из тех что вызвала картинка — программист в процессе отладки может исправлять ошибки, что логично иначе его роль совсем непонятна — транслятор, кодогенератор и компановщик могут быть вызваны без участия человека. И что, после исправления этих ошибок ГРАФИТ и ФЛОКС-данные нужно сгенерировать вновь для их исправления? Тогда в схеме не показаны обратные связи делающие её совсем не такой красивой и простой. То, что не показаны совсем не простые (не поймёшь когда с программистом, а когда с остальными инженерами) обратные связи с этапом отработки программ очевидно.

Вы правы — картинка неполная.
Это реально работающая технология, имеющая сложную структуру. Объяснить ее в рамках форума невозможно.
Сделаю лишь главные пояснения.

1. Технология предназначена для разработки программ для компьютера Бисер, разработанном во ФГУП «НПЦАП».
Бисер — трехкратно резервированный компьютер, сохраняющий работоспособность при любом одном отказе аппаратуры.

2. Компьютер Бисер устанавливается на борту ракеты в качестве бортовой ЦВМ (БЦВМ). А также на земле в составе НКСУ (наземный комплекс системы управления).
Наземный Бисер называется НЦВМ.

3. Справа на картинке есть квадратик «Программа формирования модели памяти». На нашем жаргоне «модель памяти» — это то, что до начала работы (до начала режима) загружается в компьютер Бисер.

4. В НЦВМ и БЦВМ загружаются совершенно разные программы (разные модели памяти). Кроме того, они отличаются для РАЗНЫХ РЕЖИМОВ работы.

5. Что такое режим работы?
Для простоты дам пояснения на примере наземного комплекса системы управления.

6. Наземный комплекс СУ обеспечивает проведение режимов работы, необходимых для испытаний, подготовки и пуска ракеты:

• режим регламентных испытаний;

• режим защитных операций;

• режим проверочных включений;

• режим комплексных испытаний;

• режим предстартовой подготовки.

7. Режимы осуществляются в соответствии с принятой технологией на всех рабочих местах: КИС, ТК и СК.

• КИС — контрольно-испытательная станция космодрома

• ТК — технический комплекс космодрома

• СК — стартовый комплекс космодрома

8. Все режимы работы выполняются автоматически с помощью НЦВМ Бисер и БЦВМ Бисер.

Чтобы запустить режим, оператор выполняет ограниченное число ручных операций:

• включает наземный комплекс СУ;

• в диалоговом режиме выбирает нужный режим;

• выдает команду на начало автоматического выполнения режима;

• после этого процессы проверок и подготовки выполняются наземным комплексом СУ и бортовой СУ автоматически.

9. Вернемся к картинке. Все исправления ошибок идут только через инженеров. Программист не может сам тайком от инженера исправить ошибку. Это может быть только по договоренности с инженером.

10. Инженеры делают только прикладные программы, но не системные.

11. Системные программы делают только программисты.

12. Инженер не может вызвать транслятор, анализатор, кодогенератор и т.д. самостоятельно — это непосильный для него труд. Он и слов таких не знает. И он не в состоянии понять листинги результатов. Здесь без программистов не обойтись.

13. Распределение работ между инженерами и программистами — это тонкая материя. Если угодно, это наука. (Пока еще не созданная и никем не описанная). Я владею азами этой науки только на основании опыта.

14. Приведу пример. ФЛОКС — это описание структур данных. Эти структуры создают инженеры на понятном для них языке. Программисты заносят флокс-описания в реляционную базу данных ФЛОКС.

Однажды возник вопрос: Кто должен выпускать документацию на базу данных ФЛОКС?

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

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

Чем дело кончилось?

Я придумал новый документ под названием «Флокс-формуляр», попросил отдел нормализации и стандартизации узаконить его.

Документ был узаконен в Головном институте нашей отрасли ЦНИИмаш. И вступил в законную силу.

Теперь инженеры при выпуске полного комплекта документации для каждой новой проектируемой ракеты обязательно выпускают и комплект флокс-формуляров, описывающих содержание базы данных ФЛОКС .

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>9. Вернемся к картинке. Все исправления ошибок идут только через инженеров. Программист не может сам тайком от инженера исправить ошибку. Это может быть только по договоренности с инженером.
ВП>12. Инженер не может вызвать транслятор, анализатор, кодогенератор и т.д. самостоятельно — это непосильный для него труд. Он и слов таких не знает. И он не в состоянии понять листинги результатов. Здесь без программистов не обойтись.
Взаимоисключающие параграфы детектед.

ВП>13. Распределение работ между инженерами и программистами — это тонкая материя. Если угодно, это наука. (Пока еще не созданная и никем не описанная). Я владею азами этой науки только на основании опыта.
Как всё запущено...

Т.е. как и предполагалось — ДРАКОН не используется для написания кода как такового, а только для рисования документации, по которой программисты с матом потом пишут код.

Здравствуйте, vdimas, Вы писали:

V>Смогла, просто отнесла полную грамматику языка к КЗ,
Не смогла придумать, как их разбирать.

V>но обязательно даже помимо грамматики есть семантика.
Только к разбору текста она не относится.

V>Детсад, сорри.
Детский сад.
Ты даже не понимаешь на что способны КЗ грамматики.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Cyberax, Вы писали:

C>Т.е. как и предполагалось — ДРАКОН не используется для написания кода как такового, а только для рисования документации, по которой программисты с матом потом пишут код.

Уважаемый Алексей!

Вы ошибаетесь

Здравствуйте, Владимир Паронджанов, Вы писали:

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

Здравствуйте, WolfHound, Вы писали:

V>>Смогла, просто отнесла полную грамматику языка к КЗ,
WH>Не смогла придумать, как их разбирать.

Никто не смог пока. Это нерешенная на сегодня проблема. В твоем TDOP обрабатывается лишь узкий подкласс, фактически частный случай. Потому что используется не обобщенный парсер, а вполне конкретный алгоритм разбора. Пусть даже настраиваемый и тебя эта настраиваемость маленько торкнула. Ради бога. Компиляторы С++ тоже имеют некий конкретный алгоритм разбора конкретных сценариев КЗ, как компиляторы любых КЗ-языков.

V>>но обязательно даже помимо грамматики есть семантика.
WH>Только к разбору текста она не относится.

Угу, аргумент про парсинг в условиях уже определенного "свыше" контекста и зависимостей ты проигнорировал.

WH>Ты даже не понимаешь на что способны КЗ грамматики.

Во-первых понимаю. Во-вторых — а толку, если их невозможно парсить в общем виде?

> V>Смогла, просто отнесла полную грамматику языка к КЗ,
> Не смогла придумать, как их разбирать.
>
> V>но обязательно даже помимо грамматики есть семантика.
> Только к разбору текста она не относится.
>
> V>Детсад, сорри.
> Детский сад.
> Ты даже не понимаешь на что способны КЗ грамматики.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>Никто не смог пока. Это нерешенная на сегодня проблема. В твоем TDOP обрабатывается лишь узкий подкласс, фактически частный случай. Потому что используется не обобщенный парсер, а вполне конкретный алгоритм разбора. Пусть даже настраиваемый и тебя эта настраиваемость маленько торкнула. Ради бога. Компиляторы С++ тоже имеют некий конкретный алгоритм разбора конкретных сценариев КЗ, как компиляторы любых КЗ-языков.
А общий вид нахрен никому кроме теоретиков не нужен.
Ну и не забывай что если в языке есть требование объявления до использования то этот язык КЗ.

V>Угу, аргумент про парсинг в условиях уже определенного "свыше" контекста и зависимостей ты проигнорировал.
Нет там никаких аргументов. Одни заблуждения.

WH>>Ты даже не понимаешь на что способны КЗ грамматики.
V>Во-первых понимаю. Во-вторых — а толку, если их невозможно парсить в общем виде?
Не понимаешь. Иначе ты бы не говорил что невозможно задать КЗ грамматику для кода на C#.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, elmal, Вы писали:

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

Вы правы. Обработка ошибок пронизывает алгоритм.

E> Если же думать о возможных ситуациях каждый раз, получается очень и очень запутанно и неструктурировано.

Нет, это не так. Никакой путаницы нет. Все структурно.
Структуризация понимается по правилам Дракона (двумерное структурное программирование), которое намного удобнее чем классическое (одномерное)структурное программирование).

Обработка ошибок на драконе выглядит очень просто, даже элементарно.
Любая, сколь угодно сложная обработка ошибок.
Я в этом случае не использовал бы термин "состояние".

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

Грани резервирования называются так:

— грань резервирования А,

— грань резервирования В,

— грань резервирования С.

Поэтому при проверке проверяются все сочетания:

А
В
С
АВ
АС
ВС
АВС

В частности, при проверке грани А компьютера Бисер, отключаются грани В и С компьютера Бисер.

при проверке грани В компьютера Бисер, отключаются грани А и С компьютера Бисер.

при проверке грани С компьютера Бисер, отключаются грани А и В компьютера Бисер.

при проверке граней А и В компьютера Бисер, отключается грань С компьютера Бисер.

И так далее.

При проверке и выявлении ошибок важную роль играет понятие ГЛАВНЫЙ МАРШРУТ (когда все хорошо и ошибок нет).

И правило: ГЛАВНЫЙ МАРШРУТ ИДЕТ ПО ШАМПУРУ

Все ошибки располагаются на побочных маршрутах, которые располагаются справа от главного маршрута.

Правило ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ.

Посмотрите здесь http://drakon-practic.ru/drakon.pdf

Шампур стр 13

Главный маршрут стр 14

Чем правее, тем хуже стр 15-17

Главный маршрут силуэта стр 21, 22

См. также стр 47 рис 42

стр 50 рис 45

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Все ошибки располагаются на побочных маршрутах, которые располагаются справа от главного маршрута.
ВП>Правило ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ.
Это понял. Но. Я в примерах увидел, что проверка на наличие ошибок указывается явно. И переход на побочный маршрут идет явно. Каждый раз явно нужно инициировать проверки, что легко забыть. Смотрим рисунок 45 — история с кашей. Мы вызываем алгоритм "Свари кашу". А далее проверяем возможные ошибки — каша подгорела или каша пересолена. Во первых, мы какую то ошибку можем пропустить, например это ошибка, что нам вместо сливочного масла дали машинное. Что в этом случае делать — еще одну проверку на основном маршруте, названное "непредвиденная ошибка"? Причем это делать на практике нужно всегда, ибо всегда может случиться, что выкинется что то такое, что я изначально не предполагал. Алгоритм "Свари кашу" может писаться другим человеком параллельно, он потом может изменения какие внести, не уведомив меня, и т.д. Есть ли валидация на случаи, что все возможные ошибки обработаны и сделан переход на побочный маршрут? Возможно я даже соглашусь, что такая запись достаточно наглядна, и вполне возможно, что лучше и не придумать. Но вот будет громоздковато ИМХО.

И далее. Что то мне подсказывает, что автогенеренный код будет просто ужасен, и его будет крайне проблематично читать текстом. А читать текстом в любом случае придется, ибо детали реализации даже если на схеме и будут показаны, то будут разбросаны на практике по разным листам. Мне, например, весьма интересно, как на практике алгоритм "Свари кашу" будет уведомлять родительский алгоритм о том, что каша подгорела. Явный возврат контекста, содержащего результат выполнения и возможные проблемы? Если такое делать для всех, то получим весьма неслабый оверхед. Глобальные переменные какие? Или не глобальные, а алгоритм представляет собой объект, у которого можно выполнить метод execute, а потом вернуть проблемы и результаты? А если мы генерим Фортран код?

Здравствуйте, Владимир Паронджанов, Вы писали:

C>>Т.е. как и предполагалось — ДРАКОН не используется для написания кода как такового, а только для рисования документации, по которой программисты с матом потом пишут код.
ВП>Уважаемый Алексей!
ВП>Вы ошибаетесь
Замечательно. Тогда не составит труда привести примеры кода, надеюсь? Скажем строк так на 10000? Уж за 25 лет-то можно было написать его.

Нет? Тогда мне доказательства "мамой клянусь!" неинтересны.

Да, моего OpenSource-кода примерно на порядок больше. Проприетарного кода — на полтора порядка.

Здравствуйте, WolfHound, Вы писали:

V>>Никто не смог пока. Это нерешенная на сегодня проблема. В твоем TDOP обрабатывается лишь узкий подкласс, фактически частный случай. Потому что используется не обобщенный парсер, а вполне конкретный алгоритм разбора. Пусть даже настраиваемый и тебя эта настраиваемость маленько торкнула. Ради бога. Компиляторы С++ тоже имеют некий конкретный алгоритм разбора конкретных сценариев КЗ, как компиляторы любых КЗ-языков.
WH>А общий вид нахрен никому кроме теоретиков не нужен.

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

WH>Ну и не забывай что если в языке есть требование объявления до использования то этот язык КЗ.

С чего ты решил, что кто-то забыл? И вообще причем тут?

V>>Угу, аргумент про парсинг в условиях уже определенного "свыше" контекста и зависимостей ты проигнорировал.
WH>Нет там никаких аргументов. Одни заблуждения.

Отличные ответные аргументы.

WH>>>Ты даже не понимаешь на что способны КЗ грамматики.
V>>Во-первых понимаю. Во-вторых — а толку, если их невозможно парсить в общем виде?
WH>Не понимаешь. Иначе ты бы не говорил что невозможно задать КЗ грамматику для кода на C#.

В условиях переопределения операторов где-то в зависимых сборках? Ес-но невозможно. Потому что надо начинать говорить об ABI платформы и ее семантике, а это уже мимо парсинга.

На самом деле особых проблем с однозначным парсингом современных языков программирования ес-но нет. Потому что никто не зацикливается на самом автомате-парсере, как ты, а использует его лишь как часть более общего алгоритма разбора. И тогда ABI платформы или объявление типов "где-то еще" сразу перестает быть проблемой формальных грамматик. Пример фильтрации типов токенов при передаче их от лексера к парсеру для случая С++ я уже приводил. Тривиальная же операция.

Здравствуйте, grosborn, Вы писали:

G>И не понятно, это разборки двух маленьких детей или двух толстых бородатых мужиков.

Двух ленивцев, скорее.

G>Закинуть этот диалог на башорг?

Дык, было бы смешно, можно было бы закинуть.

Здравствуйте, samius, Вы писали:

S>Где же все-таки лежат данные?
S>Я полагаю что схема в ДРАКОН-е является грубым аналогом объекта в том плане что она является экземпляром, который хранит поля, необходимые для работы. Наверное это не совсем верно, т.к. под капотом схемы данные могут лежать и в глобальных переменных. Возможно схема есть аналог статической функции, которая принимает необходимые данные через набор параметров? Как вообще принято в ДРАКОН-е? Может это остается на откуп подкапотным программистам?

Не про дракон, но там, где я видел квадратики (workflow foundation, bpel), оно (весьма условно) работало так. Схема — экземпляр некоего класса, у него есть набор входных свойств (заполняется при вызове схемы), выходных свойств (нужно заполнить перед выходом) и просто свойств, которые хранят какое-то промежуточное состояние. Время жизни экземпляра — по инстансу на вызов. Квадратики в целом двух видов.
— Методы класса. То есть при входе в квадрат просто выполняется код с полным доступом к свойствам схемы. Сюда же, пожалуй, можно отнести всякие циклы и ветвления, которые работают со свойствами схемы.
— Инстансы других классов (другие схемы, точки входа в какое-то внешнее АПИ и т.п.). Перед входом в такой квадрат ты должен заполнить его входные свойства, после выхода можно работать с выходными.

Думается, что в драконе сделано что-то подобное.

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

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, samius, Вы писали:

S>>Где же все-таки лежат данные?

MC>Не про дракон, но там, где я видел квадратики (workflow foundation, bpel), оно (весьма условно) работало так. Схема — экземпляр некоего класса, у него есть набор входных свойств (заполняется при вызове схемы), выходных свойств (нужно заполнить перед выходом) и просто свойств, которые хранят какое-то промежуточное состояние. Время жизни экземпляра — по инстансу на вызов. Квадратики в целом двух видов.
WWF я тоже видел. Для "замены" языков общего назначения он явно не годится. Т.е. идеи типа "а давайте поиск в графе напрограммируем в квадратиках WWF" — явно бредовые. Даже для своей ниши, а именно программирования воркфлоу, (имхо) в большинстве случаев он уступает специальным велосипедам. Преимущества в нем лишь те, что он уже написан и работает, + имеет визуальный дизайнер из коробки.

MC>- Методы класса. То есть при входе в квадрат просто выполняется код с полным доступом к свойствам схемы. Сюда же, пожалуй, можно отнести всякие циклы и ветвления, которые работают со свойствами схемы.
MC>- Инстансы других классов (другие схемы, точки входа в какое-то внешнее АПИ и т.п.). Перед входом в такой квадрат ты должен заполнить его входные свойства, после выхода можно работать с выходными.

MC>Думается, что в драконе сделано что-то подобное.
Что-то мне кажется что ДРАКОН лишь генерит скелет из goto и старательно запихивает между ними код, вставленный в схему.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, novitk, Вы писали:

N>>И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового.

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

Я не очень понимаю, какую позицию ты отстаиваешь в споре с Cyberax-ом. Он вроде всего лишь выступает против применения визуального подхода по сравнению с текстовыми для решения реальных задач из за неадекватного инструментария с которым он имел "счастье" работать. Если у тебя есть другой опыт, расскажи. Только не абстрактно, а конкретно про используемые тобой инструменты и задачи.

Здравствуйте, elmal, Вы писали:

E>Это понял. Но. Я в примерах увидел, что проверка на наличие ошибок указывается явно. И переход на побочный маршрут идет явно.

Да, Вы правы. Все надо задавать ЯВНО.

E>Каждый раз явно нужно инициировать проверки, что легко забыть.

Слова «легко забыть» говорят о серьезной опасности.
Можно ли принять меры против этой опасности?

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

Почему? Потому что первоисточником знаний является инженер. Инженер стоит на высшей ступени знаний. Он знает данный вопрос (как обрабатывать ошибки) намного лучше, чем программист. Программист получает знания от инженера.

В основе технологии Графит-Флокс лежит принцип:

КТО ОБЛАДАЕТ ЗНАНИЯМИ, ТОТ И ДОЛЖЕН ИХ ФОРМАЛИЗОВАТЬ.

Это принцип позволяет создать наиболее надежную защиту от такого несчастья, как «легко забыть».

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

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

E>Смотрим рисунок 45 — история с кашей. Мы вызываем алгоритм "Свари кашу". А далее проверяем возможные ошибки — каша подгорела или каша пересолена. Во первых, мы какую то ошибку можем пропустить, например это ошибка, что нам вместо сливочного масла дали машинное. Что в этом случае делать — еще одну проверку на основном маршруте, названное "непредвиденная ошибка"? Причем это делать на практике нужно всегда, ибо всегда может случиться, что выкинется что то такое, что я изначально не предполагал.

Это дело инженера. Как он решит, так и правильно. Учтем также, что у инженера есть начальник лаборатории. Последнее слово за начальником лаборатории. Программисты здесь ни при чем. Если начальник лаборатории посчитает нужным, он может сходить к программистам посоветоваться. Но решение принимают не программисты, а инженеры. Никто лучше их не знает, какие могут быть ошибки и что с ними делать.

E>Алгоритм "Свари кашу" может писаться другим человеком параллельно, он потом может изменения какие внести, не уведомив меня, и т.д.

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

E>Есть ли валидация на случаи, что все возможные ошибки обработаны и сделан переход на побочный маршрут?

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

Если есть какой-то системный вопрос, относящийся к системному программированию, тут командуют программисты. (Это упрощенная схема, бывают исключения из правила).

E>Возможно я даже соглашусь, что такая запись достаточно наглядна, и вполне возможно, что лучше и не придумать. Но вот будет громоздковато ИМХО.

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

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

Ответ на Ваш второй абзац я дам позже

Мои ответы относятся только и исключительно к организации работ в НПЦАП при разработке системы управления ракет.

Здравствуйте, novitk, Вы писали:

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

N>Я не очень понимаю, какую позицию ты отстаиваешь в споре с Cyberax-ом.

Как и он, делюсь субъективным опытом.

N>Он вроде всего лишь выступает против применения визуального подхода по сравнению с текстовыми для решения реальных задач из за неадекватного инструментария с которым он имел "счастье" работать.

Дык, это не так просто объяснить человеку.

N>Если у тебя есть другой опыт, расскажи. Только не абстрактно, а конкретно про используемые тобой инструменты и задачи.

PCAD, ORCAD, CIRCAD, LabView, Mathcad, Matlab+Simulink.
Проектирование, расчеты, симуляция, разработка налоговых и аналогово-цифровых устройств. Без графики эта работа невозможна принципиально. До этих тулзов всю графику чертили ручками.

Ну и берем тот же решарпер, вижуал-студию, графы профайлеров и VCS. В общем, здесь подробней:
http://www.rsdn.ru/forum/philosophy/4754685.1.aspx
http://www.rsdn.ru/forum/philosophy/4755042.1.aspx

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Ответ на Ваш второй абзац я дам позже
ВП>Мои ответы относятся только и исключительно к организации работ в НПЦАП при разработке системы управления ракет.
Хорошо, ок. Заодно еще один вопрос. Даже 2.
1) Итак — весьма много обязанностей возложено на инженеров. Прекрасно. Это мечта многих контор, если они с этими обязанностями наконец справляются благодаря Дракону — замечательно. Только как обстоят дела с тестированием? Ошибиться может любой. И особенно инженер, особенно тот, кто сам все проектирует. Ибо у него глаз может намылиться. Потому работу проектировщика в индустрии проверяет специальный человек — тестер, который всеми силами пытается найти ошибки. Дополнительно пишутся тесты, где моделируются все возможные крайние случаи, и пытаются таким образом обнаружить ошибки. Это делать должен не инженер — у него намылен глаз, ему эту работу поручать нельзя (вернее он конечно сам то проверит 10 раз перед сдачей, но он вполне может ошибиться и что то пропустить, человеческий фактор!). Тестировать должен совершенно посторонний человек — только так можно уменьшить вероятность ошибки. И тестировать и проверять не только визуально, но и автоматизированно — написав программу, которая будет прогонять все тесты.
Так вот — а как поставлено тестирование? Как проверяется корректность работы алгоритма в целом и отдельных мелких частей в частности? Это крайне важно в этой предметной области, здесь нужно многократно все проверять и перепроверять! Неужели просто методом пристального взгляда? Если нет, то как пишут тесты и тестируют — тоже на Драконе?
2) Итого, нужны инженеры высокой квалификации. Этим инженерам дали удобный для их работы инструмент. Прекрасно. Но есть у этого оборотная сторона, для программистов инструмент будет однозначно неудобен. Ибо программист работает не с алгоритмом, а с конкретным кодом, ему придется лазить в автогенеренный код, который, как мне представляется, оставляет желать лучшего. Более того, работа программистов весьма второстепенна. Как результат, программисты высокой квалификации не захотят этим заниматься, ибо очень большая рутина, очень неудобно работать, теряется квалификация из за очень многих ограничений, да и не могут они использовать на практике многие свои знания и умения. Соответственно тем, кто долго работает, в случае каких либо проблем сменить работу крайне проблематично, ибо они обладают крайне специфичными навыками. И в случае любых проблем, им урежут зарплату не задумываясь — так как один черт им проблематично сменить работу. Соответственно это очень многие понимают, многие этого опасаются, в результате согласятся программировать далеко не самые лучшие. А те, у кого квалификация низкая (недавние студенты, или те, кто просто долго был в стороне от современного течения индустрии, в результате обладают очень ограниченным кругозором) — те вполне могут допустить ошибку, тем более в случае, когда у них значительное недовольство работой.
Так вот, что то мне подсказывают, что инженерам Дракон нравится, а вот программисты, имеющие современный опыт хотя бы в минимальном объеме, весьма и весьма на это все матерятся.

> Только как обстоят дела с тестированием? Ошибиться может любой. И особенно инженер, особенно тот, кто сам все проектирует.

Вот кстати хорошее замечание. Могу указать на слабое место, которое и приводит к падению спутников. Есть условно говоря два вида тестирования этих комплексов, главная часть — тесты которые пишет инженер. Он тестирует функциональность, поведение и ряд параметров, по которым и определятся работоспособность блоков и системы в целом. Эти тесты это даже не одна, а ряд совершенно отдельных задач, которые выполняются еще и другими людьми. Инженер написал тесты, а другой может проектировать для него стенды и в свою очередь давать задание другим программистам для написания программы для испытаний.
И вторая часть — тестирование самой программы которую пишет программист. Вот тут косяк, программиста в этом деле обычно или не контролируют достаточно, или контролируют внутри отдела. А тесты реализаций алгоритмов не в комплексе с программой испытаний инженера. Инженер не может создать программу испытаний для программиста, программист в свою очередь не владеет темой в комплексе. И даже по ТЗ написав безошибочную программу, в работающем комплексе возникают ошибки и сбои.
И это косяк декомпозиции.

Posted via RSDN NNTP Server 2.1 beta

G>И это косяк декомпозиции.

Скорее косяк возникающий при декомпозиции и при отсутствии системного подхода.

Здравствуйте, vdimas, Вы писали:

V>PCAD, ORCAD, CIRCAD, LabView, Mathcad, Matlab+Simulink.
Про PCAD ничего не знаю, но остальные продукты не помогают в решение проблем общего программирования о котором писал ТС. В отличие от ФП, зависимых типов, DSL-ов, динамики, мета-программирования и т.д. о которых принято говорить на этом форуме. Впрочем для меня уже понятно, что Дракон это просто аналог LabView для визуализации и отладки логики контроллеров оборудования инженерами.

Здравствуйте, grosborn, Вы писали:

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

G>И вторая часть — тестирование самой программы которую пишет программист. Вот тут косяк, программиста в этом деле обычно или не контролируют достаточно, или контролируют внутри отдела. А тесты реализаций алгоритмов не в комплексе с программой испытаний инженера. Инженер не может создать программу испытаний для программиста, программист в свою очередь не владеет темой в комплексе. И даже по ТЗ написав безошибочную программу, в работающем комплексе возникают ошибки и сбои.
G>И это косяк декомпозиции.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, novitk, Вы писали:

N>Про PCAD ничего не знаю, но остальные продукты не помогают в решение проблем общего программирования о котором писал ТС. В отличие от ФП, зависимых типов, DSL-ов, динамики, мета-программирования и т.д. о которых принято говорить на этом форуме. Впрочем для меня уже понятно, что Дракон это просто аналог LabView для визуализации и отладки логики контроллеров оборудования инженерами.
Я бы не сказал, что аналог LabView. LabView заточено на схемы. А Дракон в принципе по наглядности, если правильно использовать, вполне неплохая нотация для документирования и постановки задач по крайней мере в своей предметной области. По крайней мере те примеры, что идут в книге — они действительно достаточно наглядны. По крайней мере UML мне однозначно гораздо меньше нравится. И именно для инженеров — специалистов в предметной области, но не программистов, я вполне допускаю, что язык очень и очень удобен. Книжка вроде тоже весьма неплоха (смотрел мельком, вполне возможно, что даже прочитаю в будущем), читается хорошо, с картинками — красота. И вполне допускаю, что для своей предметной области он вполне неплох. Правда я далеко не уверен, что получится бухгалтеров научить этому языку, все таки язык однозначно для людей с техническим складом ума

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

Здравствуйте, elmal, Вы писали:

E>А Дракон в принципе по наглядности, если правильно использовать, вполне неплохая нотация для документирования и постановки задач по крайней мере в своей предметной области. По крайней мере те примеры, что идут в книге — они действительно достаточно наглядны. По крайней мере UML мне однозначно гораздо меньше нравится.

То есть ты рассматриваешь Дракон не для программирования, а лишь для документации.
Чем же именно он лучше для этих целей чем диаграммы поведения UML?

Здравствуйте, novitk, Вы писали:

V>>PCAD, ORCAD, CIRCAD, LabView, Mathcad, Matlab+Simulink.
N>Про PCAD ничего не знаю, но остальные продукты не помогают в решение проблем общего программирования о котором писал ТС.

Значит, про остальные тоже ничего не знаешь.

LabView, Mathcad, Matlab+Simulink.

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

N>В отличие от ФП, зависимых типов, DSL-ов, динамики, мета-программирования и т.д. о которых принято говорить на этом форуме.

Мало ли где что принято. Реальная проблема стоит в наличии пропасти м/у инструментами расчета/моделирования и собственно программированием. Этой пропасти быть не должно. Сама пропасть состоит исключительно в плохопереносимом и плохоразбираемом текстовом представлении исходного кода программ на современных популярных языках и ни в чем больше. Реально ситуация на сегодня такова, что сами по себе текстовые исходники представляют из себя неорганизованный сброд текстовых файлов. Чтобы что-то полезное из них извлечь, необходимо отталкиваться от файлов проектов, в котором упоминаются не только исходники, но так же их зависимости, флаги компиляции и все такое прочее, что иногда кардинальным образом влияет на семантику этих несамодостаточных текстовых файлов. Получается очевидная проблема, что кол-во языков надо умножать на кол-во форматов файлов проектов, чтобы как-то это окучить. Но даже и этого мало, бо в том же Linux зачастую многое, относящееся к компиляции, задается переменными окружения конкретного сеанса оболочки. А это залет, курсант — через это вообще никак не перепрыгнуть.

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

Дракон можно рассматривать как попытку организации такой инфраструктуры.

N>Впрочем для меня уже понятно, что Дракон это просто аналог LabView для визуализации и отладки логики контроллеров оборудования инженерами.

Ничего тебе не понятно и близко.

Здравствуйте, novitk, Вы писали:

N>То есть ты рассматриваешь Дракон не для программирования, а лишь для документации.
N>Чем же именно он лучше для этих целей чем диаграммы поведения UML?

Тем, что они уж сильно ограничены.

Здравствуйте, pagid, Вы писали:

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

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

Здравствуйте, Ops, Вы писали:

Ops>В свое время писали о сбоях каких-то космических устройств, произошедших из-за каши из метрических и дюймовых величин.
Припоминаю подобноные истории про авиацию. Может у американцев или европейцев было что-то и в космонавтике.

Ops> Такие ошибки на стенде отловить не всегда реально.
Не вижу особого отличия от других видов ошибок.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, novitk, Вы писали:

N>То есть ты рассматриваешь Дракон не для программирования, а лишь для документации.
Естественно, лично я в здравом уме пытаться программировать на визуальных языках не буду больше даже пытаться, на любом. Даже на сверхпроработанном, в развитие которого вбросили 100 миллиардов долларов, и в котором ни единой ошибки и который просто предугадывает то, что мне нужно сделать. Ибо текстом я сделаю гораздо быстрее и качественней.
В случая водопада без итераций Дракон можно рассматривать частично и для программирования. Естественно частично. Специалист по предметной области нарисовал диаграмку, диаграмку 10 раз проверили — она верна, изменений не будет. Далее нагенерили шаблон (возможно вместе с значительным количеством кода), и далее уже работаем с кодом и отлаживаем код.
N>Чем же именно он лучше для этих целей чем диаграммы поведения UML?
А ты попробуй научить далекого от программирования специалиста в предметной области нарисовать достаточно читаемую диаграмму поведения. Ведь будет однозначно мешанина из блоков и стрелочек, причем стрелочек с пересечением. Да и даже если просто программиста заставить рисовать это все — тоже будет мешанина стрелочек. А в Драконе интересен не сколько сам язык, сколько книга по его использованию. Написана вполне даже неплохо. Насколько я понял, нотации Дракона проработаны именно таким образом, чтоб избежать мешанины. Если нотация достаточно проста, в тоже время достаточно выразительна, плюс если заточена именно под определенный класс задач, плюс если есть хорошая документация, плюс если пользоваться средой достаточно удобно и она сразу же подталкивает тебя в нужном направлении — для целей документирования получается весьма неплохая вещь. Вполне допускаю, что некоторым непрограммистам будет даже удобно на этом полностью программы писать.

Здравствуйте, elmal, Вы писали:

E>Мне, например, весьма интересно, как на практике алгоритм "ИСТОРИЯ С КАШЕЙ" будет уведомлять родительский алгоритм о том, что каша подгорела.

ФОРМАЛИЗАЦИЯ АЛГОРИТМА «ИСТОРИЯ С КАШЕЙ»

Откроем «Краткое описание языка ДРАКОН»
http://drakon-practic.ru/drakon.pdf

На стр. 50 рис. 45 показан алгоритм ИСТОРИЯ С КАШЕЙ.
Этот алгоритм имеет два синтаксиса:

• Текстовый синтаксис;
• Графический синтаксис.

Графический синтаксис является математически строгим.
Текстовые надписи написаны на естественном языке, то есть неформально. В Графит-Флоксе это недопустимо.

Проведем формализацию, то есть заменим естественный язык на формальный язык Графит-Флокс.
Покажем это на примере надписи «Каша подгорела?».
На формальном языке эта надпись превращается во флокс-идентификатор
ПЛ1ЩФ.КАША.ГОРЕЛ

Таким образом, текст на русском языке Каша подгорела? преобразован в математически строгий идентификатор ПЛ1ЩФ.КАША.ГОРЕЛ

Идентификатор состоит из трех частей:

• Префикс ПЛ1ЩП

• Разделитель . (точка)

• Смысловая часть КАША.ГОРЕЛ (не более 10 символов)

Префикс состоит из 5 символов, является позиционным.

П — признак

Л —логический

1 — бортовой компьютер Бисер

Щ — аппаратура спутниковой навигации

Ф — Фрегат (разгонный блок космических аппаратов Фрегат)

Если в 3-й позиции идентификатора стоит 5, это означает наземный компьютер Бисер.

Оператор ПЛ5ЩП.КАША.ГОРЕЛ := ПЛ1ЩП.КАША.ГОРЕЛ
означает, что указанный признак пересылается из бортового компьютера в наземный. (Признак однобитовый)

Еще один пример.

Данный алгоритм называется ИСТОРИЯ С КАШЕЙ

После формализации получим идентификатор алгоритма АП1ЩП.КАША

АП — означает алгоритм-процедура.

Если написать АИ1ЩП.КАША — это означает не алгоритм-процедура, а алгоритм-исполнитель. Исполнитель (на нашем жаргоне) — это головной алгоритм, получающий управление от диспетчера режима.
И так далее.

Теперь вернемся к вопросу

Мне, например, весьма интересно, как на практике алгоритм "ИСТОРИЯ С КАШЕЙ" будет уведомлять родительский алгоритм о том, что каша подгорела.

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

Примечание. В Графит-Флоксе все идентификаторы имеют математически строгие определения. Я здесь эту проблему не рассматриваю.

Сколько всего идентификаторов? Десятки тысяч.

Все идентификаторы и их определения описываются во флокс-описаниях (флокс-таблицах).

Флокс-описания хранятся в базе данных ФЛОКС.
См. структурную схему технологии Графит-Флокс.
http://drakon.su/_media/biblioteka/grafit_a4.pdf

Для каждой ракеты (разгонный блок ДМ-SL, Протон-М, Фрегат и др.) создается своя база данных ФЛОКС.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Ответ такой. Уведомлять родительский алгоритм о том, что каша подгорела, НЕ НУЖНО. Поскольку все идентификаторы глобальные. Путаница не возникает. Потому что префикс наводит строгий порядок и задает четкое распределение ответственности.
Вот что то подобное я и предполагал. Дело не в путанице. Дело не в разделении ответственности. Глобальные идентификаторы — это крайне ужасно. Про параллелизм можно забыть сразу. А современная тенденция в программировании, и задача, которую не могут пока достаточно эффективно решить — это как максимально делать алгоритмы параллельными. В случае с глобальными идентификаторами хотя бы состояний — без шансов. Как мне сварить параллельно N каш? Да и даже если без параллелизма — тоже будут весьма интересные эффекты при многократном вызове какого либо алгоритма из разных мест.
И это даже мелочь. По сравнению с тем, что любой может случайно по невнимательности изменить значение. Или, я надеюсь, не может, и эти идентификаторы только на чтение, и устанавливать их можно только в том месте, где они определены? Хотя бы есть правило на ограничения доступа? Что родитель имеет доступ только к идентификаторам только непосредственно тех алгоритмов, который он только что вызвал? Если так, небольшое облегчение конечно. Я конечно предполагаю, что работа организована таким образом, чтобы параллелизм не допускать, а также вы нашли средства и методы, чтобы со всем этим жить, но на практике уже много десятков лет существуют более эффективные средства.

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

Здравствуйте, pagid, Вы писали:
P>Припоминаю подобноные истории про авиацию. Может у американцев или европейцев было что-то и в космонавтике.
История очень известная
http://www.osp.ru/os/1998/06/179592/

Здравствуйте, pagid, Вы писали:

Ops>>В свое время писали о сбоях каких-то космических устройств, произошедших из-за каши из метрических и дюймовых величин.
P>Припоминаю подобноные истории про авиацию. Может у американцев или европейцев было что-то и в космонавтике.
Это был epic fail с Mars Climate Orbiter.

Впрочем, у СССР был не менее facepalm'овый fail с неправильной командой Фобосу-1.

Здравствуйте, novitk, Вы писали:

N>>>И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового.
V>>Высказывались люди, которые обобщали свой субъективный опыт и характер решаемых задач на отрасль в целом. Без комментариев, как говорится.
N>Я не очень понимаю, какую позицию ты отстаиваешь в споре с Cyberax-ом. Он вроде всего лишь выступает против применения визуального подхода по сравнению с текстовыми для решения реальных задач из за неадекватного инструментария с которым он имел "счастье" работать. Если у тебя есть другой опыт, расскажи. Только не абстрактно, а конкретно про используемые тобой инструменты и задачи.
Я не считаю, что адекватный инструментарий для графического программирования вообще возможен. Попытки за 50 лет его написать (включая даже гениев IDE из JetBrains) оказались безуспешны. Тогда как текстовые языки, IDE и вообще инструментарий для работы показывают постоянное улучшение.

Так что можно сделать вывод, что графические языки — это тупик.

Понятно, что в ряде ниш они полезны и нужны. Скажем, graphedit очень удобен при экспериментах с multimedia в Винде.

Здравствуйте, ins-omnia, Вы писали:

V>> Не знаю ничего насчет именно языка ДРАКОН,... ... управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд. При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок
V>> и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах.

IO>Уже сейчас всё гораздо круче: большая часть идей, которые зарождаются у людей в голове, заранее существует в виде формальных схем, инсталируемых в головы через зомбоящик.

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

Здравствуйте, vdimas, Вы писали:

V>Значит, про остальные тоже ничего не знаешь.
Хамство не красит человека.

V>Эти инструменты используется как вспомогательные к "обычному программированию", резко увеличивая производительность для многих прикладных направлений.
Все это преминимо только для R&D, как и Excel. В коробку это нормальные люди не кладут.

V>В общем, были бы текстовые файлы популярных языков программирования самодостаточные, можно было бы еще о чем-то говорить. А так, ввиду врожденной ограниченности текстового языка лишь синтаксисом конкретного языка, имеем что имеем — необходимость во внешней обслуживающей инфраструктуре.

Smalltalk и с песней. Файлов нет, все модели прямо в памяти, синтаксиса нет. Помогает, но не сильно.

V>Дракон можно рассматривать как попытку организации такой инфраструктуры.
Дракон пока можно вообще не рассматривать за отсутсвием в нем новых идей.

ЧТО ТАКОЕ СИМУЛЬТАННОЕ ВОСПРИЯТИЕ?

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

Симультанное восприятие окружающего мира формировалось в течение многих миллионов лет — на протяжении всей эволюции человеческого зрительного аппарата и мозга.

Почему симультанное восприятие столь важно?

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

Если вас интересует эта тема, читайте здесь
http://forum.oberoncore.ru/viewtopic.php?f=62&t=989

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Если вас интересует эта тема, читайте здесь
ВП>http://forum.oberoncore.ru/viewtopic.php?f=62&t=989

Интересно, но очень спорно.

Скорость чтения никак ни является лимитирующим фактором при обучении, так как скорость
понимания или усвоения на порядок меньше.

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

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

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

Здравствуйте, FR, Вы писали:

FR>1. Скорость чтения никак ни является лимитирующим фактором при обучении, так как скорость понимания или усвоения на порядок меньше.

FR>2. Скорость чтения обычного текста вполне поднимается в разы или даже на порядок, что демонстрируют те кто освоил скорочтение. Но толку от этого мало, быстрее усваивать не получается.

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

FR>Ну и спорным является и то что чтение обычного текста не является симультанным, те же практики скорочтения показывают и доказывают обратное

Вы правы. При чтении обычного текста используются оба механизма сукцессивный и симультанный.
Но! Степень симультанности РАЗНАЯ. При чтении эргономичной графики эта степень много выше.

Предлагаю Вашему вниманию две ссылки:
http://upr.1september.ru/1999/upr36.htm

http://vovr.su/arhiv2000-04.html См. 1997 год, №2 стр. 9-18

ТЕЗИСЫ

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

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

5. Сегодня обучение алгоритмизации не рассматривается как само-
стоятельная задача, необходимая обществу.

6. Принято считать, что алгоритмизация – это часть курса програм-
мирования и вне последнего не имеет ценности для общества.

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

8. Таким образом, перед системой образования возникает принципи-
ально новая масштабная задача: организовать обучение алгоритми-
ческому мышлению для непрограммистов. То есть для подавляю-
щего большинства специалистов.

Здравствуйте, Cyberax, Вы писали:

C>Это был epic fail с Mars Climate Orbiter.
Точно! Что-то американо-марсианское крутилось у отдаленном уголке моска, но как предположение.

Только проблема не в ошибке ПО и тестированием не решалась.

В тот же день агентство AP сообщило со ссылкой на Тома Гэвина, заместителя директора JPL по наукам о космосе и о Земле, что команда Lockheed Martin представила в JPL данные о тяге микродвигателей КА в фунтах силы, а в Пасадене эти числа были использованы как выраженные в ньютонах. По неофициальной версии Дж.МакДауэлла, речь шла об импульсе тяги при коррекции, который локхидовцы выразили в фунт-секундах, а джипиэлевцы восприняли как ньютон-секунды. Поскольку фунт силы в 4.45 раз больше ньютона, заложенная в дальнейшие расчеты величина импульса во столько же раз отличалась от необходимой.

C>Впрочем, у СССР был не менее facepalm'овый fail с неправильной командой Фобосу-1.
Ага, но тоже виноват не подход к тестированию, и думаю таких facepalm'овых fail'ов на околоземной орбите случалось немало.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, itslave, Вы писали:

I>История очень известная
I>http://www.osp.ru/os/1998/06/179592/
Да известная и является показательным примером ошибки при разработке ПО для ракетно-космической техники, но она не о "каше из метрических и дюймовых величин".

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, novitk, Вы писали:

V>>Значит, про остальные тоже ничего не знаешь.
N>Хамство не красит человека.

Инсинуации тоже.

V>>Эти инструменты используется как вспомогательные к "обычному программированию", резко увеличивая производительность для многих прикладных направлений.
N>Все это преминимо только для R&D, как и Excel. В коробку это нормальные люди не кладут.

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

V>>В общем, были бы текстовые файлы популярных языков программирования самодостаточные, можно было бы еще о чем-то говорить. А так, ввиду врожденной ограниченности текстового языка лишь синтаксисом конкретного языка, имеем что имеем — необходимость во внешней обслуживающей инфраструктуре.

N>Smalltalk и с песней. Файлов нет, все модели прямо в памяти, синтаксиса нет. Помогает, но не сильно.

Тем не менее, ОО взлетел и обкатался именно оттуда. Forth тоже был системой в себе и был одно время весьма популярен.

V>>Дракон можно рассматривать как попытку организации такой инфраструктуры.
N>Дракон пока можно вообще не рассматривать за отсутсвием в нем новых идей.

Я новых идей не видел еще ни разу за последние более 20-ти лет. Все нафталиновые, старые, тщательно выдаваемые за новые. Вот тут высказался: http://www.rsdn.ru/forum/philosophy/4247637.aspx
Идея графического представления конечно не нова — раньше-то ручками чертили и не парились. Но вот поиск удобной сценарии работы с графикой и текстом в процессе разработки — интересная задача. Дракон как раз пытается ввести некую экологию представления графики, чтобы получать от нее максимум отдачи.

Оказывается, на RSDN подробное сообщение о языке Дракон было сделано еще в 2008 году в форуме "Сборка программы из "кубиков" — мышью. Язык VPL и др"

Сообщение сделал специалист из РКК "Энергия".
http://wщение сделалww.rsdn.ru/forum/philosophy/3104871.1.aspx

Сообщение о Драконе сделал специалист из РКК "Энергия".
http://www.rsdn.ru/forum/philosophy/3104871.1.aspx

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>8. Таким образом, перед системой образования возникает принципи-
ВП>ально новая масштабная задача: организовать обучение алгоритми-
ВП>ческому мышлению для непрограммистов. То есть для подавляю-
ВП>щего большинства специалистов.[/b]
Угу. Очень полезная и масштабная задача. Для которой, по моему мнению, Дракон вполне подходит. Книги у вас для непрограммистов действительно весьма неплохие, и если б непрограммисты в результате получили бы хотя бы общее отдаленное представление о работе программистов, а также были бы способны самим набросать какой алгоритм — очень многие бы выиграли (как программисты, так и непрограммисты — хорошо было бы всем).
Но одно но — в случае преподнесения данного языка профессиональным программистам, критика будет огромной

. В том числе и с матами и оскорблениями

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Сообщение о Драконе сделал специалист из РКК "Энергия".
ВП>http://www.rsdn.ru/forum/philosophy/3104871.1.aspx
И как и ожидалось:

ДРАКОН начал частично применяться в программе МКС "Буран". И имел успех, но поскольку проект уже близился к заверщению ДРАКОН не являлся основным языком и использовался в основном "на бумаге", т.е. как язык описания алгоритмов во время общения специалистов между собой. Но работы по автоматизации графического языка велись. К сожалению программа МКС "Буран" была в одночасье закрыта. ДРАКОН переживал не лучшие времена, в целом на его разработку ушло 15 лет, но возник и на драконьей улице праздник.

Т.е. никакого кода на ДРАКОНе в Буране скорее всего и не было, а использовался он только для спецификаций.

Врать-то зачем надо было, что на ДРАКОНе работающий код писали?

FR>>Ну и спорным является и то что чтение обычного текста не является симультанным, те же практики скорочтения показывают и доказывают обратное

ВП>Вы правы. При чтении обычного текста используются оба механизма сукцессивный и симультанный.
ВП>Но! Степень симультанности РАЗНАЯ. При чтении эргономичной графики эта степень много выше.

Но при этом вы так и не привели ни одного примера рельного алгоритма на Драконе, о котором вас просили: AVL-деревья и т.п. Каша и дверные замки — это несерьезно.

Так что пока что все ваши заявления — банальная демагогия.

Здравствуйте, elmal, Вы писали:

E>Очень полезная и масштабная задача. Для которой, по моему мнению, Дракон вполне подходит. Книги у вас для непрограммистов действительно весьма неплохие, и если б непрограммисты в результате получили бы хотя бы общее отдаленное представление о работе программистов, а также были бы способны самим набросать какой алгоритм — очень многие бы выиграли (как программисты, так и непрограммисты — хорошо было бы всем).

К Вашим словам хочу сделать добавление

ЧТО ТАКОЕ МЕДИЦИНСКИЕ АЛГОРИТМЫ?

Это алгоритмы, которые далеко не всегда имеют отношение к компьютерам и программированию.

Medical algorithms are not necessarily implemented using digital computers. In fact, many of them can be represented on paper, in the form of diagrams, nomographs, etc.

http://en.wikipedia.org/wiki/Medical_algorithm

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

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

ЧЕМ ИНТЕРЕСНЫ МЕДИЦИНСКИЕ АЛГОРИТМЫ?

Тем, что они отвечают на насущную потребность практической медицины.

Я держу в руках «Практическое руководство для врачей общей (семейной) практики / Под редакцией академика РАМН И. Н. Денисова. – М.: ГЭОТАР-МЕД, 2001. – 720с.».

Для кого предназначен этот учебник?

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

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

1. алгоритм «Остро возникшая головная боль»,

2. алгоритм «Хроническая головная боль»,

3. алгоритм «Головокружение»,

4. алгоритм «Синкопальное состояние»,

5. алгоритм «Нарушение остроты зрения»,

6. алгоритм «Красный глаз»,

7. алгоритм «Боль в ухе»,

8. алгоритм «Боль в горле»,

9. алгоритм «Боль в груди»,

10. алгоритм «Боль в суставах»,

11. алгоритм «Острый кашель»,

12. алгоритм «Хронический кашель»,

13. алгоритм «Кровохарканье»,

14. алгоритм «Одышка»,

15. алгоритм «Дисфагия»

16. алгоритм «Тошнота и рвота»;

17. алгоритм «Увеличение живота»;

18. алгоритм «Запор»;

19. алгоритм «Острая диарея»;

20. и т. д.

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

По моему мнению, авторы учебников должны знать, что вместо блок-схем следует использовать язык ДРАКОН, который имеет неоспоримые преимущества.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>По моему мнению, авторы учебников должны знать, что вместо блок-схем следует использовать язык ДРАКОН, который имеет неоспоримые преимущества.
Я эти преимущества оспорил, так что они не неоспоримы.

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

> ВП>По моему мнению, авторы учебников должны знать, что вместо блок-схем следует использовать язык ДРАКОН, который имеет неоспоримые преимущества.
> Я эти преимущества оспорил, так что они не неоспоримы.
>
> Тут примеры реального кода будут или так и будет продолжаться логоррея, не имеющая отношения к программированию вообще?

Буга-га-га

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, elmal, Вы писали:

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

+1, но много "если". Очень может быть что в Драконе реально скрывается улучшенная нотация по описанию машин состояний. К сожалению терминологический велосипед и увлечение автора когнивистикой не помогают понять в чем собственно соль.

Здравствуйте, Cyberax, Вы писали:

C>Т.е. никакого кода на ДРАКОНе в Буране скорее всего и не было, а использовался он только для спецификаций.

Ну а если несколько строк таки было написано, что тогда?
Похоже, ты уже пошел на принцип...

C>Врать-то зачем надо было, что на ДРАКОНе работающий код писали?

Да кому нужен твой работающий код, сорри? Это я тебя как коллега коллегу спрашиваю. Любой работающий сегодня код — мусор. Т.к. рано или поздно все-равно дорабатывается вплоть до полной неузнаваемости. А вот спецификации и понимание предметной области — остаются. И то не всегда. ))

А код — это мусор, не надо на него так молиться. Тем более в реальных проектах более 100к строк. Мусор на 99%. Покажешь мне обратное — уложишь меня на обе лопатки. Дык, только не покажешь никогда, вот в чем прикол. Даже на этом сайте посмотреть в сниппетах коллег — сплошное брр... А уж любой опен сорс — это стыд нашей профессии.

Здравствуйте, vdimas, Вы писали:

C>>Т.е. никакого кода на ДРАКОНе в Буране скорее всего и не было, а использовался он только для спецификаций.
V>Ну а если несколько строк таки было написано, что тогда?
Вот если бы было написано хотя бы тысяч так 10 строк, то можно было бы реально смотреть стоит ли вообще ДРАКОН чего-нибудь.

А так у него только "неоспоримые преимущества".

V>Похоже, ты уже пошел на принцип...
Да.

C>>Врать-то зачем надо было, что на ДРАКОНе работающий код писали?
V>Да кому нужен твой работающий код, сорри? Это я тебя как коллега коллегу спрашиваю. Любой работающий сегодня код — мусор. Т.к. рано или поздно все-равно дорабатывается вплоть до полной неузнаваемости. А вот спецификации и понимание предметной области — остаются. И то не всегда. ))
Да, это вообще отмазка. Не надо код писать совсем — он мусор.

Вот пусть и идёт ДРАКОН туда где ему место — в мусорное ведро.

Здравствуйте, Cyberax, Вы писали:

C>Вот если бы было написано хотя бы тысяч так 10 строк, то можно было бы реально смотреть стоит ли вообще ДРАКОН чего-нибудь.
Вроде как Паронджанов утверждает, что в послебурановских проектах Дракон использовался, правда подробностями не делиться.

C>Вот пусть и идёт ДРАКОН туда где ему место — в мусорное ведро.
Если действительно используют зачем в мусорное ведро?
Конечно, попытки продвижения шире, например эта, выглядят... эээ. В общем лучше промолчу.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

C>>Вот если бы было написано хотя бы тысяч так 10 строк, то можно было бы реально смотреть стоит ли вообще ДРАКОН чего-нибудь.
P>Вроде как Паронджанов утверждает, что в послебурановских проектах Дракон использовался, правда подробностями не делиться.

Я в это не верю. Если бы реально что-то было, то не составило бы труда привести пример.

Возможно, оно использовалось в документации или ещё где, но очень вряд ли, что для работающего кода.

C>>Вот пусть и идёт ДРАКОН туда где ему место — в мусорное ведро.
P>Если действительно используют зачем в мусорное ведро?
P>Конечно, попытки продвижения шире, например эта, выглядят... эээ. В общем лучше промолчу.
Ну да, если бы его продвигали как более удобную нотацию для задания конечных автоматов или диаграмм переходов — ещё можно было бы что-то обсуждать.

Здравствуйте, vdimas, Вы писали:

V>Итеративность может быть процессом более высокого уровня. Но для каждого этапа разработки, т.е. для каждой итерации, схема может быть именно такой — однонаправленной. Сравни с RUP.
Понятно, схема упрощенная и делалась скорее всего для демонстрации "начальникам", но нам интересны подробности.

V>Наоборот, к этому во многих отраслях и идет. И чем больше IT будет покрывать областей знаний, тем больше будет идти разделение на специалиста-прикладника и программиста. Ты прав только касательно небольших проектов, которые выполняются маленьким кол-вом разработчиков — порядка 5+-, где о выделенном аналитике не может быть и речи.

Это так, и графические инструменты используются, но это одно, другое — попытка заменить с помощью этих инструментов программистов специалистами-прикладниками.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

P>Это так, и графические инструменты используются, но это одно, другое — попытка заменить с помощью этих инструментов программистов специалистами-прикладниками.

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

Здравствуйте, vdimas, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

V>>В показанной схемы я не увидел замены. Я увидел попытку наладить их взаимодействие через обучение прикладных специалистов (не программистов) специально разработанному формальному языку алгоритмов.
P>Очень даже может быть, но ТС утверждает, что это рабочий инструмент написания программ.

Вы правы. Подтверждаю, что это рабочий инструмент написания программ.

Предлагаю Вашему вниманию Извлечение из Вводного раздела документа "Язык ФЛОКС. Руководство алгоритмиста".
Читать не с начала, а со стр. 28 "Технология Графит-Флокс".
http://drakon.su/_media/biblioteka/grafitfloks.pdf

ВП>Вы правы. Подтверждаю, что это рабочий инструмент написания программ.

ВП>Предлагаю Вашему вниманию Извлечение из Вводного раздела документа "Язык ФЛОКС. Руководство алгоритмиста".
ВП>Читать не с начала, а со стр. 28 "Технология Графит-Флокс".
ВП>http://drakon.su/_media/biblioteka/grafitfloks.pdf

Демагогия на 50 страницах.

То есть вы говорите:

"Это неправильные пчелы.
И у них неправильный мед".

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>То есть вы говорите:

ВП>

ВП>"Это неправильные пчелы.
ВП>И у них неправильный мед".

Нет, я называю демагогию демагогией. В этом своем ответе вы продолжаете заниматься демагогией.

Здравствуйте, Mamut, Вы писали:

M> я называю демагогию демагогией. В этом своем ответе вы продолжаете заниматься демагогией.

Уважаемый Дмитрий!

Вы, по-видимому, не полностью прочитали топик. Поэтому специально для Вас я повторяю:

ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

Язык ДРАКОН успешно используется во многих космических программах:

• разгонный блок космических аппаратов ДМ-SL (проект «Морской старт»);

• разгонный блок космических аппаратов «Фрегат» (включая Фрегат-СБ, Фрегат-МТ, Фрегат с модернизированной системой управления);

• модернизированная ракета-носитель тяжелого класса «Протон-М»;

• разгонный блок космических аппаратов ДМ-SL-Б (проект «Наземный старт»);

• разгонный блок космических аппаратов ДМ-03;

• первая ступень для южнокорейской ракеты-носителя легкого класса KSLV-1 (Korean Space Launch Vehicle);

• ракета-носитель легкого класса Ангара 1,2;

• ракета-носитель тяжелого класса Ангара-А5;

• разгонный блок космических аппаратов КВТК (кислородно-водородный тяжелого класса) и др.

Космодромы:

Плавучий космодром, производящий пуски с экватора в Тихом океане (экваториальная зона вблизи острова Рождества Республики Кирибати (с координатами 154 градуса западной долготы и 0 градусов широты)),

Байконур,

Плесецк,

Европейский космический центр во Французской Гвиане "Kuru" (Южная Америка),

Южнокорейский космодром "Naro".

__________________________________________________

Скажите, Дмитрий, Вы действительно считаете, что с помощью демагогии можно запускать ракеты?

И еще. Я работаю в Роскосмосе с 1961 года. Участвовал в разработке Бурана с первого дня и до закрытия проекта. В то время я был Начальником лаборатории комплексной разработки вычислительной системы Бурана.

> И еще. Я работаю в Роскосмосе с 1961 года. Участвовал в разработке Бурана с первого дня и до закрытия проекта. В то время я был Начальником лаборатории комплексной разработки вычислительной системы Бурана.

Это плохо. Какой вы специалист видно. И по вашим методам примерно понятно каким вы были администратором. Соавторство, приписки, нечестные методы и все такое.

Posted via RSDN NNTP Server 2.1 beta

M>> я называю демагогию демагогией. В этом своем ответе вы продолжаете заниматься демагогией.

ВП>Уважаемый Дмитрий!

ВП>Вы, по-видимому, не полностью прочитали топик. Поэтому специально для Вас я повторяю:

Демагогия скипнута

ВП>Скажите, Дмитрий, Вы действительно считаете, что с помощью демагогии можно запускать ракеты?

Нет, ракеты демагогией не запускаются. Но это не имеет отношение к тому, что вы тут пишете

ВП>И еще. Я работаю в Роскосмосе с 1961 года. Участвовал в разработке Бурана с первого дня и до закрытия проекта. В то время я был Начальником лаборатории комплексной разработки вычислительной системы Бурана.

И при этом как только вам задают конкретные вопросы, вы тут же скрываетесь в кусты. А вопросы были заданы, и не раз:

http://rsdn.ru/forum/philosophy/4755616.aspx
Автор: Cyberax
Дата: 28.05.12

Пример сложного алгоритма в студию, хотя бы аналог 10000 строк кода.

http://rsdn.ru/forum/philosophy/4752672.aspx
Автор: Cyberax
Дата: 25.05.12

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

http://rsdn.ru/forum/philosophy/4751597.aspx
Автор: TimurSPB
Дата: 24.05.12

ВП>Я ввел понятие "эргономичный алгоритм". Это принципиально новое фундаментальное научное понятие.
Как выглядит эргономичная быстрая сортировка?

http://rsdn.ru/forum/philosophy/4756213.aspx
Автор: elmal
Дата: 28.05.12

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

http://rsdn.ru/forum/philosophy/4760076.aspx
Автор: elmal
Дата: 31.05.12

Так вот — а как поставлено тестирование? Как проверяется корректность работы алгоритма в целом и отдельных мелких частей в частности? Это крайне важно в этой предметной области, здесь нужно многократно все проверять и перепроверять! Неужели просто методом пристального взгляда? Если нет, то как пишут тесты и тестируют — тоже на Драконе?

Ну и про ракеты

http://rsdn.ru/forum/philosophy/4753807.aspx
Автор: elmal
Дата: 26.05.12

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

И завершу:

http://rsdn.ru/forum/philosophy/4763462.aspx
Автор: Cyberax
Дата: 03.06.12

ВП>По моему мнению, авторы учебников должны знать, что вместо блок-схем следует использовать язык ДРАКОН, который имеет неоспоримые преимущества.

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

Здравствуйте, vdimas, Вы писали:

V>На нем Буран сделали и он полетел.

Особенно это смешно выглядит под статьи о PL1-компилятор от парня из РККА Энергия (или вроде того).

Здравствуйте, vdimas, Вы писали:

C>>Никаких независимых подтверждений его слов нет.

V>Пол-но и уже относительно давно.

Дык, а где ссылка хотя бы на дину?

Здравствуйте, Mr.Cat, Вы писали:

MC>Не про дракон, но там, где я видел квадратики (workflow foundation, bpel), оно (весьма условно) работало так. Схема — экземпляр некоего класса, у него есть набор входных свойств (заполняется при вызове схемы), выходных свойств (нужно заполнить перед выходом) и просто свойств, которые хранят какое-то промежуточное состояние. Время жизни экземпляра — по инстансу на вызов. Квадратики в целом двух видов.
MC>- Методы класса. То есть при входе в квадрат просто выполняется код с полным доступом к свойствам схемы. Сюда же, пожалуй, можно отнести всякие циклы и ветвления, которые работают со свойствами схемы.
MC>- Инстансы других классов (другие схемы, точки входа в какое-то внешнее АПИ и т.п.). Перед входом в такой квадрат ты должен заполнить его входные свойства, после выхода можно работать с выходными.

MC>Думается, что в драконе сделано что-то подобное.

А как с рекурсией и стеком? Выражать рекурсию через циклы с внешними стеками? Убиться об стену в некоторых случаях.

А сами стеки как выглядят?

И вообще, как визуализировать мало-мальски пухлые данные? Они ведь в блок-схемы никак не вписываются.

Здравствуйте, LaptevVV, Вы писали:

LVV>За этим вам лучше сходить на oberoncore.ru

Как бы Оберон — это скорее антиреклама для проекта. Как и 25 лет безуспешного развития (если можно это назвать развитием) языка.

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

Здравствуйте, LaptevVV, Вы писали:

LVV>1. Мы проводили опрос среди студентов 1-2-3 курсов по вопросу, что они легче воспринимают при объяснении алгоритмов: псевдокод или блок-схемы? Ответы свидеетельствовали, что девочки практически поголовно лучше воспринимают картинку. Мальчики в основном псевдокод, но попадались и такие, которым было пофигу. Среди девочек ни одной пофигу не было.

И сколько девочек программистами стали? А сколько хорошими?

А потом никто не спорит, что на ранних стадиях блок-схемы не плохой подход представления алгоритмов. Но, блин, не для реальной же работы?

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

Здравствуйте, vdimas, Вы писали:

V>Будет ошибкой сравнивать неполноценный UML, с полноценным языком. Тут высказался.

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

ЗЫ

Собственно про ФВП ответа так и не последовал. А было бы интересно.

Ну, а если еще и паттерн-матчинг сбацать можно, так вообще слов нет.

Здравствуйте, a_g_99, Вы писали:

__>А вот в штатах бедолаги не знают и все на UML рисуют. И инструментов там — тьма тьмущая. И все довольны.

А вот это не аргумент. В штатах много ереси в мозг бедных студентов вбивают. Не странно, что они программистов пароходами импортируют.

Здравствуйте, LaptevVV, Вы писали:

LVV>Я думаю, Владими Даниэлович сам может рассказать, в каком месте использовался Дракон.

Дык где же он? Просим, просим!

Здравствуйте, Nikkk2010, Вы писали:

N>Язык ДРАКОН — новая идея в программировании.
N>Обращайтесь в администрацию проекта Сколково.
N>Ужу выделены сотни миллионов американских долларов
N>в рамках этого проекта.

Кончай стебаться. Не КУ все таки.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Даю выдержку из книги 2012 года:...

А что с обобщением? Аналоги дженериков/шаблонов/параметров типов есть?

Что с ФВП есть? Ну, можно одну блок-схему передать другой в качестве параметра для обработки некой структуры данных.

И что вообще со структурами данных?

Аналоги виртуальных функций есть?

В общем, как сделать так чтобы не писать много похожего "кода"?

Здравствуйте, Cyberax, Вы писали:

C>Т.е. я совсем не против методологии, где инжинеры описывают формальные требования, по которым потом создаётся код. Но для этого надо иметь соответствующие инструменты. И самый главный из них — старый добрый текст. Диаграммы имеют смысл, но только для:
C>1) Иллюстрации общей структуры (т.е. иерархические диаграммы).
C>2) Диаграммы для КА (в различных формах).

Скажу больше. Для каждой прикладной области диаграмы будут свои. Для описания языков — это будут аналоги БНФ. А что за диаграмму можно использовать для описания уровня в 3D-игре я вообще понять не могу. Тут лучше сам уровень и показывать.

Здравствуйте, vdimas, Вы писали:

V>А вообще, использование формального языка для постановки задачи — это на самом деле 5 баллов! Вы просто малость не в ту сторону смотрите и не то желаете там увидеть.

Ага. Только языки эти не могут быть одним языком. Они разные. Как на драконе парсер описать? А как 3d-объект?

Здравствуйте, vdimas, Вы писали:

V>По твоей ссылке предметной областью являлся компилятор с DSL. Разработка такого компилятора — вполне себе автоматная задача.

ОК. Покажи реализацию на драконе хотя бы одного компилятора или интерпетатора ДСЛ.

Здравствуйте, minorlogic, Вы писали:

M>«Если вы не можете своему ребенку за пять минут объяснить, чем вы занимаетесь, значит, вы занимаетесь какой-то ерундой».

Я своему не могу. Правда он еще разговаривать не умет.

Здравствуйте, TimurSPB, Вы писали:

TSP>

TSP>ИМХО, так эргономичнее.

Это уже графический оверхэд.

Здравствуйте, VladD2, Вы писали:

VD>А как с рекурсией и стеком? Выражать рекурсию через циклы с внешними стеками? Убиться об стену в некоторых случаях.
В wwf с рекурсией вроде фигово, так что да, циклы. В том немногом, что я видел из bpel — возможна как минимум косвенная рекурсия (может, и прямая, не пробовал), т.к. процесс (грубо говоря — блок-схема) может вызвать другой процесс.

VD>А сами стеки как выглядят?
В wwf для девелопера, в конечном счете, блок-схема (кажется, "шаблон процесса" по-тамошнем) — обычный класс, так что состояние блок схемы теоретически может включать произвольные сериализуемые поля. В bpel состояние инстанса блок-схемы (процесса) — это практически xml-документ.

VD>И вообще, как визуализировать мало-мальски пухлые данные? Они ведь в блок-схемы никак не вписываются.

Не совсем понимаю, что ты имеешь в виду, но скорее всего ответ — никак. На то они и блок-схемы, чтобы описывать алгоритм, а не данные.

Здравствуйте, Mr.Cat, Вы писали:

VD>>как визуализировать мало-мальски пухлые данные? Они ведь в блок-схемы никак не вписываются.

MC>Не совсем понимаю, что ты имеешь в виду, но скорее всего ответ — никак. На то они и блок-схемы, чтобы описывать алгоритм, а не данные.

Уважаемый Mr.Cat!

Вы совершенно правы. В дракон-схемах (в блок-схемах) пишут только алгоритм. И, возможно, простые ("непухлые") данные.

VD тоже совершенно прав. Он ставит законный вопрос: "как визуализировать мало-мальски пухлые данные?"

Ответ такой: http://drakon.su/_media/biblioteka/grafit_a4.pdf

1. "Пухлые" данные пишут не в блок-схеме, а в другом месте.

2. Данные не обязательно визуализировать.

В технологии Графит-Флокс само название отражает два понятия:

графит — это алгоритм (блок-схема),
флокс — это данные, заданные в форме таблиц (флокс-таблиц).

Все данные (очень "пухлые") помещаются в базу данных ФЛОКС.

Блок-схемы (графит-алгоритмы) вводятся в ПК через графит-редактор.

Данные (флокс-описания) вводятся в ПК через флокс-редактор.

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

Я говорю о том, как работает Технология разработки алгоритмов и программ Графит-Флокс во ФГУП "НПЦАП"
http://drakon.su/_media/biblioteka/grafit_a4.pdf

Здравствуйте, VladD2, Вы писали:

LVV>>Я думаю, Владимир Данилович сам может рассказать, в каком месте использовался Дракон.

VD>Дык где же он? Просим, просим!

Уважаемый VladD2!

На этом форуме я уже два раза отвечал на этот вопрос.
Из уважения к администратору повторю ответ еще раз:

ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

Язык ДРАКОН успешно используется во многих космических программах:

• разгонный блок космических аппаратов ДМ-SL (проект «Морской старт»);

• разгонный блок космических аппаратов «Фрегат» (включая Фрегат-СБ, Фрегат-МТ, Фрегат с модернизированной системой управления);

• модернизированная ракета-носитель тяжелого класса «Протон-М»;

• разгонный блок космических аппаратов ДМ-SL-Б (проект «Наземный старт»);

• разгонный блок космических аппаратов ДМ-03;

• первая ступень для южнокорейской ракеты-носителя легкого класса KSLV-1 (Korean Space Launch Vehicle);

• ракета-носитель легкого класса Ангара 1,2;

• ракета-носитель тяжелого класса Ангара-А5;

• разгонный блок космических аппаратов КВТК (кислородно-водородный тяжелого класса) и др.

Космодромы:

Плавучий космодром, производящий пуски с экватора в Тихом океане (экваториальная зона вблизи острова Рождества Республики Кирибати (с координатами 154 градуса западной долготы и 0 градусов широты)),

Байконур,

Плесецк,

Европейский космический центр во Французской Гвиане "Kuru" (Южная Америка),

Южнокорейский космодром "Naro".

__________________________________________________

Скажу о себе. Я работаю в Роскосмосе с 1961 года. Участвовал в разработке Бурана с первого до последнего дня.
В тот период (1976 — 1992) я был Начальником лаборатории комплексной разработки вычислительной системы Бурана.

Дракон родился в процессе работы на Бураном. Это совместная разработка ФГУП Научно-производственный центр автоматики и приборостроения им. акад. Н.А. Пилюгина и Института прикладной математики им. акад. М.В. Келдыша РАН.

Технология Графит-Флокс (основанная на языке Дракон) разрабатывалась, начиная с 1986 года и была доведена до рабочего состояния в 1996 году. Данная технология эксплуатируется уже 16 лет (1996 — 2012).

Данная технология использовалась во всех перечисленных выше ракетно-космических проектах.

Я написал около десятка книг на эту тему, которые можно скачать в сети или купить в магазинах.
Вот, например, последняя книга (2012 год), которая есть в продаже и в бумажном, и в цифровом виде:
http://www.dmk-press.ru/catalog/computer/programming/?p=1

Через интернет с этой литературой познакомились не знакомые со мной специалисты, которые по своей инициативе создали (пока еще экспериментальные) инструментальные средства.

Некоторые пользователи (пока еще немногочисленные) используют эти средства в своей практической работе. Они сообщают о значительном повышении производительности труда при создании алгоритмов и программ. Положительные отзывы поступают из России, Германии, Норвегии.

Информация на эту тему обсуждается на Форумах сайта "Визуальный язык ДРАКОН" с 2008 года.
http://forum.oberoncore.ru/viewforum.php?f=77

На форумах сайта "Визуальный язык ДРАКОН" свыше 300 тем, 7500 ответов.

По языку ДРАКОН и инструментальным средствам (например, ИС Дракон) имеются и другие форумы и сайты.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Язык ДРАКОН успешно используется во многих космических программах:
Нескромный вопрос, на ракетах которые упали недавно пару раз, ваш софт стоит ? ))

ВП>Космодромы:
ВП>Плавучий космодром, производящий пуски с экватора в Тихом океане (экваториальная зона вблизи острова Рождества Республики Кирибати (с координатами 154 градуса западной долготы и 0 градусов широты)),
ВП>Байконур, ВП>Плесецк, ВП>Европейский космический центр во Французской Гвиане "Kuru" (Южная Америка),
ВП>Южнокорейский космодром "Naro".
То есть, если , не дай бог, жизнь заставит писать софт для ракет, то от осваивания дракона не отвертеться.
Хорошо хоть не модно щас деньги сжигать такими объемами, как раньше, во времена гонки вооружений.
Вон в США, НАСА от краника бюджета отвадили, несмотря на их чистосердечные уверения, что наука загнется без них.
Ан нет, коммерсанты за сумму в 10 раз меньше на орбиту взлетели.

ВП>Дракон родился в процессе работы на Бураном. Это совместная разработка ФГУП Научно-производственный центр автоматики и приборостроения им. акад. Н.А. Пилюгина и Института прикладной математики им. акад. М.В. Келдыша РАН.
И, очевидно, отсюда принцип "шашлыка" — что бы не происходило, носитель куда то попадет, на орбиту ли, в море ли.
Тяжесть то на железки всегда действует. Понятно что для системы в которой больше миллиона деталей, которая состоит
из кучи модулей с выходом на физические рецепторы/эффекторы, нужно дать инженерам возможность порулить.
А они привыкли то к blueprint-ам, и без черчения и рисования никак.

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

Это ж ЮМЛ, квадратики и стрелочки. Ну генерит он код. Так весь жизненный цикл разработки софта намного больше.
И не зря блок-схемы учат на первом этапе изучения информатики.
Потом абстрактная модель алгоритма уже генерируется в мозгу программиста на лету, и отображается в код исполнителя автоматом.
И большого смысла в трате времени на рисование постоянно изменяющуюся модель реализации не будет.
Как вы думаете, почему за 20 лет, после ооп, так ничего толкового и не придумали ?
Толкового в смысле, переложить труд в поиске алгоритмов и генерации по алгоритму для конкретного процессора — исполняемого кода,
с программиста, который человек, тоже ошибается, и объять предметную область проблемы спроектировав ее на область исполнителя,
не в состоянии.

ВП>Некоторые пользователи (пока еще немногочисленные) используют эти средства в своей практической работе. Они сообщают о значительном повышении производительности труда при создании алгоритмов и программ. Положительные отзывы поступают из России, Германии, Норвегии.
)) С ностальгией вспоминаю сообщения в новостях страны которую развалили...

ВП>По языку ДРАКОН и инструментальным средствам (например, ИС Дракон) имеются и другие форумы и сайты.
Ага, посмотрел, интересно, редактор блок схем. Да еще и код генерит, только вот схема удаления файлов больше 100кб в поддиректориях,
где в квадратиках код паскаля, смотрится анахронизмом. Вот схема высшего уровня где русскими словами — так еще ничего, красиво.

Здравствуйте, VladD2, Вы писали:

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

Уважаемый Владислав Юрьевич!

Вы правы. Блок-схемы — это плохо.
Но дракон-схемы — это не блок-схемы.

Смешивать их недопустимо. Иначе получается так:

"Ругали абрикос за толстокожесть апельсина, только потому что оба фрукты"

ДРАКОН (в отличие от блок-схем) позволяет рисовать СКОЛЬ УГОДНО сложные алгоритмы.

Более того, Чем сложнее алгоритм, тем больше выгода от использования ДРАКОНа.

ВП>ДРАКОН (в отличие от блок-схем) позволяет рисовать СКОЛЬ УГОДНО сложные алгоритмы.

ВП>Более того, Чем сложнее алгоритм, тем больше выгода от использования ДРАКОНа.
я не понял, дракон — это только средство одного из видов визуализации алгоритмов? это язык? есть ли у него рефлексия?

Здравствуйте, BrainSlug, Вы писали:

BS>я не понял, дракон — это только средство одного из видов визуализации алгоритмов? это язык?

Да, это язык. Более того, это не один язык, а семейство языков.

Каждый язык Дракон-семейства имеет не один синтаксис, а два:

1. графический синтаксис
2. текстовый синтаксис.

Язык принадлежит дракон-семейству, если он имеет стандартный графический синтаксис.

Все языки дракон-семейства имеют ОДИН И ТОТ ЖЕ ГРАФИЧЕСКИЙ синтаксис.

А текстовый синтаксис может быть любой. Вы можете придумать Ваш собственный текстовый синтаксис.

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

Я об этом уже рассказывал на этом форуме.

Если хотите, можно посмотреть Википедию:
http://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D_(%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA)#.D0.93.D1.80.D0.B0.D1.84.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.B9_.D0.B8_.D1.82.D0.B5.D0.BA.D1.81.D1.82.D0.BE.D0.B2.D1.8B.D0.B9_.D1.81.D0.B8.D0.BD.D1.82.D0.B0.D0.BA.D1.81.D0.B8.D1.81_.D1.8F.D0.B7.D1.8B.D0.BA.D0.B0_.D0.94.D0.A0.D0.90.D0.9A.D0.9E.D0.9D

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ
ВП>Язык ДРАКОН успешно используется во многих космических программах:
Это враньё. Приведи пример нетривиального кода на ДРАКОНе — ты этого сделать банально не можешь, так как такого кода не существует.

Я уж не говорю, что ДРАКОН — это каменный век по нынешним временам. Поделка для быдлоакадемиков советской школы. Прогрессивный мир нынче смотрит на: метапрограммирование, зависимые типы, typesets, proof-carrying code. Крайне интересны исследования в области total functional programming.

К примеру, от НАСА: http://babelfish.arc.nasa.gov/trac/jpf — система для постройки формально верифицируемых программ. Причём они не языком треплют про "неоспоримые преимущества", а пишут код.

Здравствуйте, VladD2, Вы писали:

VD>Это же об стену убиться, если мало-мальски серьезный алгоритм придется читать в блок-схемах!

Уважаемый Владислав Юрьевич!

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

Иное дело ДРАКОН. Это принципиально новая нотация. Она позволит Вам быстро и удобно изобразить не только "мало-мальски серьезный алгоритм", но и алгоритмы ЛЮБОЙ СЛОЖНОСТИ.

Если Ваш алгоритм (согласно Вашему замыслу) должен быть ПОНЯТНЫМ и УДОБОЧИТАЕМЫМ, то у ДРАКОНа просто нет конкурентов.

Никакая другая нотация не даст Вам такой ПОНЯТНОСТИ алгоритмов, как ДРАКОН.

Для этой цели разработаны специальные методы, в том числе математические.

http://drakon.su/_media/biblioteka/drakondescription.pdf

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Для этой цели разработаны специальные методы, в том числе математические.
ВП>http://drakon.su/_media/biblioteka/drakondescription.pdf
Гааа.... Я посмотрел раздел "Операторы реального времени", наивно ожидая увидеть как визуализутся гарантии реального времени или приоритеты.

Забаньте этого клоуна уже, что ли?

Здравствуйте, Cyberax, Вы писали:

ВП>>Язык ДРАКОН успешно используется во многих космических программах:
C>Это враньё. Приведи пример нетривиального кода на ДРАКОНе — ты этого сделать банально не можешь, так как такого кода не существует.

Вот же он ссылку дал.

ДРАКОН — графический (визуальный) язык, в котором используются два типа элементов:

графические фигуры (иконы),

текстовые надписи, расположенные внутри или снаружи икон (текстоэлементы).

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

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

Здравствуйте, artelk, Вы писали:

A>Вся нетривиальщина вписывается в эти "текстоэлементы" и инлайнится (или вызывается в качестве попдрограммы) по месту при трансляции в низлежащий язык.

Ну дык. Вот пример нетривиального кода на ДРАКОНе:

=====================|
|           Ядро ОС                |
|                                         |
| [код linux-3.2.0 skipped]    |
|=====================

Здравствуйте, VladD2, Вы писали:

VD>Кончай стебаться. Не КУ все таки.

А надо бы. Не в КУ, так в КСВ, чтобы все заценили.

Здравствуйте, BrainSlug, Вы писали:

BS>в таком случае какой же это язык? это способ представления, особый редактор если угодно, кода или псевдокода, или что там у него

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

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

PS Имхо, в качестве серебряной пули не прокатит, даже близко.

> BS>в таком случае какой же это язык? это способ представления, особый редактор если угодно, кода или псевдокода, или что там у него
>
> Да нет, все же язык, причем Тьюринг-полный — есть условия, циклы и т.п. Кроме того, есть такие вещи как распараллеливание.
> На сколько я понял, создание так называемого языка Дракон-гибрида делается так: выбирается некий низлежащий язык (например, С++), для каждой примитивной "иконы" Дракона находится соответствие в низлежащем языке (условный переход, цикл и т.д.). Для них делается тупой транслятор в этот низлежащий язык.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>в таком виде, это не трансляция, а прямое отображение
Прямое отображение — частный случай трансляции.
G>причем не формализованное.
Будет формализованное, когда напишешь транслятор. В стандарте С++, например, не указано в какие машинные инструкции что компилировать.

G>Соответственно тут Дракон не язык, язык это низлежащий язык.
И то и другое — языки.
G>А с учетом того, что отображение каждый раз писать нужно заново
Заново под каждый низлежащий язык. Компиляторы тоже пишут под каждую платформу свой (и не один).
G>, это даже не инструмент, не словарь и не средство визуализации. Это просто формальные соглашения по рисованию.
Которые образуют язык.
G>Что сделало бы дракон языком?
Синтаксис (тут графическая нотация плюс правила использования) и семантика (иконка Выбор означает то-то, и т.п.)

Не стоит приписывать Дракону недостатки — у него и так их хватает

Здравствуйте, lseder, Вы писали:

В этом офтопике ненадолго попробую заменить Паронджанова.

L>Нескромный вопрос, на ракетах которые упали недавно пару раз, ваш софт стоит ? ))
Нет не их. И во всех неудачах только одна — с ФГ, имеет вероятность быть софтовой.

L>То есть, если , не дай бог, жизнь заставит писать софт для ракет, то от осваивания дракона не отвертеться.
С Драконом балутся только одна организация.

L>Вон в США, НАСА от краника бюджета отвадили, несмотря на их чистосердечные уверения, что наука загнется без них.
Да ну?

L>Ан нет, коммерсанты за сумму в 10 раз меньше на орбиту взлетели.
Только финансирует этих "коммерсантов" американское правительство через бюджет НАСА. Сумма действительно в несколько раз меньше, чем у Боинга и Локхида (НАСА во всех трех случаях лишь заказчик), но никак не меньше российских расценок.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

ВП>Иное дело ДРАКОН. Это принципиально новая нотация. Она позволит Вам быстро и удобно изобразить не только "мало-мальски серьезный алгоритм", но и алгоритмы ЛЮБОЙ СЛОЖНОСТИ.

Доказательство этого мы когда-нибудь увидим? Или ответ хоть на один из вопросов тут: http://rsdn.ru/forum/philosophy/4775173.1.aspx

Сдается мне, вопрос риторический

Уважаемые коллеги!

Познакомьтесь со Stepan Mitkin.

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

DRAKON Editor is a free cross-platform editor for the DRAKON visual language.

DRAKON language was developed within the Russian space program. Its primary objective is presenting complex software systems in a way which is easy to understand by humans.

DRAKON's motto: took a glance — understood at once.

This tool is aimed at software architects, developers and quality specialists.

Features

•Simple user interface optimized for editing DRAKON diagrams.

•Export to PDF and PNG.

•Verification of diagrams.

•Code generation for Java, C#, C/C++ (with Qt support), Python, Tcl, Javascript and Erlang.

Подробнее см. здесь:
http://drakon-editor.sourceforge.net/

Еще один фрагмент:

Code generation in DRAKON Editor

Home | Download

DRAKON Editor generates source code from diagrams for a number of programming languages. As of version 1.11, the following languages are supported: C, C++, Java, C#, Python, Tcl, Javascript and Erlang. Since these languages have a lot in common, most of the generation is done by the same algorithm. The language-specific routines mostly take care of the differences in syntax.

Code generation has four steps:

•Build the graph of the algorithm from the items on the diagram.

•Process the graph.

•Generate the tree for the output source file.

•Print the tree using the syntax of the selected programming language.

Подробнее см.:
http://drakon-editor.sourceforge.net/generation.html

Это ваш ответ на сообщение Mamut-а

Доказательство этого мы когда-нибудь увидим? Или ответ хоть на один из вопросов тут: http://rsdn.ru/forum/philosophy/4775173.1.aspx
Автор: Mamut
Дата: 12.06.12

Сдается мне, вопрос риторический

?

у меня когнитивный диссонанс...о боже...это вопрос-а это ответ? а я Никита, любимый камень малохит

ВП>Это наш, русский человек. Живет и работает в Норвегии.
ВП>Его тексты предназначены для англоязычной аудитории.
ВП>Вот часть материалов с его сайта:

Каким образом это является ответом на вопрос

ВП>Иное дело ДРАКОН. Это принципиально новая нотация. Она позволит Вам быстро и удобно изобразить не только "мало-мальски серьезный алгоритм", но и алгоритмы ЛЮБОЙ СЛОЖНОСТИ.

Доказательство этого мы когда-нибудь увидим? Или ответ хоть на один из вопросов тут: http://rsdn.ru/forum/philosophy/4775173.1.aspx
Автор: Mamut
Дата: 12.06.12

Вот по этой ссылке: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184&start=40

5 страниц (!) обсуждения того, что делать с простейшим алгоритмом. Он, видите ли, не укладывается в схему. Самый сок с примерами — на второй странице. Например: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184&start=20#p60536

Ну и дальше тоже хорошо: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184&start=40#p61677

Гуру Паронджанов появился там только один раз с очередными циататами из замшелых книг.

А так я взял на себя смелость продублировать это сообщение тут: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3992

> Каким образом это является ответом на вопрос

Количество переходит в качество.

Posted via RSDN NNTP Server 2.1 beta

Уважаемые коллеги!

Мы видели, что дракон-редактор Степана Митькина поддерживает следующие языки:
C, C++, Java, C#, Python, Tcl, Javascript and Erlang.

В моих терминах это называется так:

Гибридный язык Дракон-С

Гибридный язык Дракон-С++

Гибридный язык Дракон-Java

Гибридный язык Дракон-С#

Гибридный язык Дракон-Python

Гибридный язык Дракон-Tcl

Гибридный язык Дракон-Javascript

Гибридный язык Дракон-Erlang

Я вовсе не настаиваю на этих терминах. Просто я не смог придумать ничего более подходящего.

Я исходил из простой мысли: надо же эту "штуковину" как-нибудь назвать. Так появился термин "гибридный язык".

Точнее говоря, гибридный язык Дракон-Х, где вместо Х надо подставить что-нибудь подходящее.

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

Но не только. Язык Дракон, созданный во ФГУП "НПЦАП" (Графит-Флокс) НЕ является гибридным языком. Это самостоятельный (не гибридный) язык.

ВП>Мы видели, что дракон-редактор Степана Митькина поддерживает следующие языки:
ВП>C, C++, Java, C#, Python, Tcl, Javascript and Erlang.

ВП>В моих терминах это называется так:

Эй, бот. Хватит чушь генерить, и ответь на прямо поставленные вопросы.

Здравствуйте, Mamut, Вы писали:

M>5 страниц (!) обсуждения того, что делать с простейшим алгоритмом. Он, видите ли, не укладывается в схему. Самый сок с примерами — на второй странице. Например: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184&start=20#p60536
Блин, да всю эту секту оберннутых и драконнутых нужно немедленно лишить всех академических званий и держать на пушечном выстреле от образовательных учреждений.

Здравствуйте, pagid, Вы писали:

L>>То есть, если , не дай бог, жизнь заставит писать софт для ракет, то от осваивания дракона не отвертеться.
P>С Драконом балутся только одна организация.
Если точнее, с ним никто не балуется. Это никчёмная поделка быдлоакадемиков из самых замшелых НИИ в худших традициях совка. Никаких сомнений в этом уже не осталось.

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

L>>Ан нет, коммерсанты за сумму в 10 раз меньше на орбиту взлетели.
P>Только финансирует этих "коммерсантов" американское правительство через бюджет НАСА.
Не финансирует, совсем. В частности, вся разработка велась на частные деньги, что является по-настоящему уникальным. SpaceX даже космодром свой будут строить.

НАСА просто купили запуски на готовых ракетах. Кстати, первый коммерческий запуск SpaceX со спутниками Интелсата будет в следующем году.

P>Сумма действительно в несколько раз меньше, чем у Боинга и Локхида (НАСА во всех трех случаях лишь заказчик), но никак не меньше российских расценок.
В теории, примерно такая же.

КАК ОЦЕНИВАЮТ ЯЗЫК ДРАКОН В АНГЛИИ?

По мнению Charles RB, это одно из важных достижений Роскосмоса.

http://forums.comicbookresources.com/showthread.php?317650-Obamas-trip-to-NASA&s=faed9e8d337b448f171f4d4226c216a0&p=10978923&viewfull=1#post10978923

Originally Posted by FalconX2000

What about Russia's space agency/program?
What can they boast about inventing?

На вопрос отвечает Charles RB Elder Member, Location: United Kingdom

The intercontinental ballistic missile, the satellite,
telemetry to/from space, knowledge of the moon
(including samples) and Mars and Venus,
the space station, robot space rovers,
and the programming language DRAKON.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>КАК ОЦЕНИВАЮТ ЯЗЫК ДРАКОН В АНГЛИИ?
ВП>По мнению Charles RB, это одно из важных достижений Роскосмоса.
ВП>http://forums.comicbookresources.com/showthread.php?317650-Obamas-trip-to-NASA&s=faed9e8d337b448f171f4d4226c216a0&p=10978923&viewfull=1#post10978923
В задницу мнения Charles RB. Он не программист.

Покажи нетривиальный работающий код, клоун.

Здравствуйте, Cyberax, Вы писали:

C>Покажи нетривиальный работающий код, клоун.

Да забей уже. Троллит он.

Здравствуйте, Ops, Вы писали:

Ops>Да забей уже. Троллит он.

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

M>А так я взял на себя смелость продублировать это сообщение тут: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3992

Тут: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3992&p=73120#p73110 и тут: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3992&p=73120#p73113. Все остальное можно не читать.

Что примечательно — не от Паронджанова и не от другого такого же клоуна под ником TAU, а от человека, который явно применяет это на практике.

Цитирую:

Если я скажу, что ниша эффективного применения ДРАКОН-схем, как минимум, перекрывается с нишей программирования на основе конечных автоматов, это разрешит какие-то из Ваших вопросов?

Из личных примеров могу привести вот эти схемы: http://forum.oberoncore.ru/viewtopic.php?f=78&t=1148
Правда, это спецификация, а не программа.

На замечание по поводу того, что "чем это лучше блок-схем" можно сказать, как минимум, что ДРАКОН — один из немногих визуальных языков, которые регламентируют взаимное положение элементов схемы (т.е. если мы нарисуем граф вершин и связей, то его можно разместить на плоскости автоматически). Т.е. индивидуальные выкрутасы типа "а я вот это помещу сюда, а это сюда" полностью исключены.

M> ЧТо будет, если у нас будет не КА?

Речь о классе алгоритмов, которые определяют поведение (в широком смысле, как "грамматику возможных последовательностей событий"). И это очень широкий класс. Алгоритмы этой категории обычно хорошо описываются через введение состояний, они обычно имеют много развилок. И здесь ДРАКОН хорошо визуализует.
Если говорить об алгоритмах обработки данных (т.е. любая часть программы, смысл которой заключается не в вычислении чего-либо, в обработке структуры данных и т.п.; где одной и той же цели можно достичь разными способами), то там преобладает мелкая декомпозиция на функции, в основном циклы, много IF в одной функции, как правило, стараемся избегать — и здесь лично я у ДРАКОНа никаких преимуществ не вижу.

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

Здравствуйте, Cyberax, Вы писали:

C>Не финансирует, совсем. В частности, вся разработка велась на частные деньги, что является по-настоящему уникальным.
Частные деньги закончились с Falcon-1.

C> SpaceX даже космодром свой будут строить.
Может и будут, но пока НАСА "подарила" LC-40, и переоборудовала его на бюджетные деньги для Falcon-9. А стартовый комплекс это самая дорогая часть создания новой ракеты, если считать двигатели первой ступени отдельно от самой ракеты.

C>НАСА просто купили запуски на готовых ракетах.
С выплатой аванса под разработку ракеты и корабля, это и называется "финансирует".

C> Кстати, первый коммерческий запуск SpaceX со спутниками Интелсата будет в следующем году.
Но первоначально планируемый на этот год HYLAS вынужденно ушел к французам на Ариан.
А в следующем году не Интелсату, а SES'у и каким-то тайваньцам. Сравнительно небольшие спутники, Falcon-9 больше не поднимет.

C>В теории, примерно такая же.
На практике окажется хуже. И сравнивать нужно не с Протоном, а с Зенитом с Байконура, по массе максимально выводимых коммерческих спутников сравнимы именно они. Стоимости доставки килограмма на МКС

, Прогресс для этого не оптимален, но пока летает на самом дешевом носителе, в общем

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

C>>Не финансирует, совсем. В частности, вся разработка велась на частные деньги, что является по-настоящему уникальным.
P>Частные деньги закончились с Falcon-1.
Технически, они до сих пор не закончились.

C>> SpaceX даже космодром свой будут строить.
P>Может и будут, но пока НАСА "подарила" LC-40, и переоборудовала его на бюджетные деньги для Falcon-9. А стартовый комплекс это самая дорогая часть создания новой ракеты, если считать двигатели первой ступени отдельно от самой ракеты.
Собственно, уже даже начали. Землю купили и получили разрешение на строительство.

Чего особо дорогого в космодроме — мне непонятно. SpaceX стартовый комплекс, кстати, сами строили.

C>>НАСА просто купили запуски на готовых ракетах.
P>С выплатой аванса под разработку ракеты и корабля, это и называется "финансирует".
Из ~2млрд. на контракты с НАСА приходится около $400 млн. Так что не совсем "финансируют", скорее "помогают".

Опять же, суммы совершенно смешные по "космическим" меркам. Это примерно один запуск "Шаттла"

C>> Кстати, первый коммерческий запуск SpaceX со спутниками Интелсата будет в следующем году.
P>Но первоначально планируемый на этот год HYLAS вынужденно ушел к французам на Ариан.
Бывает.

P>А в следующем году не Интелсату, а SES'у и каким-то тайваньцам. Сравнительно небольшие спутники, Falcon-9 больше не поднимет.
10 тонн на LEO. В ближайших планах — Falcon Heavy (53 тонны на LEO) из тех же модулей, что и Falcon-9.

Здравствуйте, Cyberax, Вы писали:

C>Собственно, уже даже начали. Землю купили и получили разрешение на строительство.
В Ванденберге что ли, на военной базе.

C>Чего особо дорогого в космодроме — мне непонятно. SpaceX стартовый комплекс, кстати, сами строили.
Для Falcon-1 в Ванденберге, на военной базе?

Или для Falcon-9 на военной базе же на мысе Каневерал? Оставшимся от "Титана" отдали в пользование и в подарок переоборудовали.

C>Из ~2млрд. на контракты с НАСА приходится около $400 млн. Так что не совсем "финансируют", скорее "помогают".
Что есть 2млрд?

C>Опять же, суммы совершенно смешные по "космическим" меркам. Это примерно один запуск "Шаттла"
Совершенно верно, но стоимость одного запуска "Шаттла" нескромная даже по американским космическим меркам.

C>10 тонн на LEO.
Ну тогда его нужно сравнивать с "Союзом", с "Союзом-У" где-нибудь за $25 миллионов.

Нужно смотреть не на LEO, а на GTO. Прямой конкурент Зенит с Байконура, но и он побольше поднимет и стоить будет около $50 миллионов.

C> В ближайших планах — Falcon Heavy (53 тонны на LEO) из тех же модулей, что и Falcon-9.
Ну нельзя из тех же модулей сделать 53 тонны на LEO, если их будет три, конечно. Придется удлинять, кое-что утолщать, шить и кроить. Но в любом случае если сделают на 53 тонны решпект им и уважуха.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

C>>Собственно, уже даже начали. Землю купили и получили разрешение на строительство.
P>В Ванденберге что ли, на военной базе.

В пустынях Техаса — на голом поле. Уже даже защитники животных (в Техасе?!?) активизировались.

C>>Чего особо дорогого в космодроме — мне непонятно. SpaceX стартовый комплекс, кстати, сами строили.
P>Для Falcon-1 в Ванденберге, на военной базе?

P>Или для Falcon-9 на военной базе же на мысе Каневерал? Оставшимся от "Титана" отдали в пользование и в подарок переоборудовали.
Там у них остался только бетонный стартовый стол в виде подарка. Не шибко большая помощь.

C>>Из ~2млрд. на контракты с НАСА приходится около $400 млн. Так что не совсем "финансируют", скорее "помогают".
P>Что есть 2млрд?
Баксов.

C>>10 тонн на LEO.
P>Ну тогда его нужно сравнивать с "Союзом", с "Союзом-У" где-нибудь за $25 миллионов.

P>Нужно смотреть не на LEO, а на GTO. Прямой конкурент Зенит с Байконура, но и он побольше поднимет и стоить будет около $50 миллионов.
На GTO вроде в районе полутора тонн.

C>> В ближайших планах — Falcon Heavy (53 тонны на LEO) из тех же модулей, что и Falcon-9.
P>Ну нельзя из тех же модулей сделать 53 тонны на LEO, если их будет три, конечно.
P>Придется удлинять, кое-что утолщать, шить и кроить. Но в любом случае если сделают на 53 тонны решпект им и уважуха.
Ты не понял, они реально собираются полностью взаимозаменяемые модули делать. То есть, совсем взаимозаменяемые. Так что их можно будет чуть ли не на стартовой площадке компоновать. Не знаю насколько получится, но задумка классная.

Ещё будет первая в истории ракета с общей топливной системой — ускорители будут подпитывать центральный модуль. Получается почти трёхступенчатая ракета по цене двухступенчатой.

Здравствуйте, Cyberax, Вы писали:

C>В пустынях Техаса — на голом поле. Уже даже защитники животных (в Техасе?!?) активизировались.
Техас не Невада, и коровы с ковбоями там в несметных количествах.

Те же казахи уж как за судьбу сусликов, на которых падают ступени от ракет, беспокоятся, прямо страдают.

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

C>Баксов.
Что баксов? И каких, зимбабвийских?

C>На GTO вроде в районе полутора тонн.
Поболее, почти пять тонн. Но средний спутник на GTO имеет тонн шесть. А полторы и Союз с Плесецка выведет, только не нужны они там.

C>Ты не понял, они реально собираются полностью взаимозаменяемые модули делать. То есть, совсем взаимозаменяемые.
Понял, понял. Привет от "Ангары".
C> Так что их можно будет чуть ли не на стартовой площадке компоновать. Не знаю насколько получится, но задумка классная.
Эта задумка была когда обещали Хеви не на 52 тонны, а на 32. С тех пор многое переиграли

C>Ещё будет первая в истории ракета с общей топливной системой — ускорители будут подпитывать центральный модуль. Получается почти трёхступенчатая ракета по цене двухступенчатой.
Да хоть запереливайся, не получится. То-то стартовая масса Falcona-9 — 333 тонны, 32 тонного варианта Heavy почти 900 тонн, а 52 тонного варианта уже 1400 тонн. Ну никак он из трех блоков не получается. А еще нужно двигатель в полтора раза форсировать не увеличивая его габариты.

P.S. Славно мы офтопим.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

C>>В пустынях Техаса — на голом поле. Уже даже защитники животных (в Техасе?!?) активизировались.
P>Техас не Невада, и коровы с ковбоями там в несметных количествах.

P>Те же казахи уж как за судьбу сусликов, на которых падают ступени от ракет, беспокоятся, прямо страдают.
Там зеленые за лягушек волнуются. Их может потревожить взлетающая ракета.

C>>Там у них остался только бетонный стартовый стол в виде подарка. Не шибко большая помощь.
P>Ну значит всё остальное им построили на бюджетные деньги. Только думается далеко не только стартовый стол, впрочем и это немало.
Реально, только стартовый стол (ну и подъездные дороги с прочей инфраструктурой, понятное дело), даже ангары они сами строили. Где-то у них на сайте было time-lapse видео строительства комплекса.

C>>Баксов.
P>Что баксов? И каких, зимбабвийских?

Ага.

C>> Так что их можно будет чуть ли не на стартовой площадке компоновать. Не знаю насколько получится, но задумка классная.
P>Эта задумка была когда обещали Хеви не на 52 тонны, а на 32. С тех пор многое переиграли
Все ещё обещают.

C>>Ещё будет первая в истории ракета с общей топливной системой — ускорители будут подпитывать центральный модуль. Получается почти трёхступенчатая ракета по цене двухступенчатой.
P>Да хоть запереливайся, не получится. То-то стартовая масса Falcona-9 — 333 тонны, 32 тонного варианта Heavy почти 900 тонн, а 52 тонного варианта уже 1400 тонн. Ну никак он из трех блоков не получается. А еще нужно двигатель в полтора раза форсировать не увеличивая его габариты.

Там будет три разгонника и центральный модуль. Причём движки везде одинаковы.

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

P>P.S. Славно мы офтопим.

Ага.

Здравствуйте, Cyberax, Вы писали:

C>Там зеленые за лягушек волнуются. Их может потревожить взлетающая ракета.
Что с них взять — зеленые, те и другие.

C>Там будет три разгонника и центральный модуль. Причём движки везде одинаковы.
Одинаковые и много, но не те, что у Falcon-9. Удельный импульс на 14 секунд больше, давление в камере в полтора раза больше, тяга тоже в полтора.

C>За счёт общей топливной системы сначала три разгонника + центральный модуль будут первой ступенью, потом разгонники отделяются, но за счёт общей топливной системы в центральном модуле горючее не будет израсходовано почти совсем. Так что центральный модуль дальше работает второй ступенью. Ну и там дальше отделение и уже обычная третяя ступень. Просто как всё гениальное.
Просто, просто. Но полезную нагрузку увеличивает только на несколько процентов. Как и добавление третьей ступени. Не случайно почти все современные ракеты двухступенчатые. Это, конечно, если с чистого листа пректировать при всех остальных равных условиях. Семерка и Протон отдельные истории, им добавление третьих ступеней много дало.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

C>>Там зеленые за лягушек волнуются. Их может потревожить взлетающая ракета.
P>Что с них взять — зеленые, те и другие.
Ага.

C>>Там будет три разгонника и центральный модуль. Причём движки везде одинаковы.
P>Одинаковые и много, но не те, что у Falcon-9. Удельный импульс на 14 секунд больше, давление в камере в полтора раза больше, тяга тоже в полтора.
?
На Falcon 9 стоят Merlin 1C на существующих или 1D на будущих ракетах, на Heavy будет только 1D.

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

C>>За счёт общей топливной системы сначала три разгонника + центральный модуль будут первой ступенью, потом разгонники отделяются, но за счёт общей топливной системы в центральном модуле горючее не будет израсходовано почти совсем. Так что центральный модуль дальше работает второй ступенью. Ну и там дальше отделение и уже обычная третяя ступень. Просто как всё гениальное.
P>Просто, просто. Но полезную нагрузку увеличивает только на несколько процентов.
Около 10% — весьма немало.

P>Как и добавление третьей ступени. Не случайно почти все современные ракеты двухступенчатые. Это, конечно, если с чистого листа пректировать при всех остальных равных условиях. Семерка и Протон отдельные истории, им добавление третьих ступеней много дало.
Третяя ступень, если она отдельная, то не очень окупается по стоимости. А тут они сделали 2.5-ступенчатую ракету.

Здравствуйте, Cyberax, Вы писали:

C>Около 10% — весьма немало.
Если обсуждать переходы ежду вариантами на 32 и 52 тонны, 10% это ничто.

C>Третяя ступень, если она отдельная, то не очень окупается по стоимости. А тут они сделали 2.5-ступенчатую ракету.
Ох уж эти условные циферки "2.5-ступенчатую ракета", "компьютер пятого поколения"...
К слову, 2.5 ступени было у какой-то эмериканской буйной фантазии (но успешно летавшей) на рубеже 50-60-х — два из четырех двигателей отделялись, когда становились избыточными.
А уж как важен был перелив в проекте "луной ракеты" Челомея — УР-700, там без него никуда.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

http://forum.oberoncore.ru/viewtopic.php?f=78&t=1959

Привожу пример реальной дракон-схемы.
Схема занимает 5 листов формата А1.
Мысленно расположите листы по горизонтали (в цепочку)
слева направо.
Пронумеруйте листы 1, 2, 3, 4, 5.
Для увеличения листов используйте "лупу" со знаком +

http://store.oberoncore.ru/lib/image/drakon/list1.png
http://store.oberoncore.ru/lib/image/drakon/list2.png
http://store.oberoncore.ru/lib/image/drakon/list3.png
http://store.oberoncore.ru/lib/image/drakon/list4.png
http://store.oberoncore.ru/lib/image/drakon/list5.png

остальное — по ссылке

Здравствуйте, Mamut, Вы писали:

M>остальное — по ссылке
Аааааа!!! Make me unsee it!

Где там биореактор Луговского?

Вообще, дракон очень похож на языки IEC_61131-3, которые достаточно активно применяются инженерами при программировании встроенной электроники. И скорее всего его ноги как раз из этого стандарта и растут. Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.

IEC 61131-3 is the third part (of 8) of the open international standard IEC 61131 for programmable logic controllers, and was first published in December 1993 by the IEC. The current (second) edition was published in 2003.

Part 3 of IEC 61131 deals with programming languages and defines two graphical and two textual PLC programming language standards:
Ladder diagram (LD), graphical
Function block diagram (FBD), graphical
Structured text (ST), textual
Instruction list (IL), textual
Sequential function chart (SFC), has elements to organize programs for sequential and parallel control processing.

Больше всего Дракон напоминает язык Ladder logic

Ladder logic is a programming language that represents a program by a graphical diagram based on the circuit diagrams of relay logic hardware. It is primarily used to develop software for programmable logic controllers (PLCs) used in industrial control applications. The name is based on the observation that programs in this language resemble ladders, with two vertical rails and a series of horizontal rungs between them.

Здравствуйте, DarkGray, Вы писали:

DG>Вообще, дракон очень похож на языки IEC_61131-3, которые достаточно активно применяются инженерами при программировании встроенной электроники. И скорее всего его ноги как раз из этого стандарта и растут. Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.
Не-не. Графические языки для электроники — это хорошая, полезная вещь. ДРАКОН — это язык записи алгоритмов. Внешняя похожесть — только в квадратиках со стрелочками.

Чтоб понять уровень их идиотизма — у них на форуме флейм в 5 страниц о том, как делать диаграммы с пересечениями стрелок.

Здравствуйте, pagid, Вы писали:

C>>Около 10% — весьма немало.
P>Если обсуждать переходы ежду вариантами на 32 и 52 тонны, 10% это ничто.
Большая ценовая эффективность — это не шутки. У сравнимой "Ангары А7" при полезной нагрузке в 40т на LEO масса в 1154т., против 53т. при массе 1400т.

C>>Третяя ступень, если она отдельная, то не очень окупается по стоимости. А тут они сделали 2.5-ступенчатую ракету.
P>Ох уж эти условные циферки "2.5-ступенчатую ракета", "компьютер пятого поколения"...
P>К слову, 2.5 ступени было у какой-то эмериканской буйной фантазии (но успешно летавшей) на рубеже 50-60-х — два из четырех двигателей отделялись, когда становились избыточными.
Вполне логично, идея лежит на поверхности.

P>А уж как важен был перелив в проекте "луной ракеты" Челомея — УР-700, там без него никуда.
Ну, лунные ракеты никуда нормально не полетели, к сожалению.

C> ДРАКОН — это язык записи алгоритмов.

вот это утверждение мне непонятно. А какой язык не является языком записи алгоритмов? Если, конечно, не брать группу markup languages.

Здравствуйте, DarkGray, Вы писали:

C>> ДРАКОН — это язык записи алгоритмов.
DG>вот это утверждение мне непонятно. А какой язык не является языком записи алгоритмов? Если, конечно, не брать группу markup languages.
Грубо говоря, языки для электрических схем устанавливают взаимное соединение элементов. В том числе и в тех случаях, когда результирующая схема не выполняет никаких цифровых вычислений.

А ДРАКОН — это язык для записи обычных императивных алгоритмов, т.е. if-then-else, циклы и т.п.

C>А ДРАКОН — это язык для записи обычных императивных алгоритмов, т.е. if-then-else, циклы и т.п.

Оба графических языка(Ladder diagram (LD), Function block diagram (FBD)) из IEC_61131-3 предназначены для того же (один меньше, другой больше).

FBD, вообще, похож на примитивные блок-схемы:

A function block diagram (FBD) is a block diagram that describes a function between input variables and output variables. A function is described as a set of elementary blocks. Input and output variables are connected to blocks by connection lines. An output of a block may also be connected to an input of another block:

Functional block diagram of the attitude control and maneuvering electronics system of the Gemini spacecraft. June 1962.
Inputs and outputs of the blocks are wired together with connection lines, or links. Single lines may be used to connect two logical points of the diagram:
An input variable and an input of a block
An output of a block and an input of another block
An output of a block and an output variable

Ниже по ссылке блоки FBD, прошу обратить внимание на блоки JMP, JMPC (условный переход), CAL (вызов блока), CALC (условный вызов блока).
http://software.pilz.com/Software_FAQ/toolhelp/psswinpro/GB/mergedProjects/Main/mergedProjects/ProgManual/Book/TEX_FBD_Grafische_Elemente_in_FBS.htm

зы
и, имхо, в тех же SCADA-системах — Дракон не плохо будет смотреть (при грамотном трансляторе для PLC) по сравнению с FBD.

Siemens, beckhoff, schneider и т.д. — сейчас все предлагают визуальные среды для программирования на FBD, который по сути графическое представление ассемблера. Дракон по сравнению с FBD — это шаг вперед, это графическое представление языков уровня алгола или паскаля.
Соответственно, дракон в нише для программирования электроники домофона, гаражных ворот, бойлерной, мини-конвеера для сахарного заводика и т.д. — смотрится перспективно, по сравнению с тем, что сейчас там есть.
В образовании и "нормальных"(не plc) нишах программирования Дракон, конечно, нафиг не нужен. Там уже все занято более современными, и более мощными и выразительными языками.

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

Здравствуйте, DarkGray, Вы писали:

DG>Ниже по ссылке блоки FBD, прошу обратить внимание на блоки JMP, JMPC (условный переход), CAL (вызов блока), CALC (условный вызов блока).
DG>http://software.pilz.com/Software_FAQ/toolhelp/psswinpro/GB/mergedProjects/Main/mergedProjects/ProgManual/Book/TEX_FBD_Grafische_Elemente_in_FBS.htm
В FBD может быть (и обычно бывает) несколько "путей исполнения", которые сливаются и раздваиваются, что вполне логично для функциональных схем, обрабатывающих реальные сигналы.

В ДРАКОНе такого нет, там есть обычный линейный поток управления. Приспособить его, конечно, можно. Но получится тот же FBD в другой нотации.

DG>и, имхо, в тех же SCADA-системах — Дракон не плохо будет смотреть (при грамотном трансляторе для PLC) по сравнению с FBD.
В СКАДА? Да ну.

Здравствуйте, DarkGray, Вы писали:

DG>Siemens, beckhoff, schneider и т.д. — сейчас все предлагают визуальные среды для программирования на FBD, который по сути графическое представление ассемблера. Дракон по сравнению с FBD — это шаг вперед, это графическое представление языков уровня алгола или паскаля.
DG>Соответственно, дракон в нише для программирования электроники домофона, гаражных ворот, бойлерной, мини-конвеера для сахарного заводика и т.д. — смотрится перспективно, по сравнению с тем, что сейчас там есть.
Почему? Это всё обычные примеры КА. ДРАКОН асболютно отстойно подходит для них, так как переходы между состояниями получаются скрытыми в мелочах из действий.

Тем более, что в ДРАКОНе абсолютно отсутствуют понятия инвариантов и программирования по контракту, что как раз весьма важно для вещей типа бойлерной или контроллера светофора. Не хотелось бы, чтобы у светофора горело одновременно два зелёных света. Т.е. нельзя формально взять схему и показать, используя эту схему, что никогда не возможно наличие конфликтующих зелёных. Точнее можно, но потребуется обычное формальное текстовое доказательство.

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

C> Почему? Это всё обычные примеры КА

Это поднимает вопрос, а какая программа является не обычным примером КА?

C> В ДРАКОНе такого нет, там есть обычный линейный поток управления.

Каждая вертикальная линия в драконе — это отдельный поток управления. Линии могут разветвляться или сливаться. Разве не так?

C>Для сравнения, в JPF от НАСА есть интересный режим, когда задаётся конечный автомат состояний (в виде графической схемы!) и верификатор проверяет, что код соответствует этой схеме. Причём таких схем может быть несколько.

в моем понимании — это отдельный блок. и его можно прикрутить к произвольному языку.
и разве JPF графический?

C>Тем более, что в ДРАКОНе абсолютно отсутствуют понятия инвариантов и программирования по контракту

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

Что на твой взгляд еще бы стоило добавить (или сделать по другому)? При условии, что язык обязан иметь полное графическое представление (допустим на мгновение, что данное требование — догма и не подлежит обсуждению).

DG>Каждая вертикальная линия в драконе — это отдельный поток управления. Линии могут разветвляться или сливаться. Разве не так?

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>КАК ОЦЕНИВАЮТ ЯЗЫК ДРАКОН В АНГЛИИ?

ВП>По мнению Charles RB, это одно из важных достижений Роскосмоса.

ВП>http://forums.comicbookresources.com/showthread.php?317650-Obamas-trip-to-NASA&s=faed9e8d337b448f171f4d4226c216a0&p=10978923&viewfull=1#post10978923

ВП>

ВП>Originally Posted by FalconX2000

ВП>What about Russia's space agency/program?
ВП>What can they boast about inventing?

Хорошее слово "boast about" — ничего другого ты тут и не делаешь.

Здравствуйте, DarkGray, Вы писали:

DG>Вообще, дракон очень похож на языки IEC_61131-3, которые достаточно активно применяются инженерами при программировании встроенной электроники. И скорее всего его ноги как раз из этого стандарта и растут. Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.

Ну, по редким внятным описаниям от того же Паронджанова, так и есть. Инженеры-непрограммисты описывают достаточно высокоуровневый алгоритм, который потом воплощается в железе или софте (или и том и другом).

Сейчас же (если взять этот ответ), Дракон можно использовать как простой аналог Rational Rose для кодогенерации на основе UML (где в роли UML выступает сам Дракон).

К>>И как это соотносится с тем, что проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?
К>>Ещё пару вопросов (если вдруг есть возможность/желание ответить) -
К>>Как насчёт взаимодействия сущностей (проектируем в рамках ООП, например) наподобие диаграмм последовательности?
К>>Можно ли на драконе нарисовать алгоритм, использующий ФВП?
LVV>1. Я думаю, эти вопросы лучше задать автору Дракона Владимиру Даниэловичу.

Задали, и не один раз. Он так и не соизволил ответить. Ну или генерит какую=то бредятину (например, см. его ответ на мой вопрос тут)

LVV>2. Можно сходить на форум oberoncore.ru и пообсуждать там. На форуме очень конкретно и предметно обсуждаются в том числе и ваши вопросы.

Да-да. Исключительно корректно и исключительно предметно

Ну и еще один перл приведу:

DM>А можно пару подтверждающих примеров?
За этим вам лучше сходить на oberoncore.ru
Там большое сообщество, там огромное количество примеров, там обсуждают и делают редакторы Дракона.

За три страницы обсуждения успели обсудить все — мою личность, мои стихи, мою компетенцию, нимб и самовлюбленность TAU, но примеры так и не появились. К чему бы это?

> За три страницы обсуждения успели обсудить все — мою личность, мои стихи, мою компетенцию, нимб и самовлюбленность TAU, но примеры так и не появились. К чему бы это?

Возможно причина очень проста — вопреки привычным утверждениям, рисовать графические представления труднее, чем писать код программы. Писать мы можем от частного к общему, а рисовать — нет. При написании мы можем удерживать в голове только несколько строк алгоритма, остальное "за кадром", а при рисовании нужно удерживать в голове минимально лист схемы и всегда "ориентироваться на местности", как только какое-то пересечение, нужно проводить топологические изыскания.

Posted via RSDN NNTP Server 2.1 beta

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

http://sourceforge.net/projects/drakon-editor/files/DRAKON.pptx/download
http://drakon-editor.sourceforge.net/python/python.html
http://drakon-editor.sourceforge.net/DRAKON.pdf
http://drakon.su/_media/biblioteka/drakondescription.pdf

Какие средства язык предоставляет для организации больших программ?
Я имею в виду средства абстракции и (де)композиции алгоритмов и данных.

И как это соотносится с тем, что проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.?

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

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

Я в глубоком детстве познакомился с так называемыми "блок схемами".
Что именно нового превносит дракон, кроме собственного синтаксиса?
Чем же именно он лучше для этих целей чем диаграммы поведения UML?

Дракон основан на блок-схемах, но отличается от них:
1. У Дракона есть конструкция "силуэт".

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

3. Дракон позволяет быстро выделить happy path и игнорировать код обработки ошибочных ситуаций.

Как насчёт взаимодействия сущностей (проектируем в рамках ООП, например) наподобие диаграмм последовательности?

Диаграмма последовательности описывает один use case и не содержит ветвления и циклов.
Самое главное в этом виде диаграмм — какие именно сущности взаимодействуют и в каком порядке.
Дракон же специализируется на ветвлении (if then else) и циклах.

Диаграмма последовательности — это детализация юз кейса с точки зрения его участников.
Дракон также взаимосвязан с юз кейсами: Дракон диаграмма — это компактное представление всех юз кейсов данного алгоритма.

Для случая, когда сущность имеет особое значение, в Драконе имеется особая икона "полка".
Есть и специальные иконы для приёма сообщений (или ввода) и посылки сообщений (или вывода).

Язык Дракон значительно облегчает алгоритмизацию и программирование
Чем это подтверждено?

Практика — критерий истины.
Всем желающим предлагается подтвердить (или опровергнуть) преимущества Дракона на практике!

Нет пояснения в чем же её эргономичность.

Эргономичность состоит в том, что правила Дракона имеют объективные основания. Кратко приведу некоторые из них:

1) Пересечения линий запрещены.
(Думаю, объяснять не надо. Чтобы избежать аналогии диаграммы с макаронами или с мотком ниток.)

2) Следующая икона всегда строго внизу.
(Читатель диаграммы никогда не должен искать глазами следующий шаг алгоритма — он всегда внизу.
Почему именно движение вниз? Потому что движение вниз естественно при наличии гравитации, оно ассоциируется с расслаблением.)

3) Квадратики соединяются не стрелками, а прямыми линиями.
(Чтобы визуально не засорять диаграмму. Стрелки не нужны: линия всегда ведёт вниз.
Жирная стрелка в Драконе всегда означает цикл, поэтому циклы сразу видны. )

4) У иконы "развилка" (if) один выход всегда внизу, а другой — справа.
(Во-первых, этим достигается предсказуемость и единообразие. Человек концентрируется на идее, а не на способе её представления.
Кроме того, выполняется следующий закон: дальнейшее развитие алгоритма всегда идёт вниз,
а ветвление — вправо. Никогда влево. Это соответствует направлению чтения текста в европейских языках.)

5) Косые и кривые линии запрещены.
(Граф программы в Драконе не только плоский, но и прямоугольный. Он удобен для восприятия.
В городе с прямоугольной планировкой ориентироваться гораздо проще, чем с беспорядочной.)

6) Икона "развилка" (if) имеет форму не ромба, как в блок-схемах, а усечённого ромба.
(Это позволяет вместить в неё больше текста и делает диаграмму более компактной.)

Легкость то в чем. Я вот бегло пробежался по книге и пришел к выводу о огромных схемах. Текстовая форма более компактна.

1) Текстовая форма более компактна, но зато графическая — более наглядна.
Проблема в том, что для того, чтобы понять текстовое выражение хотя бы средней сложности, его приходится распаковывать в уме.
В случае с графической диаграммой вся сложность находится на поверхности и хорошо видна.
Мозговые усилия, требуемые на распаковку текстовой программы, можно использовать в мирных целях!

2) Наш зрительный анализатор оптимизирован под графику, а не под текст. Графике уже миллионы лет, а текст недавно появился.

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

Запостите лучше сюда алгоритм балансировки AVL-дерева, пожалуйста.
А то все эти "Обед в ресторане" и "Покрасить забор" как-то не тянут на типичные задачи
попрошу привести здесь алгоритм быстрой сортировки,
балансировки бинарного дерева и парсера текста. Чтоб их можно было реально выполнить.

Быстрая сортировка: http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png
Алгоритм Дейкстры: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3946#p72330
Парсер рекурсивного спуска: http://forum.oberoncore.ru/download/file.php?id=3244

ОК. Покажи реализацию на драконе хотя бы одного компилятора или интерпетатора ДСЛ.

Работа с process dictionary в Erlang. Process dictionary — зло, но если злить чёрта, то с удобствами.
http://rel-erl.sourceforge.net/

V>Да и сейчас, если чувствую нутром во время ревью чужого кода, что "здесь что-то не то", беру блокнот и рисую квадратики и стрелочки и сразу вижу это "не то" или
что напрасно сомневался.
Прекрасно. А теперь то же самое попробуй на формальном ДРАКОНе.

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

Засунуть слова в прямоугольники и заменить операторы на стрелочки много ума не надо.
И эта махинация ухудшила восприятие.
Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.

1) В Драконе для обычных переходов не используются стрелки, только простые линии.
2) Клубков, комков и вермишени в Драконе не бывает, потому что пересечения линий запрещены.
3) Одна из сильных сторон Дракона: циклы сразу видны.

Дело в том, что ДРАКОН — это не язык разработки use-case'ов и для описания формальных требований он тоже не очень подходит.
Все-таки в RFC много отcебятины, воды и что самое досадное — недоговоренностей.

Юз кейсы и Дракон — это почти как Партия и Ленин. Говорим одно, подразумеваем другое.
Дракон-диаграмма представляет собой компактное представление всех юз кейсов данного компонента системы.
Каждый из юз кейсов легко получить из Дракон-диаграммы, если вести пальцем по линиям и квадратикам.
Выбор на развилках даёт разные юз кейсы.
Большой плюс Дракона в том, что удаётся увидеть юз кейсы, о которых заказчик/начальник/аналитег даже и не догадывался.
Дракон устраняет недоговорённости и неопределённости в проектировании.

Насчёт практического использования Дракона вне космоса.
Делаем систему контроля доступа. Есть разные виды ресурсов, над ними можно производить разные действия. В ресурсы также зашиты ограничения доступа.
А ещё есть пользователи со своими правами. Есть группы, у которых тоже есть права. Пользователь может быть в разных группах. И ещё кое-чего.
Всё это вместе даёт довольно сложную картину. Самое страшное в ней — это то, что НИКТО полностью не представляет, как это должно работать.
Есть несколько спецов, каждый из которых имеет МНЕНИЕ об одном виде ресурса, которые его касается.
Собрал всю информацию, нарисовал Дракон-схемы ("раздраконил" (с)). Сразу всё стало на свои места.
Что дальше? Надо утвердить с боем полученные спеки у аналитега, а он немец, понимаете? Я не говорю по-немецки, общаюсь с ним на адском местном суржике "Norglish".
Шансов объяснить ему это всё в течение суток нет. Даю ему Дракон-схемы и через 30 минут получаю "зачøт". Немец всё понял, а ведь он Дракона-то и не видел никогда.
После этого, водя пальцем по линиям и квадратиком, набросал юнит-тесты. И уже потом написал основной код и спокойно лёг спать.
Результат — всё работает.

Дополнительно пишутся тесты, где моделируются все возможные крайние случаи, и пытаются таким образом обнаружить ошибки. Это делать должен не инженер — у него намылен глаз, ему эту работу поручать нельзя (вернее он конечно сам то проверит 10 раз перед сдачей, но он вполне может ошибиться и что то пропустить, человеческий фактор!).
Инженер не может создать программу испытаний для программиста, программист в свою очередь не владеет темой в комплексе.

Кто ставит задачу, тот и определяет критерии приёмки. Если инженер/аналитег пишет требования, то он же и должен составить тестовые сценарии.
Низкоуровневые юнит-тесты должен, конечно, писать сам программист, но любая функциональность, которая видна пользователю, проверяется по сценариям инженера/аналитега.
То же самое касается исправлений ошибок. Сначала инженер/куэйщик говорит, как оно должно работать после исправления, потом программист исправляет.
Не важно, какой процесс в конторе — agile, waterfall или базар. Если программист кодит ДО того, как составлен сценарий тестирования, придёт беда и чума.

Плюс Дракона в том, что он наглядно показывает все необходимые тестовые сценарии для алгоритма на одной диаграмме.

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

В Драконе это есть. ИС "Дракон" Тышова поддерживает разветвления и слияния потока выполнения
http://drakon.su/instrumenty/is_drakon

Ибо текстом я сделаю гораздо быстрее и качественней.

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

Прогрессивный мир нынче смотрит на: метапрограммирование, зависимые типы, typesets, proof-carrying code. Крайне интересны исследования в области total functional programming.

Многое из перечисленного выше отлично работает вместе с Драконом. То же функциональное программирование, отлично сочетается с Драконом (ДРАКОН-Эрланг например).

Здравствуйте, Степан Митькин, Вы писали:

СМ>1) Текстовая форма более компактна, но зато графическая — более наглядна.
СМ>Проблема в том, что для того, чтобы понять текстовое выражение хотя бы средней сложности, его приходится распаковывать в уме.
Для этого есть декомпозиция, очень способствует...
Для наглядности графического представления схемы даже небольшой программы нужно развесить на стене, для большой стены не хватит. Возможно в той отрасли откуда Дракон произошёл это не так и плохо, но для других задач может быть затруднительно.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, Степан Митькин, Вы писали:

СМ>Быстрая сортировка: http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png

Модификация быстрой сортировки, использующая дополнительную память (т.е. не по месту), записывается на функциональном языке в 2-4 очень понятных строчки, которые не содержат явных циклов и ветвления.
Даже если из дракон-схемы выкинуть код для простых случаев, все равно она останется куда более громоздкой, чем код на ФЯ.

qsort []     = []
qsort (p:xs) = qsort [x | x<-xs, x<p] ++ [p] ++ qsort [x | x<-xs, x>=p]

> qsort []     = []
> qsort (p:xs) = qsort [x | x<-xs, x<p] ++ [p] ++ qsort [x | x<-xs, x>=p]
>

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Если сравнивать эти два случая, то для целей программирования дракон, как пример читаемой записи, в таком сравнении практичнее.

удивлен и озадачен

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

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

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

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

Posted via RSDN NNTP Server 2.1 beta

СМ>

СМ>Какие средства язык предоставляет для организации больших программ?
СМ>Я имею в виду средства абстракции и (де)композиции алгоритмов и данных.

СМ>И как это соотносится с тем, что проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.?

СМ>Дракон предназначен только для представления алгоритмов.
СМ>Всё остальное: модель данных, иерархия наследования, уровни абстракции — делается в обычном порядке средствами вашего любимого языка программирования.

Только вот как только язык не ложится на Дракон, возникают проблемы (см. Erlang)

СМ>Для проектирования статической структуры программы используются другие виды диаграмм: сущность-связь, диаграмма классов, диаграмма компонентов и прочая.

СМ>Что касается декомпозиции алгоритмов.
СМ>Дракон даёт дополнительный способ декомпозиции в дополнение к обычному вызову подпрограмм.
СМ>Это так называемый "силуэт". Он разбивает алгоритм на логические части, что позволяет избежать необходимости лишний раз создавать подпрограммы.

Помимо блок схем есть, например, UML

СМ>2. У Дракона есть дополнительные правила, цель которых — сделать диаграмму более предсказуемой и читаемой.
СМ>Каждое из этих правил имеет объективное обоснование.
СМ>Например, строгий запрет пересечения линий нужен, чтобы картинка не превратилась в кашу.

Что приводит к проблемам. http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184

СМ>Быстрая сортировка: http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png

Пр обыструю сортировку я уже задавал вопрос:

Сразу вопрос. В recurse должны поступать, соответственно, left и right из partition. Где эта передача? Из диаграммы она совершенно никак не следует

СМ>Шансов объяснить ему это всё в течение суток нет. Даю ему Дракон-схемы и через 30 минут получаю "зачøт". Немец всё понял, а ведь он Дракона-то и не видел никогда.
СМ>После этого, водя пальцем по линиям и квадратиком, набросал юнит-тесты. И уже потом написал основной код и спокойно лёг спать.
СМ>Результат — всё работает.

То же самое можно сказать и про правильно нарисованную схему в UML. Не говоря о том, что UML позволяет представить проблему с нескольких точек зрения.

Здравствуйте, grosborn, Вы писали:

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

G>Я к тому, что хаскель без комментариев это код с которым невозможно совместно работать. Его специально нужно делать читаемым. Хотя я даже сомневаюсь что это возможно. Почти так же как регулярки. Регулярки вообще крайний случай нечитабельности.
Странно, квиксорт на хаскеле писал не я, но я его понимаю. К тому же, этот код один в один похож на запись квиксорта в математической нотации, читаемость которой довольно высока.

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

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

На это я тоже уже отвечал:

К сожалению, исходники как раз наглядно показывают, что без поллитры и активной помощи автора в них фиг разберешься :

— Диаграммы не помещаются на экране (даже при zoom out)
— Взаимодействие между отдельными функциями (типа bad_case/foreach_current/и т.п. во всяких cs.drn и т.п.) непонятно (может они вызываются откуда-то извне? неизвестно).
— они достаточно низкоуровневы, чтобы без комментариев разобраться было уже невозможно:
Код:
set found_keywords [ gen_cpp::find_keywords $first $keywords ]
set alien_keywords [ gen_cpp::find_not_belonging $first $keywords ]
— местами это по сути псевдокод, только в визуальном обрамлении (например, alt_edit.drn -> shadow), то есть от визуальности он не выигрывает вообще ничего. В частности, для диаграмм типа alt_edit.drn -> update, если использовать паттерн матчинг (Haskell, Erlang, Nemerle), то даже текстовая запись будет не менее, а то и более наглядна

СМ>

СМ>Прогрессивный мир нынче смотрит на: метапрограммирование, зависимые типы, typesets, proof-carrying code. Крайне интересны исследования в области total functional programming.

СМ>Многое из перечисленного выше отлично работает вместе с Драконом. То же функциональное программирование, отлично сочетается с Драконом (ДРАКОН-Эрланг например).

НИфига он там не сочетается. Цитирую:

2. Перегрузка функций (наличие нескольких функций с одним именем) запрещены в DRAKON Editor'е по
политическим мотивам.
3. Ветвление логики делается только стандартными средствами Дракона, pattern matching (case of, when) для этого не используется.

На драконе даже алгоритмы с ФВП записать не удастся

P.S. Ветку с вопросами на oberoncore закрыли (потому что кому нафиг нужны неудобные вопросы?)

Поэтому будет хорошо, если вопросы, задаваемые тут, на oberoncore транслировал кто-то из участников того форума. Так что, Степан, просьба перезадать некоторые из вопросов, которые возниктнут тут, на oberoncore

[skipped]

Здравствуйте Степан...

А Вам это не напоминает мертворожденное дитятё? Хотя согласен применимо в узконаправленных областях, тьфу о мертвых плохо не говорят, но вся это схоластика, даж боюсь эт слово дурное — DSL употребить.... Может проще использовать SVG? И портабилити, ну и мало ли у кого руки под что заточены... Эт так комментарий, не ради флэйма...

avalon 1.0rc3 build 428, zlib 1.2.5

Уважаемые коллеги!

Отличительной особенностью языка ДРАКОН является графический синтаксис.

Ниже дано формальное описание графического синтаксиса.
Но перед этим описан дракон-конструктор (дракон-редактор).
http://files.rsdn.ru/100994/%d0%a7%d0%b0%d1%81%d1%82%d1%8c%206.%20393-424%20%d0%9a%d0%be%d0%bd%d1%81%d1%82%d1%80%d1%83%d0%ba%d1%82%d0%be%d1%80%20%d0%b0%d0%bb%d0%b3%d0%be%d1%80%d0%b8%d1%82%d0%bc%d0%be%d0%b2%20%d0%b8%20%d1%84%d0%be%d1%80%d0%bc%d0%b0%d0%bb%d1%8c%d0%bd%d0%be%d0%b5%20%d0%be%d0%bf%d0%b8%d1%81%d0%b0%d0%bd%d0%b8%d0%b5.pdf

Владимир, а чем эта идея новая?
Алгоритмические схемы существуют уже очень давно, в десятках известных и тысячах менее известных вариантах.
Связки графического представления с конкретными языками / рантаймом — тоже.
Даже если принять, что ДРАКОНовская реализация превосходит все остальные — что нового-то в этой "идее"?

Уже после прочтения заголовка темы Вас мало кто воспринимает всерьез.

Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание. Разработка, вроде как, задумывается для реального применения. Вместо блок-схем используются блоки как в пазлах, выглядит гламурно:

Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...

Здравствуйте, PSV100, Вы писали:

PSV>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание.

В обсуждении на OpenNet наткнулся на ссылку на конкурента (в прямом смысле создан в 70 — 80 в СССР и
тоже использовался ракетчиками

) Р-технологии

На первый взгляд и судя по схемам здесь http://glushkov.org/?page_id=59

гораздо нагляднее (во всяком случае для программиста) Дракона.

Здравствуйте, FR, Вы писали:

FR>В обсуждении на OpenNet наткнулся на ссылку на конкурента (в прямом смысле создан в 70 — 80 в СССР и
FR>тоже использовался ракетчиками

) Р-технологии

А я все никак не мог вспомнить, пока читал тему, как эта технология называется. Боюсь наврать, эксперименты на ЕС ЭВМ проводились с Фортраном, PL/1 и, возможно, Ассемблером. Я даже распечатки таких схем видел с кодом внутри. Ну не было там графических дисплеев. Я не знаю, как вводились эти схемы.
Языки, если не вру, назывались графический Фортран, графический PL/1. Google по запросу "графический Фортран" привел к Графору, который, имея прямое отношение как к Фортрану, так и к графике, никак не связан с темой обсуждения. Вот я ничего и не нашел.
Интересно, те, кто постарше, например, LaptevVV, в курсе, что там происходило и есть ли этому какое-нибудь развитие? Использовалась ли эта Р-технология промышленно?

Здравствуйте, PSV100, Вы писали:

PSV>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание. Разработка, вроде как, задумывается для реального применения. Вместо блок-схем используются блоки как в пазлах, выглядит гламурно:
Тот же Scratch, только не надо ничего скачивать. ИМХО для детей только. Либо для обучения на первых курсах, после чего про него забываем, как страшный сон.
Никто в здравом уме такие языки для промышленного применения использовать не будет. Хоть это будет трижды гугол — если будут пытаться на это пересадить программистов реальных, ничего у них не выйдет. Если попробовать посадить непрограммистов — попробовать конечно можно, в теории может и получиться, но я как то сомневаюсь, что получится даже у гугла. В лучшем случае кончится тем же, что и всегда — непрограммисты на этом ужасе черти что наваяют, логика разрастется до неприличных размеров, все будет черти как запутанно, что сам черт голову сломит, и далее за бешенные деньги этот ужас посадят разгребать программистов, которые будут долго и сильно материться.

) Р-технологии

FR>На первый взгляд и судя по схемам здесь http://glushkov.org/?page_id=59
FR>гораздо нагляднее (во всяком случае для программиста) Дракона.

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

Сейчас немного посмотрел на Р-технологию. Что понравилось на фоне Дракона:

— отсутствие явных блоков, т.е. всяких прямоугольников с ромбиками и пр., т.е. это не блок-схемы. Их банально задалбывает рисовать на бумаге, а пользоваться графическим редактором — ещё более муторное дело. В Р-технологии нагружаются ребра графа, текст над и под ребрами как-то меньше влияет на восприятие текста в соседних "блоках", например, нет такого желания, как сделать "прямоугольники" одинакового размера. И, имхо, для Р-графов проще реализовать поддержку в текстовом редакторе для их удобного ввода в псевдографике (что крайне проблематично для Дракона и прочих блок-схем);

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

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

— правил в Р-технологии ещё меньше, чем в Драконе. При этом схемы выглядят покомпатнее, с большим запасом для показа содержательной информации. Но здесь есть явные стрелки и возможно пересечение линий, насколько это ухудшает восприятие — пока сложно сказать.

Короче говоря, очевидно, что графы РТ задумывались как замена блок-схемам, и на первый взгляд не плохая. В инете очень мало информации о проекте (здесь пару слов про Р-технологию, здесь можно прочитать дифирамбы для неё). Жаль нет толкового сравнения с Драконом, реально интересно и мнение Владимира Даниловича.

Здравствуйте, PSV100, Вы писали:

PSV>Короче говоря, очевидно, что графы РТ задумывались как замена блок-схемам, и на первый взгляд не плохая. В инете очень мало информации о проекте (здесь пару слов про Р-технологию, здесь можно прочитать дифирамбы для неё). Жаль нет толкового сравнения с Драконом, реально интересно и мнение Владимира Даниловича.

Тут есть редактор http://glushkov.org/?page_id=64
и интерпретатор http://glushkov.org/?page_id=272 (с QtScript в качестве текста).

Здравствуйте, elmal, Вы писали:

PSV>>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание. Разработка, вроде как, задумывается для реального применения. Вместо блок-схем используются блоки как в пазлах, выглядит гламурно:

E>Тот же Scratch, только не надо ничего скачивать. ИМХО для детей только. Либо для обучения на первых курсах, после чего про него забываем, как страшный сон.
E>Никто в здравом уме такие языки для промышленного применения использовать не будет. Хоть это будет трижды гугол — если будут пытаться на это пересадить программистов реальных, ничего у них не выйдет. Если попробовать посадить непрограммистов — попробовать конечно можно, в теории может и получиться, но я как то сомневаюсь, что получится даже у гугла. В лучшем случае кончится тем же, что и всегда — непрограммисты на этом ужасе черти что наваяют, логика разрастется до неприличных размеров, все будет черти как запутанно, что сам черт голову сломит, и далее за бешенные деньги этот ужас посадят разгребать программистов, которые будут долго и сильно материться.

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

Здравствуйте, FR, Вы писали:

FR>Тут есть редактор http://glushkov.org/?page_id=64
FR>и интерпретатор http://glushkov.org/?page_id=272 (с QtScript в качестве текста).

Ага, видел и пощупал. Редактор по сравнению с драконовскими несколько проще и удобнее, т.к. "втыкать" нужно фактически одни дуги, а не разные квадратики. Но всё-равно, все эти графические редакторы ну уж очень муторные. Проще карандаш да резинка. Но для Р-схем, в отличие от Дракона, реально можно придумать какие-то выкрутасы для нормального текстового редактора, что-то по мотивам эмаксового org-mode, когда там таблицы рисуются. Для Дракона и прочих блок-схем у меня фантазии не хватило (правда и используется он не так уж и часто, поэтому пока не было сильного нагибания, иначе без drakon-mode

было бы совсем тяжко).

Здравствуйте, PSV100, Вы писали:

PSV>Ага, видел и пощупал. Редактор по сравнению с драконовскими несколько проще и удобнее, т.к. "втыкать" нужно фактически одни дуги, а не разные квадратики. Но всё-равно, все эти графические редакторы ну уж очень муторные. Проще карандаш да резинка. Но для Р-схем, в отличие от Дракона, реально можно придумать какие-то выкрутасы для нормального текстового редактора, что-то по мотивам эмаксового org-mode, когда там таблицы рисуются. Для Дракона и прочих блок-схем у меня фантазии не хватило (правда и используется он не так уж и часто, поэтому пока не было сильного нагибания, иначе без drakon-mode

было бы совсем тяжко).

Вот еще http://emag.iis.ru/arc/infosoc/emag.nsf/BPA/e72abd849fe68a7dc32576eb0034c090 статья, похоже раньше
чуть ли не аппаратный ввод был для него

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

Здравствуйте, FR, Вы писали:

FR>Вот еще http://emag.iis.ru/arc/infosoc/emag.nsf/BPA/e72abd849fe68a7dc32576eb0034c090 статья, похоже раньше
FR>чуть ли не аппаратный ввод был для него

FR>http://emag.iis.ru/arc/infosoc/emag.nsf/5312565765062e8cc32575c2004f59bf/e72abd849fe68a7dc32576eb0034c090/Body/77.4DC2?OpenElement&FieldElemFormat=gif

Схемы, очень похожие на приведенные в статье, я видел в распечатанном виде. За точный вид не поручусь, но, ЕМНИП, они выглядели, как на рисунках 2 и 3 из статьи. Вот язык был не Паскаль. Скорее, PL/1. И аббревиатуру РТК я откуда-то знаю.

Осталось вспомнить, откуда. Наверное, какой-то доклад слушал по теме, и что-то отложилось. Но с Р-технологией в работе я не сталкивался.

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

Тоже посмотрю, может, и вспомню, где я обо всем этом услышал.

Там еще фишка такая была: пишем программу с помощью диаграмм, к примеру на PL/1, и если нас в PL что-то не устраивает, просто меняем текстовые фрагменты на Фортран. Структура программы остается неизменной.

PSV>Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...

Такое, IMHO, возможно — говорил здесь применительно к похожей среде — Скретчу. Как ещё это можно развить — на этой странице. Конструктивная критика приветствуется.

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>>Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша.
ВП>>Но в сложных случаях дело обстоит иначе.
E>Кстати о сложных случаях. Со всей этой декомпозицией мы забыли спросить одну интересную вещь — а как делается обработка ошибок? Я не увидел обработки ошибок ни на одной из диаграмм. Итак, предположим мы пишем софт управления атомной станцией. И хотим следующее — чтобы в случае абсолютно любых ошибочных ситуаций заглушать реактор. Это настолько важно, что это все требуется на на диаграмме верхнего уровня! Что любая непредвиденная ситуация — заглушаем реактор. Эта любая непредвиденная ситуация может вылететь откуда угодно из нижестоящего сабалгоритма. То есть интересует в языке такая полезная вещь, как исключения. Итого — как это будет на Драконе? Я приблизительно догадываюсь, что на главной диаграмме сверху будет состояние ошибка, в которую мы можем переходить из других состояний. Но ... любой прямоугольничек может у нас выкинуть исключение. Даже функция проверки условия может выкинуть исключение (предположим, там датчик какой оказывается неисправным). Как будем поступать? Более того, обработчик ошибки очень интересуется деталями, в зависимости от того, что за ошибка, он захочет принять решение, стопать ли реактор или нет, или попытаться переключиться на резервный контур и проверить все еще раз. Как будет выглядить алгоритм в этом случае? Что то мне подсказывает, что будет очень неслабое усложнение схемы на ровном месте. И если исключения поддерживаются — очень интересует, как будет генерироваться программа на фортране, где на момент последнего с ним знакомства исключениями и не пахло?
Вы имели в виду описанное здесь? Т.е. что если любому шагу процесса разрешить выбрасывать исключение — то либо надо после вершины, соответствующей шагу (допустим, мы приняли такое соглашение), ставить конструкцию типа описанной — либо считать, что она всегда там стоит и делать её отдельно? Причём в первом случае логику обработки можно специализировать, а во втором придётся либо делать глобальный разбор на все возможные типы ситуаций, либо ряд схем специализирванных связывать по кодам типов с шагами?

Здравствуйте, VladZharinov, Вы писали:

VZ>Вы имели в виду описанное здесь? Т.е. что если любому шагу процесса разрешить выбрасывать исключение — то либо надо после вершины, соответствующей шагу (допустим, мы приняли такое соглашение), ставить конструкцию типа описанной — либо считать, что она всегда там стоит и делать её отдельно? Причём в первом случае логику обработки можно специализировать, а во втором придётся либо делать глобальный разбор на все возможные типы ситуаций, либо ряд схем специализирванных связывать по кодам типов с шагами?
Да, имел приблизительно именно это. Но мне вроде уже ответили, что обработка ошибок делается через глобальные переменные, а исключения, как я понял, не используются.

Здравствуйте, DarkGray, Вы писали:

C>>Тем более, что в ДРАКОНе абсолютно отсутствуют понятия инвариантов и программирования по контракту

DG>Вот такой разговор, в формате — а что стоит добавить, чтобы стало лучше — мне больше нравится, чем разговор вида: язык — говно, автор — идиот.
DG>В первом случае, мы все становимся чуточку образованнее, во втором — лишь глупее и обиженнее.

DG>Что на твой взгляд еще бы стоило добавить (или сделать по другому)? При условии, что язык обязан иметь полное графическое представление (допустим на мгновение, что данное требование — догма и не подлежит обсуждению).
Добавить, вероятно, многое. С указанным условием согласен — и один "человек, который явно применяет это на практике" (С Mamut) по-своему говорил о том же: "Один из важнейших интеллектуальных навыков для инженера-программиста — умение находить подобие во внешне
непохожих конструкциях и свободно выполнять эквивалентные преобразования между разными базисами. Ярким примером
является эквивалентность по выразительной мощности архитектурных моделей на основе объектов-методов и процессов-
сообщений..."(И. Ермаков, с. 5). Кстати, TAU тут зря грубили — он тоже работает над практическим программированием ответственных систем. Где и верификация, и тестирование есть. В их системе подход немного другой, чем в ГРАФИТ-ФЛОКС — можно посмотреть на сайте.
Попытался определить, что именно, на примере паскалеподобных языков. Были различные примеры, их можно найти в этом разделе. Там и связь с автоматным программированием намечена. Но именно для иллюстрации базовых средств реализовать предложенную Вами "догму" есть одна задача.

Ещё в ответ на пожелания разных участников:

Насчёт статей — существует официальный журнал НПЦ АП, где есть и статьи по программированию БЦВМ (как можно понять из аннтаций — сам журнал не читал

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

О возможных удобствах других графовых представлений — в частности, Р-схем (говорилось здесь). Есть предложения по структурированию текста — скажем, проект PureBuilder. Мысли обоих авторов мне кажутся интересными. Да, был такой стандарт, где разные типы записи управляющих конструкций были систематизированы. М.б. кому-то незнаком и окажется полезным фрагментом данных.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, grosborn, Вы писали:

G>>Нет, ну совести совсем нет, зачем же так бессовестно вводить людей в заблуждение.

V>У тебя есть информация, подтверждающая твои инсинуации? Поделись.
Возможно, grosborn решил, что ВП говорил о применении ГРАФИТ-ФЛОКСа на самом космодроме в Куру? Там действительно использовалась другая система разработки — можно узнать из этой статьи. Хотя в ней подход тоже чем-то напомминает ГРАФИТ-ФЛОКС и ГРАФКОНТ. Да и цели такие же — обеспечить сопровождение продукции в течение всего жизненного цикла с максимальным качеством.
Но ведь Паронджанов-то явно перечислил все изделия, разрабатываемые по ГРАФИТ-ФЛОКС. В их числе и те, что запускаются с Куру — потому эта площадка и была упомянута. Или под "инсинуациями" имелось в виду что-то иное?..

Здравствуйте, VladZharinov, Вы писали:

VZ>Но ведь Паронджанов-то явно перечислил все изделия, разрабатываемые по ГРАФИТ-ФЛОКС. В их числе и те, что запускаются с Куру — потому эта площадка и была упомянута.
Странный подход, если это так. "Фрегат" там указан отдельно. Все же надеюсь НПЦАП делал что-то для союзовского старта в Куру. В остальном список Паронджанова похож на правду.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, VladZharinov, Вы писали:

VZ>Возможно, grosborn решил, что ВП говорил о применении ГРАФИТ-ФЛОКСа на самом космодроме в Куру? Там действительно использовалась другая система разработки — можно узнать из этой статьи.

Уважаемый Владислав!

В Вашем сообщении имеется неточность. Статья, на которую Вы ссылаетесь, посвящена ракете-носителю «Союз». И не более того.

Вы упустили из виду, что Союз выводит разгонный блок Фрегат-МТ. Технология разработки алгоритмов и программ Графит-Флокс используется при создании системы управления Фрегата, а не Союза.

Я указал космодром «Kuru» потому, что с этого космодрома выводится Фрегат. Очевидно, что разгонный блок Фрегат, не может взлететь сам по себе. С Земли стартует Союз, «на плечах» у которого сидит Фрегат. Маршевый двигатель Фрегата включается только после отделения от ракеты-носителя Союз.

Союз и Фрегат имеют разное наземное оборудование. Наземное оборудование СУ Фрегата называется «Наземный комплекс системы управления» Фрегата. В статье, на которую Вы ссылаетесь, об этом не говорится ни слова. Почему? Потому, что эта статья посвящена другой теме — не Фрегату, а Союзу.

ВЫВОД

Мои слова «Технология разработки алгоритмов и программ Графит-Флокс» успешно применяется при разработке системы управления разгонным блоком Фрегат (который запускается, в частности, с космодрома Kuru во Французской Гвиане) полностью соответствуют действительности.

ССЫЛКИ

Разгонный блок Фрегат
http://ru.wikipedia.org/w/index.php?title=%D0%A4%D1%80%D0%B5%D0%B3%D0%B0%D1%82_(%D1%80%D0%B0%D0%B7%D0%B3%D0%BE%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B1%D0%BB%D0%BE%D0%BA)&oldid=43343134

Куру (космодром)
http://ru.wikipedia.org/w/index.php?title=%D0%9A%D1%83%D1%80%D1%83_(%D0%BA%D0%BE%D1%81%D0%BC%D0%BE%D0%B4%D1%80%D0%BE%D0%BC)&oldid=45210343

В последней ссылке, в частности, говорится:

21 октября 2011 года Ракета-носитель «Союз-СТБ» вывела на орбиту два спутника для европейской спутниковой навигационной системы Galileo — «Тиис» и «Наталия». Два космических аппарата отделились от разгонного блока «Фрегат-МТ», и выведены на круговую околоземную орбиту высотой 23,2 тысячи километров и наклонением 54,7 градуса.

Поясняю. "Союз вывел два спутника" — это метафора. Ракета-носитель Союз выводит не спутники, а разгонный блок Фрегат. Полезным грузом Фрегата являются космические аппараты (в данном случае, спутники).

Лучше один раз увидеть ...

Посмотрите видео про Фрегат:
http://www.youtube.com/watch?v=EwZ180X4Cfs

VZ>Кстати, TAU тут зря грубили — он тоже работает над практическим программированием ответственных систем.

1. Тут TAU не грубили, он здесь и не появлялся, и не появится, потому что на вопросы отвечать не способен
2. Над чем он работает, мне плевать, потому что ни он, ни Тышов не смогли дать ответы ни на один из заданных вопросов

VZ>Где и верификация, и тестирование есть. В их системе подход немного другой, чем в ГРАФИТ-ФЛОКС — можно посмотреть на сайте.

Это неизвестно, есть там верификация, или нет, потому что описать что-либо они не в состоянии, а продираться через лес демагогии времени ни у кого нет.

VZ>Ещё в ответ на пожелания разных участников:

VZ>Насчёт статей — существует официальный журнал НПЦ АП, где есть и статьи по программированию БЦВМ (как можно понять из аннтаций — сам журнал не читал

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

Эти ссылки не отвечают ни на один из вопросов, связанных с программированием, и задаваемые тут. Как видно (см. ответы за 23.06) сам Паронджанов трусливо избегает любые ветки, где возникают конкретные вопросы.

Здравствуйте, Владимир Паронджанов, Вы писали:

Не нужно видео про Фрегат, с ним понятно. Для Куру вы наземку делали только для Фрегата, но это его неотемлимая часть. Надо полагать для Морского Старта тодько для ДМ, а для корейцев тоже в соответствующей части. Тогда выделение космодромов в Вашем списке действительно выглядит сомнительно.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, pagid, Вы писали:

P>Для Куру вы наземку делали только для Фрегата, но это его неотемлемая часть.

Да, это так. Но почему Вы говорите только о наземке?

Правильнее говорить о трех объектах, имеющих отношение к Технологии разработки алгоритмов и программ Графит-Флокс:

1. Бортовой компьютер Бисер-6.

2. Наземный компьютер Бисер-3.

3. Два персональных компьютера (для дублирования) с наглухо закрытой (для оператора) клавиатурой. Они входят в состав рабочего места оператора РМО.

P>... Тогда выделение космодромов в Вашем списке действительно выглядит сомнительно.

Не понял. Почему сомнительно? Ничего сомнительного в моем списке нет.

> Возможно, grosborn решил, что ВП говорил о применении ГРАФИТ-ФЛОКСа на самом космодроме в Куру? Там действительно использовалась другая система разработки — можно узнать из этой статьи.

Нет, мои претензии были другого плана. О демагогических приемах Паронджанова. Конкретно когда он частный второстепенные случаи упоминает как систему или когда использует его для приписывания себе чужих заслуг. Мы имеем некий инструмент, который используется в единичных случаях и косвенно использовался при создании каких-то элементов космической программы. Но Паронджанов пишет "Язык ДРАКОН успешно (никак не меньше — я УСПЕШНО забил гвоздь) используется во многих космических программах — космический центр Kuru". Там вообще хотя бы слышали о драконе?
Я вот никогда не позволял себе говорить что я "важный участник космической программы". мое участие косвенно.
Используя эти приемчики, можно ведь кого угодно посчитать "участником космической программы". Там в столовке чипсы продавались. Бразильская компания производитель чипсов участник космической программы? А работник смены оператор печки когда эти чипсы жарились? А бразильские сезонные рабочие которые картошку обрабатывали? А собачка котрая бежала мимо и немного задержалась на поле и удобряла посадки картофеля? А хозяин собачки, который ее пнул, иначе бы она туда не добежала? А его жена была причиной что он был дворник злой и пнул собачку. Она имеет право приписывать себе эту заслугу и неоднократное участие в разных космических программах?

Posted via RSDN NNTP Server 2.1 beta

СОВСЕМ ДРУГАЯ ТОЧКА ЗРЕНИЯ

предствлена на RSDN еще в 2008 году http://www.rsdn.ru/forum/philosophy/3104871.1.aspx

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

Делалось это усилиями коллектика центра автоматики и приборостроения им. академика Н. Пилюгина и ИПМ им. Келдыша.

В те годы шла активная разработка МКС "Буран" и по инициаливе Юрия Трунова совместно в ИПМ были созданы три языка ПРОЛ2, ДИПОЛЬ и ЛАКС (руководители проектов: Виктор Крюков, Владимир Луцикович и Константин Федоров соотв.).

Каждый язык использовался для своих задач и с другими не пересекался: ПРОЛ2 — для разработки бортовых комплексных программ Бурана , ДИПОЛЬ — для создания наземных программ Бурана и ЛАКС — для моделирования. Языки и инструменты были созданы, но возникли сложности с организацикй взаимодействия специалистов-прикладников и программистов.

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

Но Параджанов несколько пересмотрел условия задачи, т.к. понимал, что еще один новый язык проблемы не решит. Нужен был принципиально иной подход, который позволил бы совсем-не-программистам и совсем-уже-программистам разговаривать на одном языке, т.е. думать и решать задачи в схожих понятиях. По сути замахнулись на святое, на способ мышления, на то, что бы улучшить/изменить работу ума. И как ни странно это звучит, задача была решена. Был создан язык ДРАКОН, графический язык. Цель и задачи этого языка были:

1. Предложить эффективные средства для описания структуры человеческой деятельности.

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

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

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

5. Добиться кардинального улучшения качества программного обеспечения по критерию «понимаемость алгоритмов и программ».

ДРАКОН начал частично применяться в программе МКС "Буран". И имел успех, но поскольку проект уже близился к заверщению ДРАКОН не являлся основным языком и использовался в основном "на бумаге", т.е. как язык описания алгоритмов во время общения специалистов между собой. Но работы по автоматизации графического языка велись. К сожалению программа МКС "Буран" была в одночасье закрыта. ДРАКОН переживал не лучшие времена, в целом на его разработку ушло 15 лет, но возник и на драконьей улице праздник.

Этот праздник назывался проект Sea Launch. В проекте участвовали США, Норвегия, Россия и Украина. Пуски ракет производились с плавучей стартовой платформы, размещенной на экваторе в западной части Тихого океана в районе островов Кирибати. Управление пуском осуществлялось с находящегося поблизости сборочно-командного судна. Для каждого пуска стартовая платформа и сборочно-командное судно совершали морской рейс с базы, расположенной на западном побережье США, к островам Кирибати, а затем возвращались обратно. Результаты применения драконьей технологии оказались блестящими. Они превзошли все ожидания.

После этого драконья технология использовалась в российско-французском космическом проекте «Фрегат», а также при модернизации ракеты-носителя «Протон-М». Результаты были стабильно высокими и руководство Пилюгинского центра приняло решение использовать драконью технологию во всех последующих проектах.

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

Но бесспорен только один факт. ДРАКОН, как графический язык и как среда разработки, имел значительный успех в очень крупных проектах. Основываясь на примере ДРАКОНа я хочу поставить под сомнение утверждение некоторых коллег в этом форуме о том, что графические языки пригодны лишь для наглядного предствления простых задач...

С Уважением,
md034t

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Этот праздник назывался проект Sea Launch. В проекте участвовали США, Норвегия, Россия и Украина. Пуски ракет производились с плавучей стартовой платформы, размещенной на экваторе в западной части Тихого океана в районе островов Кирибати. Управление пуском осуществлялось с находящегося поблизости сборочно-командного судна. Для каждого пуска стартовая платформа и сборочно-командное судно совершали морской рейс с базы, расположенной на западном побережье США, к островам Кирибати, а затем возвращались обратно. Результаты применения драконьей технологии оказались блестящими. Они превзошли все ожидания.

Использовался ли Дракон в проекте Sea Launch для СУ ДМ-SL или для чго-то еще?

ВП>После этого драконья технология использовалась в российско-французском космическом проекте «Фрегат»
Какое отношение французы имеют к "Фрегату" кроме того, что "Фрегат" в составе "Союза" используется с Куру?

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, grosborn, Вы писали:

>> Возможно, grosborn решил, что ВП говорил о применении ГРАФИТ-ФЛОКСа на самом космодроме в Куру? Там действительно использовалась другая система разработки — можно узнать из этой статьи.

G>Нет, мои претензии были другого плана.
...
... имеет право приписывать себе эту заслугу и неоднократное участие в разных космических программах?

А, понял. Т.е., что непосредственно в критикуемом посте вот это:

ВП> ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

ВП>Язык ДРАКОН успешно используется во многих космических программах:

ВП>{• <имя-изделия>[(имя-проекта)]}

ВП>Космодромы:

ВП>{название-космодрома}

— следовало бы изложить более развёрнуто — как в этом посте:

ВП>Мои слова «Технология разработки алгоритмов и программ Графит-Флокс» успешно применяется при разработке системы управления разгонным блоком Фрегат (который запускается, в частности, с космодрома Kuru во Французской Гвиане) полностью соответствуют действительности.

Т.е. что с таких-то площадок по таким-то проектам запускаются изделия, где применяется ГРАФИТ-ФЛОКС либо в целом (как можно понять — из уже эксплуатируемых это "Протон"), либо в таком-то субизделии (в данном случае — РБ как части носителя). А изложенное так, как выше, Вы считаете, можно понимать так, что ГРАФИТ-ФЛОКС применяется в целом на проекте и/или площадке? Возможно, Вы и правы...

Насчёт заслуг — от надёжности даже и РБ вообще-то зависит успех всего запуска. Так что раз работает — значит, имеет. Вы согласны? О кратности — вроде как запусков с применением перечисленных изделий было уже немало. Паронджанов в своё время перечислял (не знаю, все ли на ту дату).

Насчёт того, что человек активно пропагандирует что-то — само по себе это ведь не значит, что он обязательно искажает факты и/или делает неверные выводы? Даже если в его обращениях присутствуют элементы, как Вы говорите, "демагогии" (спецпропаганды)?..

Посмотреть бы на всю клавиатуру, интересно, какая была фантазия в те годы

Спасибо за ссылку, весьма полезно, всплыли многие "недокументированные" фичи, как именование дуг и переходы на них, спецвершины, комментарии и пр. Прикольно то, что я как только увидел Р-графы, то сразу въехал, что так можно "зарисовать" даже Хаскель, а также Р-схемы по духу очень похоже на диаграммы Ганта, диаграммы связей (всякие Mind Map) и пр. А эта статья показала саму сущность — оказывается, что специально задумано так, чтобы всё было в одном стиле: и схемы алгоритмов, и всякие диаграммы/графики, и схемы/таблицы данных, документация и т.д. При этом всё можно держать в текстовом виде. И "запрограмлять" можно всё, вплоть до Пролога.
В общем, пока впечатляет. По возможности опробую Р-схемы на юзерах, которые не связаны с программированием, имхо, надеюсь, что будет проще, чем с Драконом.

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

Здравствуйте, VladZharinov, Вы писали:

PSV>>Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...

VZ>Такое, IMHO, возможно — говорил здесь применительно к похожей среде — Скретчу. Как ещё это можно развить — на этой странице. Конструктивная критика приветствуется.

К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют. Лично я под симбиозом графа ДРАКОН-а и пазлов подразумеваю лишь техническую "улучшалку" условного ДРАКОН-редактора: вместо вставки в блоках непосредственно текста , описывающего действия, можно "лепить" пазлы (там, где это уместно, и эти "пазлы" не должны указывать на блок "if", "for" и т.п., т.е. только пазл-действия или определения).

А по поводу конструктивной критики развития и улучшения ДРАКОН-а могу сказать следующее. Я не активный пользователь ДРАКОН-а, использую его только для документации, причём, прежде всего, для лиц-непрограммистов. Поэтому могу дать небольшую оценку с этой стороны.

— язык ДРАКОН, как графический язык блок-схем, оказался лучше для восприятия, чем описание алгоритмов на условном программном псевдо-языке, пусть даже с русскими словами (что-то похожее на язык 1C). Среди всяких вариантов рисования блок-схем ДРАКОН оказался самым приятным.
Кстати, и среди программистов текстовый псевдо-язык тоже не приятен, особенно когда все могут общаться на нормальном реальном языке программирования.

— "рядовых" пользователей наличие разных типов блоков (квадратики, ромбики, ввод/вывод, переход и т.д.) реально "напрягает" — им не нужны "сложности", всё должно быть максимально просто. Их интересует только то, какие выполняются действия, их последовательность, "развилки" и циклы (и чтобы их было поменьше). Поэтому у нас ДРАКОН был максимально упрощён: везде используются только квадратики (точнее прямоугольники), включая и развилки (всё понятно по тексту внутри блока и наличию двух выходящих линий), и циклы "for" (весь цикл по возможности описывается в одном блоке или начало и конец цикла рисуются линией, чуть жирнее остальных), также квадратиками, с чуть жирнее линиями, рисуются и переходы на другие шампура , и часто все "обламываются" их рисовать, если логически есть только один последовательный переход на соседний шампур. Фактически используется псевдо-Дракон, непригодный для машинной обработки. Существенной виной этому является неудобство работы в графических редакторах, поэтому проще/лучше рисовать вручную, да и не заставишь рядовых пользователей осваивать ещё одну программу для создания схем (иногда требуется и им рисовать, при этом это их не основная профессиональная деятельность).

Таким образом, я ничего не могу сказать о профессиональном инженерном программировании на ДРАКОНе (т.к. нет реальной практики), но для случаев "рядовой" демонстрации "дружественности" и "наглядности" алгоритмов ДРАКОН, имхо, нуждается в некотором упрощении.
Кстати, в представленной статье о "Дейкстрале" я тоже вижу некую попытку небольшого упрощения работы с ДРАКОНом (в том числе).

Скорее всего, блок-схемы, как таковые, плохо "упрощаются". Вот сейчас в немного обсуждаемой рядом Р-технологии лично я для себя вижу более привлекательные подходы в графическом представлении алгоритмов (и не только), чем в блок-схемах, включая и ДРАКОН.

Здравствуйте, PSV100, Вы писали:

PSV>Имхо, отсутствие "жж-ж-ж" по этому поводу не просто так...
Причина может быть, например, в том, что Р-технология развивалась и использовалась на Украине.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

Здравствуйте, Владимир Паронджанов,

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

респект и уважуха

PSV>К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют.

А там и не стоит появляться. Сначала там в подробностях разберут твою личность[1], потом будут вопрошать «а кто ты такой», потом модератор потрет самые яркие высказывания «уважаемых участников» (чтобы не портить им карму), тему закроют, а тебя забанят якобы за неоднократное нарушение правил.

[1] Например: Некто Тышов, типа гуру, нашел мое стихотворение восьмилетней давности про флуд, нашел потом его на моем сайте, связал это с мои ником на форуме оберонкор, полностью процитировал это стихотворение и спросил: «вы сюда поразвлекаться пришли»? Ни одного ответа ни на один вопрос он так и не предоставил, продолжая выяснять, где я живу, какие сайты я веду и т.п. Лезть в этот застарелый адъ почти поголовно страдающих завышенным ЧСВ маразматиков не советую.

Здравствуйте, BrainSlug, Вы писали:

BS>все таки повторю свое мнение, — в данном случае Дракон никакой не язык.
...........................................................................
BS> Представляется мне для обучения такие вещи удобны, для повседневной жизни, вряд ли.

Уважаемый BrainSlug!

ДРАКОН ориентирован в значительной мере на непрограммистов. Для них вопрос "язык или не язык" не интересен.
Поясню.

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

"День добрый! Я Вас не забыла.

Я сейчас пишу алгоритм составления ассортиментной матрицы для отдела маркетинга оптовой фирмы.

Пока хочу сказать, что чем дальше влезаю в Дракон, тем больше убеждаюсь, что этот язык вовсе не для домохозяек.

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

Тут крайности какие то прослеживаются — то язык программирования "для бурана", то "для домохозяек"...
Надо бы ему другое позиционирование сформулировать....

Я подумаю.

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

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

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

Как допишу — поделюсь схемой."

Моя страница в Фейсбуке называется Язык для "домохозяек" ДРАКОН
http://e.mail.ru/cgi-bin/msglist#readmsg?id=13404680040000000857&folder=0

Здравствуйте, PSV100, Вы писали:

PSV>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание.

Спасибо за ссылку. Я обратил внимание на это:

Один из разработчиков языка Нил Фрейзер (Neil Fraser) так описывает цели создания языка: ”Эта концепция прошла очень длинный путь, от Ассемблера к Фортрану, затем к C++ и к Python, и наконец, это Blockly. Это попытка подняться на ещё более высокий уровень абстракции, чтобы лишить программирование кастовости и закрытости, сделать его более естественным и доступным для как можно более широкого круга лиц”.

Точнее, я обратил внимание не на весь этот отрывок, а только на вторую фразу:

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

Я готов подписаться под каждым словом Нила Фрейзера. Потому что:

1. ДРАКОН — это попытка лишить программирование кастовости.

2. ДРАКОН — это попытка лишить программирование закрытости.

3. ДРАКОН — это попытка сделать алгоритмизацию (а иногда и программирование) естественными и доступными для как можно более широкого круга лиц.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Точнее, я обратил внимание не на весь этот отрывок, а только на вторую фразу:

ВП>

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

ВП>Я готов подписаться под каждым словом Нила Фрейзера. Потому что:

ВП>1. ДРАКОН — это попытка лишить программирование кастовости.

ВП>2. ДРАКОН — это попытка лишить программирование закрытости.

ВП>3. ДРАКОН — это попытка сделать алгоритмизацию (а иногда и программирование) естественными и доступными для как можно более широкого круга лиц.

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

Пользуясь случаем, хочу сказать спасибо за ДРАКОН, это хорошее средство для употребления блок-схем.

И попутный вопросик по поводу обсуждаемой рядом Р-технологии. Я позволю себе предположить, что Вам она вполне знакома. Каково Ваше мнение/отношение/критика ?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Я готов подписаться под каждым словом Нила Фрейзера. Потому что:

ВП>1. ДРАКОН — это попытка лишить программирование кастовости.

ВП>2. ДРАКОН — это попытка лишить программирование закрытости.

ВП>3. ДРАКОН — это попытка сделать алгоритмизацию (а иногда и программирование) естественными и доступными для как можно более широкого круга лиц.

Алгоритмы и Паскаль дают школьникам в 9м классе. Какая уж тут кастовость, закрытость и недоступность?
http://www.5byte.ru/9/

Здравствуйте, samius, Вы писали:

S>Алгоритмы и Паскаль дают школьникам в 9м классе. Какая уж тут кастовость, закрытость и недоступность?
S>http://www.5byte.ru/9/
А сколько процентов школьников это осиливают хотя б на 3 объективные балла? Максимум 5 процентов.

http://www.rsdn.ru/forum/philosophy/4794964.flat.aspx#4794964

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, samius, Вы писали:

S>>Алгоритмы и Паскаль дают школьникам в 9м классе. Какая уж тут кастовость, закрытость и недоступность?
S>>http://www.5byte.ru/9/
E>А сколько процентов школьников это осиливают хотя б на 3 объективные балла? Максимум 5 процентов.

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

Предлагаю провести мысленный экспримент. Заменим блок-схемы на Дракон. Сильно ли вырастет процент осиливших программу по информатике за 9-ый класс на объективные 3 балла?
Уверен, что он едва ли всколыхнется.

Но я таки опровергал тезис о кастовости, закрытости и недоступности. То что алгоритмы и Паскаль дают ВСЕМ в 9м классе, по моему, свидетельствует об открытости, доступности и отсутствии каких-либо каст. А то что от учеников информатику не требуют так же как математику — так это другими словами называется.

Здравствуйте, PSV100, Вы писали:

PSV>Здравствуйте, VladZharinov, Вы писали:

PSV>>>Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...

VZ>>Такое, IMHO, возможно — говорил здесь применительно к похожей среде — Скретчу. Как ещё это можно развить — на этой странице. Конструктивная критика приветствуется.

PSV>К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют. Лично я под симбиозом графа ДРАКОН-а и пазлов подразумеваю лишь техническую "улучшалку" условного ДРАКОН-редактора: вместо вставки в блоках непосредственно текста , описывающего действия, можно "лепить" пазлы (там, где это уместно, и эти "пазлы" не должны указывать на блок "if", "for" и т.п., т.е. только пазл-действия или определения).
Как я понял, речь из перечисленного мной идёт об одном посте (связанном по ссылке). Там, в сущности, развита та же идея об "улучшении" редактора, исчисляющего графы. За счёт эквивалентного изображения кроссов (и схем и составных атомов) и простых атомов как скретч-пазлов. Остальные посты в открытых темах и регистрации не требуют. Как я понял, Вы уже и зарегились на Оберонкоре, так что вроде как можете всё читать (если нет, можно перепостить сюда что-то, но не всем, наверное, стоит наполнять форум

?..

Да, в отношении замечания Mamut по источникам — что имеет отношение и к Вашему интересу к сравнениям. В общем он прав — то, что сейчас представлено, в основном: 1) содержит лишь упоминания техноязыка; и/или 2) почти или совсем не даёт материал для ответов на те именно вопросы, которые он поставил. Но. Некоторые исключения, IMHO, имеются. Думаю, это: 1) доклад, где как раз приложение шампур-схем к потокам управления разбирается; 2) книга, где именно есть сравнение разных графических нотаций для программирования УВК реального времени.
О некоторых других Ваших мыслях в новой теме, т.к. они туда и относятся больше.

Здравствуйте, PSV100, Вы писали:

PSV>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание.

Источником вдохновения для Blockly послужил похожий проект AppInventor, изначально развиваемый для платформы Android

Видел видео аппинвентора с их сайта, просто тупо передрали блоки и переделали немножко их форму, и оппа, новый язык!

Уважаемые коллеги!

Рекомендую познакомиться с этой дискуссией:

Visual programming for serious software

Are visual program control flow diagrams and languages which support that used for larger serious programs? Why not? They seem like a nice overview of the code.

In the thread What software programming languages were used by the Soviet Union's space program? a visual language is mentioned (Drakon) and I wondered why such approaches aren't used more often?

Is there nothing a visual control flow representation (I don't mean class diagrams etc.) which are 1-to-1 with code can help compared to typing in letters in an editor?

И далее:
http://programmers.stackexchange.com/questions/152313/visual-programming-for-serious-software

Здравствуйте, VladZharinov, Вы писали:

VZ>Как я понял, речь из перечисленного мной идёт об одном посте (связанном по ссылке). Там, в сущности, развита та же идея об "улучшении" редактора, исчисляющего графы. За счёт эквивалентного изображения кроссов (и схем и составных атомов) и простых атомов как скретч-пазлов. Остальные посты в открытых темах и регистрации не требуют. Как я понял, Вы уже и зарегились на Оберонкоре, так что вроде как можете всё читать (если нет, можно перепостить сюда что-то, но не всем, наверное, стоит наполнять форум

?..

VZ>Да, в отношении [...]

Да, я не мог просмотреть все темы на Оберонкоре, но уже всё доступно. И прочитал также указанные статьи. Спасибо.

http://www.rsdn.ru/forum/philosophy/4797675.flat.aspx#4797675

Здравствуйте, xvost, Вы писали:

X>До тех пор пока графы и диаграммы помогают понять код — "you'r welcome"!
X>Как только пытаются в эти графы запихать ВСЮ программу,и обязать ее модифицировать тоже через графическое представление — fail.

Вообще-то не fail. В телекоме в SDL давно уже многое запихивали и вполне успешно. Другое дело, что чисто графического представления не бывает. Оно всегда смешивается с текстом.

Здравствуйте, Mamut, Вы писали:

M>Вот по этой ссылке: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184&start=40

M>5 страниц (!) обсуждения того, что делать с простейшим алгоритмом. Он, видите ли, не укладывается в схему. Самый сок с примерами — на второй странице. Например: http://forum.oberoncore.ru/viewtopic.php?f=78&t=3184&start=20#p60536

Я когда-то приводил похожий пример для структурного программирования с просьбой обойтись без goto:

Никто так и не смог обойтись. Потому что речь явно идет о детерминированном автомате, поэтому такой алгоритм надо тупо делить на состояния и делать один короткий, но широкий цикл, в начале которого будет один большой switch (или аналогичный переход по таблице переходов автомата). По ссылке примерно так и предложили. Это решение пойдет для любого структурного ЯП, не только ДРАКОНа.

Здравствуйте, PSV100, Вы писали:

PSV>Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...

Я вижу, что эти пазлы точно так же умеют расти только вправо и вниз. Пересечения — невозможны.

Здравствуйте, vdimas, Вы писали:

V>Я когда-то приводил похожий пример для структурного программирования с просьбой обойтись без goto:
V>

V>Никто так и не смог обойтись.
Теорема Бома-Якопини: можно без goto.
Пример: общий цикл с if-ами, в которых идет проверка переменной go_label. Т.е. статические метки заменяются динамическими проверками. Не айс, но формально оператор goto отсутствует. Код писать лениво.

Здравствуйте, samius, Вы писали:

V>>Никто так и не смог обойтись.
S>Теорема Бома-Якопини: можно без goto.
S>Пример: общий цикл с if-ами, в которых идет проверка переменной go_label.

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

Предложенный мною switch/case для атоматной модели тоже ничем от goto не отличается.

Даже выражения под case так и названы — метки.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Никто так и не смог обойтись.
S>>Теорема Бома-Якопини: можно без goto.
S>>Пример: общий цикл с if-ами, в которых идет проверка переменной go_label.

V>Это и есть эмуляция goto. Мы в любом случае пропускаем код до нужной метки, только делаем это не за один такт, а за много.

V>Предложенный мною switch/case для атоматной модели тоже ничем от goto не отличается.

V>Даже выражения под case так и названы — метки.

Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).

Так без чего надо было обойтись?

Здравствуйте, samius, Вы писали:

V>>Предложенный мною switch/case для атоматной модели тоже ничем от goto не отличается.

V>>Даже выражения под case так и названы — метки.

S>Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).

S>Так без чего надо было обойтись?

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

Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).

S>>Так без чего надо было обойтись?

V>См. на что я отвечал. Обойтись надо без пересечения стрелок-переходов. ИМХО, такие пересечения возможны только на goto. Ну или его равнозначной эмуляции (то бишь за счет некоторой избыточности, касающейся механики эмуляции goto, но не касающейся алгоритма).
Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto. В том что пересечения возможны лишь на goto — тут я вроде согласен. Но раз так, то из того что любое вычисление можно записать без goto, следует что любую схему можно изобразить без пересечений.

V>Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.

Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.

V>=======================
V>И да, всякие парсеропостроители используют goto в генеренном коде аж бегом. Именно как самый локаничный способ выразить схемы, наподобие нарисованных.
дык мы же не об этом. Мы о том что на оберонкоре 5 страниц обсуждений как избавиться от пересечений. Конечно, я их не читал.

Здравствуйте, samius, Вы писали:

S>>>Естественно, что без оператора goto обойтись можно, но не без ветвления с неявными переходами между ветками. При формулировке задачи "обойтись без goto" (1) она решается. При формулировке "обойтись без goto и его эмуляции" (2) — нет. Т.к. switch/case ничем не отличается от goto, то во второй формулировке даже решение с его помощью не удовлетворяет формулировке (2).

S>>>Так без чего надо было обойтись?

V>>См. на что я отвечал. Обойтись надо без пересечения стрелок-переходов. ИМХО, такие пересечения возможны только на goto. Ну или его равнозначной эмуляции (то бишь за счет некоторой избыточности, касающейся механики эмуляции goto, но не касающейся алгоритма).
S>Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto.

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

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

S>В том что пересечения возможны лишь на goto — тут я вроде согласен. Но раз так, то из того что любое вычисление можно записать без goto, следует что любую схему можно изобразить без пересечений.

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

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

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

Мои поздравления, цель достигнута!

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

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

V>>Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.

S>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.

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

V>>И да, всякие парсеропостроители используют goto в генеренном коде аж бегом. Именно как самый локаничный способ выразить схемы, наподобие нарисованных.
S>дык мы же не об этом. Мы о том что на оберонкоре 5 страниц обсуждений как избавиться от пересечений. Конечно, я их не читал.

Ну дык, Оберон — это вообще международный слет фанатов структурного программирования. Они же за goto зарежут. ))))

V>>Лично я ничего зазорного в графе переходов автомата вида "многие-ко-многим" не вижу, просто это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.

S>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.

Ключевой момент: не тривиально, и конечный результат может оказаться кашей по сравнению с вариантом с пересечениями.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto.

V>Вообще-то ровно наоборот. При табличной эмуляции работы автомата через цикл, вот этот цикл и есть точка пересечения ВСЕХ стрелок.
Не пересечения, а схождения. Иначе придется признать что в исходной схеме кроме явных пересечений стрелок есть еще T-образные пересечения на местах схождения стрелок на входе в блок (если считать что вход в блок лишь один). Любой цикл образует такое пересечение. Я думал что обсуждаются другие пересечения, именно X-образные а не T-образные.

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

V>Это лишь один из способов эмуляции ДКА, когда мы состояние автомата переносим в данные. То бишь осуществляется преобразование кода в данные и затем по этим данным работает дополнительный софтовый уровень — интерпретатор этих данных. По отношению к варианту на железе это уже будет целых два уровня программного исполнения, а не один. Я уже молчу о том, что целевой алгоритм на этом уровне теряется полностью и привести в соответствие одно к другому можно только через дополнительные артефакты — графы переходов автомата и полученной из него таблицы переходов... Почему бы такой артефакт не "нарисовать" прямо в программе?
Почему — это другой вопрос. Мы обсуждаем не его.

S>>В том что пересечения возможны лишь на goto — тут я вроде согласен. Но раз так, то из того что любое вычисление можно записать без goto, следует что любую схему можно изобразить без пересечений.

V>Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя.
Как ни крути, от T-образных не избавиться.

V>Попробую объяснить суть всех твоих приемов. (Все предложенные тобой и мной приёмы абсолютно идентичны, даже если упоминались разные операторы языка для их воплощения.)

V>Как работает центральный процесор? Он выполняет некий код. Сам цикл работы центрального процессора не содержит никаких пересечений, ес-но, там идет диспетчеризация по коду команд, которую можно отобразить в блок-схемах без каких-либо пересечений. Однако же, этот процессор способен исполнять алгоритмы, в которых эти пересечения есть (см блок-сцему исходного алгоритма). Ты предлагаешь избавляться от пересечений точно по такому же принципу — превращая код этого агоритма (его поток исполнения) в данные, кодируя разные точки алгоритма через искуственно-вводимые состояния автомата. То бишь имеем дополнительный софтовый уровень: свою "систему команд", свой интерпретатор и на этом уровне получаем аналог центрального процессора, только эмулируемый. И на этом уровне пересечений уже нет, ес-но, как нет в алгоритме работы центрального процессора.
Опять таки, причем тут уровень процессора?!?!? Все равно что рассуждать об иммутабельности кода по исполнителю уровня процессора, регистров и стека. Мы это уже проходили. В структурном программировании мы оперируем в терминах языка, на котором пишем.

V>Мои поздравления, цель достигнута!

V>Но целевой автоматически алгоритм переползает на один уровень вверх, и на этом уровне все пересечения стрелок останутся. См. упомянутый артефакт — граф переходов. Он никуда не делся. Ты опять можешь "закинуть невод", т.е. опять попытаться избавиться от пересечений на этом новом уровне... и опять получишь тот же самый эффект, потому что сделаешь это через очередной слой интерпретации данных и т.д. до бесконечности.
От X-образных пересечений я избавился с первого раза. А от T-образных и не собирался.

V>В чистом виде описанный подход не факт что можно распознать, т.к. народ подвергает такому преобразованию довольно-таки "локальные" места (чаще всего интуитивно, не отдавая себе отчета, что при этом происходит). Но суть этих преобразований надо понимать, чтобы быстро "воткнуть" в целевой алгоритм, глядя на цепочку ветвлений по исскуственно-введенным флагам в чужом коде. Мне порой подобный код-ревью доставляет массу фана, надо признать. )))
Обычно не стремлюсь заменять флаги на goto.

S>>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.

V>Суть этого преобразования я показал. И оно тривиально, это преобразование. (Для тех, кто имеет представление о принципах работы процессоров, т.е. фактически для всех коллег. )

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

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

V>Ну дык, Оберон — это вообще международный слет фанатов структурного программирования. Они же за goto зарежут. ))))
А, ну тогда ничего удивительного в 5и страницах нет.

Здравствуйте, Mamut, Вы писали:

S>>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.

M>Ключевой момент: не тривиально, и конечный результат может оказаться кашей по сравнению с вариантом с пересечениями.
Я не настаиваю на таком преобразовании.

Здравствуйте, vdimas, Вы писали:

V>Ну дык, Оберон — это вообще международный слет фанатов структурного программирования. Они же за goto зарежут. ))))

Концепция ДРАКОНа отличается от концепции Оберона.
Поясню:

Гибридные языки ДРАКОН-семейства и оператор GOTO

Чтобы глубже понять роль оператора GOTO, можно выделить два этапа в истории развития языков программирования.

На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня»[28] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.

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

При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать.[29]

Подобная эмуляция оператора GOTO вносит мелкие неоправданные сложности. Эти сложности сразу исчезают, если в целевом языке есть оператор GOTO. Следовательно, с точки зрения языка ДРАКОН, было бы лучше, если бы в целевом языке был предусмотрен оператор GOTO.

Оператор GOTO нежелательно использовать именно в текстовых языках, так как контроль за соблюдением структурности программы остается за исполнителем (программистом). В языке ДРАКОН есть свои собственные правила, позволяющие сохранять структурность.[30]

Отсюда следует предположительный вывод. Если гибридные языки ДРАКОН-семейства (по сравнению с языками высокого уровня) ощутимо повысят производительность труда программистов и со временем получат широкое распространение, это может послужить достаточным основанием, чтобы судьба оператора GOTO снова круто изменилась. Это значит, что в языки высокого уровня, по-видимому, снова будет введен некогда изгнанный оттуда оператор GOTO.

При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме.

В свою очередь, дракон-схема имеет надежную защиту от подобных неприятностей благодаря использованию ДВУМЕРНОГО структурного программирования. Принципы двумерного структурного программирования подробно описаны в литературе.[31][32][4]

Эта цитата взята из статьи ДРАКОН в Википедии

http://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D_(%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA)#.D0.93.D0.B8.D0.B1.D1.80.D0.B8.D0.B4.D0.BD.D1.8B.D0.B5_.D1.8F.D0.B7.D1.8B.D0.BA.D0.B8_.D0.94.D0.A0.D0.90.D0.9A.D0.9E.D0.9D-.D1.81.D0.B5.D0.BC.D0.B5.D0.B9.D1.81.D1.82.D0.B2.D0.B0_.D0.B8_.D0.BE.D0.BF.D0.B5.D1.80.D0.B0.D1.82.D0.BE.D1.80_GOTO

Здравствуйте, samius, Вы писали:

V>>Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя.
S>Как ни крути, от T-образных не избавиться.

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

V>>Попробую объяснить суть всех твоих приемов. (Все предложенные тобой и мной приёмы абсолютно идентичны, даже если упоминались разные операторы языка для их воплощения.)

V>>Как работает центральный процесор? Он выполняет некий код. Сам цикл работы центрального процессора не содержит никаких пересечений, ес-но, там идет диспетчеризация по коду команд, которую можно отобразить в блок-схемах без каких-либо пересечений. Однако же, этот процессор способен исполнять алгоритмы, в которых эти пересечения есть (см блок-сцему исходного алгоритма). Ты предлагаешь избавляться от пересечений точно по такому же принципу — превращая код этого агоритма (его поток исполнения) в данные, кодируя разные точки алгоритма через искуственно-вводимые состояния автомата. То бишь имеем дополнительный софтовый уровень: свою "систему команд", свой интерпретатор и на этом уровне получаем аналог центрального процессора, только эмулируемый. И на этом уровне пересечений уже нет, ес-но, как нет в алгоритме работы центрального процессора.

S>Опять таки, причем тут уровень процессора?!?!?

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

S>Все равно что рассуждать об иммутабельности кода по исполнителю уровня процессора, регистров и стека. Мы это уже проходили.

Нет, это не тоже самое. Ты не вник в мой пример, к сожалению. В случае иммутабельности и прочей высокоуровневой мишуры целевую механику обеспечивает компилятор автоматически,но в случае предложенного тобой способа ухода от вынужденных goto придется ВРУЧНУЮ нарисовать схему, аналогичную работе центрального процессора.

Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. )))

S>В структурном программировании мы оперируем в терминах языка, на котором пишем.

Речь шла о задаче и тобой было предложено вместо решения целевой задачи построить эмулятор автомата и решить уже эту задачу на эмуляторе. Тут уже конкретный язык не важен, лишь бы позволял эмулировать работу автомата. А зачем вообще автомат? Ах да, он же позволяет скакать по состояниям произвольно, в отличие от "структурного программирования"... Вот он и скачет по исходных стрелкам с пересечениями.

V>>Но целевой автоматически алгоритм переползает на один уровень вверх, и на этом уровне все пересечения стрелок останутся. См. упомянутый артефакт — граф переходов. Он никуда не делся. Ты опять можешь "закинуть невод", т.е. опять попытаться избавиться от пересечений на этом новом уровне... и опять получишь тот же самый эффект, потому что сделаешь это через очередной слой интерпретации данных и т.д. до бесконечности.
S>От X-образных пересечений я избавился с первого раза. А от T-образных и не собирался.

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

V>>В чистом виде описанный подход не факт что можно распознать, т.к. народ подвергает такому преобразованию довольно-таки "локальные" места (чаще всего интуитивно, не отдавая себе отчета, что при этом происходит). Но суть этих преобразований надо понимать, чтобы быстро "воткнуть" в целевой алгоритм, глядя на цепочку ветвлений по исскуственно-введенным флагам в чужом коде. Мне порой подобный код-ревью доставляет массу фана, надо признать. )))
S>Обычно не стремлюсь заменять флаги на goto.

Дык, у тебя просто выработанная привычка к мышлению в стиле структурного программирования. То бишь вместо того, чтобы шаги алгоритма получались как естественное положение указателя команд, ты эти шаги кодируешь в данных в некое т.н. "состояние". Я не спорю, эта техника хороша... Особенно в событийном/асинхронном программировании — там и вариантов-то нет... Но не факт, что это так же хорошо в синхронном алгоритме, или где допустимо ожидать события по технике poll. Признаюсь, мне все эти вещи немного до фени, т.е. у меня особой любимой техники и стиля нет (и комлпексов по этому факту тоже), мне "структурность" или "функциональность" — как пустой звук, потому что это слишком уж грубые обобщения, которые не натягиваются задёшево на все случаи жизни. В реальности есть алгоритмы (иногда они даны сверху) и удобные модели для их решения. В технике получения событий poll и при наличии механизма исключений приведенный способ на блок-схеме был самый дешевый (это было описание шагов кое-какого протокола без именований и блоков м/у ветвлениями).

S>>>Что значит не ложится в структурное программирование? По теореме Б-Я ложится все что может быть выполнено. Естественно, что не тривиально, но преобразование существует.

V>>Суть этого преобразования я показал. И оно тривиально, это преобразование. (Для тех, кто имеет представление о принципах работы процессоров, т.е. фактически для всех коллег. )

S>Только вот мы не можем сойтись по поводу исчезновения пересечений.

Почему не можем? Перенаправляем все линии в один блок — интерпретатор состояний, а тот уже каждую линию доведет до места. Конечный адрес каждого перехода теперь закодирован не в коде, а в данных. Согласно моему ИМХО такой интерпретатор состояний — это прозрачный механизм, т.е. на самом деле входящая в него линия уже заранее знает, в какую конечную точку она попадет (это верно для детерминированных автоматов), ведь перед возвратом на начало цикла предыдущий цикл должен изменить состояние, т.е. "заказать" себе услугу перехода в нужную ему точку... коль мы явно запретили ему переходить куда ему надо по goto... В общем, теперь вместо того, чтобы алгоритму переходить куда ему надо самостоятельно, мы используем посредника со всеми накладными расходами, ес-но.

S>Если ты считаешь что пересечения никуда не делись, то какой смысл в преобразовании?

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

Здравствуйте, vdimas, Вы писали:

V>это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.

Ваши слова справедливы только как грубое приближение.
Суть в том, что НЕЛЬЗЯ отождествлять правила ДРАКОНа и правила (традиционного) структурного програмирования.
Между ними есть тонкое, но ОЧЕНЬ ВАЖНОЕ различие.

Графические правила ДРАКОНа являются не тождественным повторением правил традиционного (текстового) структурного программирования, а РАЗВИТИЕМ. Причем это развитие позволяет получить НОВОЕ КАЧЕСТВО, новые мощные выразительные средства.

Пояснения представлены ниже.
Мне кажется, сначала следует прочитать
Часть VII, а затем Часть VI .

Часть. Конструктор алгоритмов и формальное
описание языка .............................................393

Глава 32. Конструктор алгоритмов (помощник человека) ...................395

Глава 33. Графический синтаксис языка ДРАКОН ................................416
http://drakon.su/_media/biblioteka/chast_6._393-424_konstruktor_algoritmov_i_formalnoe_opisanie.pdf

Часть VII. Теоретические основы языка ДРАКОН ............425

Глава 34. Исчисление икон ..............................................................................427

Глава 35. Метод Ашкрофта-Манны и алгоритмическая
структура «силуэт» ..........................................................................436

Глава 36. Визуальный структурный подход к алгоритмам
и программам (шампур-метод) ...................................................449

http://drakon.su/_media/biblioteka/chast_7._425-472_teoreticheskie_osnovy_jazyka_drakon.pdf

Здравствуйте, PSV100, Вы писали:

PSV>К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют.
Оберонкоре — это собрание неграмотных фриков, у половины из которых идеология: "да я 40 лет крутил этот болт ключом на 15!" Ещё там есть несколько невинных жертв этих фриков, которые пытаются что-то делать с использованием технологий, которые им навязали.

О современном состоянии в разработке ПО там и близко не знают.

Здравствуйте, Владимир Паронджанов, Вы писали:

V>>это не ложится на обычное структурное программирование и не ложится на правила ДРАКОНа, которые, как я вижу, в графическом виде описывают правила структурного программирования.
ВП>Графические правила ДРАКОНа являются не тождественным повторением правил традиционного (текстового) структурного программирования, а РАЗВИТИЕМ.

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

Здравствуйте, vdimas, Вы писали:

V>Коль структурное программирование — это система ограничений на конструкции программы, то развитие структурного программирования может быть только в сторону усилениятрансляци ограничений. В общем, хотел сказать, что если некий кусок кода нарушает ограничения структурного программирования, то он нарушает ограничения ДРАКОНа и подавно.

Не согласен.

V>развитие структурного программирования может быть только в сторону усиления ограничений.

Это неверно. ДРАКОН снимает часть ограничений. То есть развитие идет не в сторону усиления ограничений,
а в сторону снятия части ограничений

Вы исходите из того, что кусок кода первичен, а дракон-схема вторична.

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

Здравствуйте, vdimas, Вы писали:

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

Это не так. См. пример на стр. 456.
На рис. 259 — классическое структурное программирование.
На рис. 260 — НЕклассическое структурное программирование, принятое в ДРАКОНе.
http://drakon.su/_media/biblioteka/chast_7._425-472_teoreticheskie_osnovy_jazyka_drakon.pdf

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Если исходный граф переходов нельзя "повернуть" так, чтобы избавиться от пересечений, то, увы, нельзя.
S>>Как ни крути, от T-образных не избавиться.

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

Тогда непонятно, почему таки стрелки пересекутся при наличии цикла

S>Запись циклом с ветвлением получитеся без пересечения стрелок, хотя она является эмуляцией goto.

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

Так все-таки, направленные в одно место стрелки пересекаются или нет? Если нет, то цикл не организует пересечений.

S>>Опять таки, причем тут уровень процессора?!?!?

V>Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных.
Странно, но я понимаю, что я предложил. Я не понимаю смысла отсылки к ЦП.

S>>Все равно что рассуждать об иммутабельности кода по исполнителю уровня процессора, регистров и стека. Мы это уже проходили.

V>Нет, это не тоже самое. Ты не вник в мой пример, к сожалению. В случае иммутабельности и прочей высокоуровневой мишуры целевую механику обеспечивает компилятор автоматически,но в случае предложенного тобой способа ухода от вынужденных goto придется ВРУЧНУЮ нарисовать схему, аналогичную работе центрального процессора.
Суть вопроса была в том, можно или нет избавиться от пересечений (пока мы не можем определиться, что является пересечением, а что — нет). А причем тут вручную или нет? И почему ПРИДЕТСЯ, это что, принципиально нельзя автоматизировать? Не очевидно.

V>Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. )))
Я не втыкаюсь, что за схема интерпретатора графов перехода автомата и что за схема работы ЦП.

S>>В структурном программировании мы оперируем в терминах языка, на котором пишем.

V>Речь шла о задаче и тобой было предложено вместо решения целевой задачи построить эмулятор автомата и решить уже эту задачу на эмуляторе. Тут уже конкретный язык не важен, лишь бы позволял эмулировать работу автомата. А зачем вообще автомат? Ах да, он же позволяет скакать по состояниям произвольно, в отличие от "структурного программирования"... Вот он и скачет по исходных стрелкам с пересечениями.
Я предложенный подход воспринимаю несклько проще чем эмулятор автомата. Адрес безусловного перехода стал ключем-состоянием для ветвления. Согласен, что это можно считать автоматом. Но почему это стало противопоставляться "структурному программированию"?
Язык важен тем что мы рассматриваем СП в рамках языка, позволяющего использовать СП. Все что уровнем ниже — может сильно отличаться от конструкций СП.

S>>От X-образных пересечений я избавился с первого раза. А от T-образных и не собирался.

V>Не избавился, ты их все свел в одну точку и из нее раздал обратно. Вот этот искуственный новый блок как раз принимает все линии и продолжает их на все их конечные точки. Скажем так, ты все эти пересечения накрыл сверху черным ящиком... сделав алгоритм нечитабельным, ес-но...
Как и T-образные они сходятся в одну точку. Здесь никаких отличий нет.
А по поводу читабельности — извини, я не смог прочитать и исходный алгоритм. Так что претензии к читабельности не принимаю.

S>>Обычно не стремлюсь заменять флаги на goto.

V>Дык, у тебя просто выработанная привычка к мышлению в стиле структурного программирования. То бишь вместо того, чтобы шаги алгоритма получались как естественное положение указателя команд, ты эти шаги кодируешь в данных в некое т.н. "состояние". Я не спорю, эта техника хороша... Особенно в событийном/асинхронном программировании — там и вариантов-то нет... Но не факт, что это так же хорошо в синхронном алгоритме, или где допустимо ожидать события по технике poll. Признаюсь, мне все эти вещи немного до фени, т.е. у меня особой любимой техники и стиля нет (и комлпексов по этому факту тоже), мне "структурность" или "функциональность" — как пустой звук, потому что это слишком уж грубые обобщения, которые не натягиваются задёшево на все случаи жизни. В реальности есть алгоритмы (иногда они даны сверху) и удобные модели для их решения. В технике получения событий poll и при наличии механизма исключений приведенный способ на блок-схеме был самый дешевый (это было описание шагов кое-какого протокола без именований и блоков м/у ветвлениями).
Не-не-не. Ты покалаз условие задачи и сказал что никто не избавился от пересечений. Я считаю что мой пример (на авторство методики не претендую) позволяет убрать пересечения. Все остальное — читабельность, дешевость, отсутствие эмуляции автомата и т.п. — их в условии не было. Обсуждать недостатки этого решения я не собираюсь, т.к. я показывал саму возможность в недоумении что никто якобы смог.

S>>Только вот мы не можем сойтись по поводу исчезновения пересечений.

V>Почему не можем? Перенаправляем все линии в один блок — интерпретатор состояний, а тот уже каждую линию доведет до места. Конечный адрес каждого перехода теперь закодирован не в коде, а в данных. Согласно моему ИМХО такой интерпретатор состояний — это прозрачный механизм, т.е. на самом деле входящая в него линия уже заранее знает, в какую конечную точку она попадет (это верно для детерминированных автоматов), ведь перед возвратом на начало цикла предыдущий цикл должен изменить состояние, т.е. "заказать" себе услугу перехода в нужную ему точку... коль мы явно запретили ему переходить куда ему надо по goto... В общем, теперь вместо того, чтобы алгоритму переходить куда ему надо самостоятельно, мы используем посредника со всеми накладными расходами, ес-но.
Вот потому и не можем, что я считаю что дополнительный уровень косвенности позволил убрать пересечения.

S>>Если ты считаешь что пересечения никуда не делись, то какой смысл в преобразовании?

V>Смысл может быть в пошаговости. Такой алгоритм легко приостановить в точке диспетчеризации и потом возобновить, выполнив что-то другое в том же потоке исполнения. Про событийную модель уже напоминал. Собственно, ООП-парадигма сидит на таком подходе, где вызов каждого метода объекта можно рассматривать как запуск цикла интерпретатора состояний автомата (объекта), а возврат из метода означает конец цикла интерпретатора и готовность к следущему "такту"... поэтому и был приведен в пример ЦП как аналогия происходящему.
ИМХО, более близкая аналогия — цикл сообщений. Есть ли пересечения в цикле сообщений (без прямых переходов)?

S>Здравствуйте, vdimas, Вы писали:
S>[...]

V>Здравствуйте, samius, Вы писали:
V>[...]

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

Здравствуйте, PSV100, Вы писали:

PSV>Сорри, что вмешиваюсь, но здесь я соглашусь с Паронджановым в том, что иногда лучше нарисовать, чем долго объяснять на пальцах. Рискну предположить, что здесь на форуме VladZharinov уже давал ссылку на один из вариантов решения подобной "проблемы".

+1
С поправкой: это не один из вариантов, это точно такой же вариант, как мы обсуждаем. Он же единственный, других нет. Я эту схему называю интерпретатором, потому что по ней работают интерпретаторы. Для работы этой сехемы необходимо часть кода перенести в данные (закодировать шаги алгоритма через состояния) и добавить логику по интерпретации этих данных.

Здравствуйте, samius, Вы писали:

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

S>Тогда непонятно, почему таки стрелки пересекутся при наличии цикла
S>

S>Вообще-то ровно наоборот. При табличной эмуляции работы автомата через цикл, вот этот цикл и есть точка пересечения ВСЕХ стрелок.

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

S>Так все-таки, направленные в одно место стрелки пересекаются или нет? Если нет, то цикл не организует пересечений.

Я не спорю, что ты ИЗБАВИЛСЯ от пересечений своей блок-схемы. Я лишь показывал, что теперь эта схема не показывает целевой алгоритм, а показывает алгоритм диспетчеризации некоей интерпретирующей схемы, которая будет исполнять целевой алгоритм. А схему алгоритма надо нарисовать заново. Эта схема должна показывать граф переходов нашего искуственного интерпретатора по своим одноуровневым теперь) веткам ветвления. И на этом графе переходов опять будут пересечения. Се ля ви.

V>>Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных.
S>Странно, но я понимаю, что я предложил. Я не понимаю смысла отсылки к ЦП.

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

V>>Нет, это не тоже самое. Ты не вник в мой пример, к сожалению. В случае иммутабельности и прочей высокоуровневой мишуры целевую механику обеспечивает компилятор автоматически,но в случае предложенного тобой способа ухода от вынужденных goto придется ВРУЧНУЮ нарисовать схему, аналогичную работе центрального процессора.
S>Суть вопроса была в том, можно или нет избавиться от пересечений (пока мы не можем определиться, что является пересечением, а что — нет). А причем тут вручную или нет? И почему ПРИДЕТСЯ, это что, принципиально нельзя автоматизировать? Не очевидно.

Как раз-таки в случае автоматизации ничего делать не надо, пусть себе пересекаются. См. код, генерируемвй всякими генераторами лексеров/парсеров.

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

V>>Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. )))
S>Я не втыкаюсь, что за схема интерпретатора графов перехода автомата и что за схема работы ЦП.

А как вообще работает ЦП?

S>Я предложенный подход воспринимаю несклько проще чем эмулятор автомата. Адрес безусловного перехода стал ключем-состоянием для ветвления. Согласен, что это можно считать автоматом. Но почему это стало противопоставляться "структурному программированию"?

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

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

S>Язык важен тем что мы рассматриваем СП в рамках языка, позволяющего использовать СП. Все что уровнем ниже — может сильно отличаться от конструкций СП.

Вот именно. уровнем ниже. Автоматный подход в разработке — это обратный подход, это использование высокоуровневого языка для моделирования низкоуровневых процессов. А избавиться от трудноизбавимых goto в рамках СП порой никак! Поэтому всю систему опускают на один уровень ниже — на автоматный подход, и решают задачу в рамках низкоуровневого автоматного подхода. Подробная ссылка на нечто подобное рядом уже была.

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

S>Как и T-образные они сходятся в одну точку. Здесь никаких отличий нет.

Они сходятся по исходому алгоитму, а не ради мифического убегания от goto.

S>А по поводу читабельности — извини, я не смог прочитать и исходный алгоритм. Так что претензии к читабельности не принимаю.

Дело твое. А тебе что-то дадут блоки и текст в них?

S>>>Только вот мы не можем сойтись по поводу исчезновения пересечений.
S>Вот потому и не можем, что я считаю что дополнительный уровень косвенности позволил убрать пересечения.

Дык, с этим фактом я не спорю. Я рассуждаю о сути предложенного трюка. Если тебе суть трюка неинтересна... ну значит зря распинался. ОК, вопрос исчерпан.

S>ИМХО, более близкая аналогия — цикл сообщений. Есть ли пересечения в цикле сообщений (без прямых переходов)?

Она не более близкая, это одно и то же. Именно оно. Только здесь исходный алгоритм шлет сообщения сам себе в каждой своей ветке.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, PSV100, Вы писали:

PSV>>Сорри, что вмешиваюсь, но здесь я соглашусь с Паронджановым в том, что иногда лучше нарисовать, чем долго объяснять на пальцах. Рискну предположить, что здесь на форуме VladZharinov уже давал ссылку на один из вариантов решения подобной "проблемы".

V>+1
V>С поправкой: это не один из вариантов, это точно такой же вариант, как мы обсуждаем. Он же единственный, других нет. Я эту схему называю интерпретатором, потому что по ней работают интерпретаторы. Для работы этой сехемы необходимо часть кода перенести в данные (закодировать шаги алгоритма через состояния) и добавить логику по интерпретации этих данных.
В общем, да — либо мы вводим метки (для переходов), либо работаем от состояний как функций над выбранными совокупностями величин процесса. В то же время смысл многоветочного цикла как раз в том, что логика интерпретации м.б. естественно включена в алгоритм. Когда мы сразу задумываемся, какую роль в решении задачи будет играть та или иная ветка этого цикла. Аналогичным образом и ВП предлагает выделить в процессе решения единицы, к которым исполнитель, возможно, будет возвращаться (в силуэте с ВЦ). Только там выбор новой единицы идёт изнутри предыдущей по ходу исполнения...
Для материального техпроцесса, как уже говорил, пример здесь.
И всё, что в схеме — д.б. представимо текстом, конечно. Неважно, скольки-мерное (как я понимаю, здесь в основном обсуждается логическая мерность в смысле введённого здесь разграничения).

Тут, кстати, ещё одно. Не сразу м.б. понятно — что это за "фиктивные вершины" такие?.. На самом деле их условия (описанные здесь), конечно, не реализуются.

Используется то, что иконы веток интерпретируются как метка и команда БП — и тогда достаточно разадресовать эти переходы в машкоде (промежуточном тексте на ЯВУ — где тогда нужен goto). Как — показано здесь (на второй схеме).

Не думаю, что это абсолютно — годится именно для получения маршрутов, которые "... сходятся по исходому алгоитму, а не ради мифического убегания от goto." (С vdimas).

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
Закидонов? А кто поставил задачу убрать пересечения стрелок? Вот того и закидоны.

S>>Так все-таки, направленные в одно место стрелки пересекаются или нет? Если нет, то цикл не организует пересечений.

V>Я не спорю, что ты ИЗБАВИЛСЯ от пересечений своей блок-схемы. Я лишь показывал, что теперь эта схема не показывает целевой алгоритм, а показывает алгоритм диспетчеризации некоей интерпретирующей схемы, которая будет исполнять целевой алгоритм. А схему алгоритма надо нарисовать заново. Эта схема должна показывать граф переходов нашего искуственного интерпретатора по своим одноуровневым теперь) веткам ветвления. И на этом графе переходов опять будут пересечения. Се ля ви.
Ты говоришь "нужно избавиться от перекрестков"
Я — "давай поставим развязку с мостом"
Ты — "надо подпилить опоры, тогда мост упадет и будет как было"
Конечно се ля ви. Так чего ради избавлялись от перекрестков?

V>>>Это был пример того, что означают твои преобразования. Потому что суть твоих преобразований заключается ровно в том же — в разделении алгоритма на состояния (шаги), кодирование этих состояний данными и интерпретация этих данных.
S>>Странно, но я понимаю, что я предложил. Я не понимаю смысла отсылки к ЦП.

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

V>Как раз-таки в случае автоматизации ничего делать не надо, пусть себе пересекаются. См. код, генерируемвй всякими генераторами лексеров/парсеров.
Он для этого не предназначен.

V>Ограничения структурного программирования предназначены для человека, а не машины.
Вот поэтому и избавляются от goto

V>>>Вот попробуй помедитировать и найти отличие схемы интерпретатора графов перехода автомата (суть предложенного тобой трюка) от схемы работы ЦП. )))
S>>Я не втыкаюсь, что за схема интерпретатора графов перехода автомата и что за схема работы ЦП.

V>А как вообще работает ЦП?
Я не спец по ЦП. Мне достаточно того что он выполняет команды. Даже о том что он их интерпретирует мне знать не надо.

S>>Я предложенный подход воспринимаю несклько проще чем эмулятор автомата. Адрес безусловного перехода стал ключем-состоянием для ветвления. Согласен, что это можно считать автоматом. Но почему это стало противопоставляться "структурному программированию"?

V>Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
Тебе не удалось мне это показать.

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

S>>Язык важен тем что мы рассматриваем СП в рамках языка, позволяющего использовать СП. Все что уровнем ниже — может сильно отличаться от конструкций СП.

V>Вот именно. уровнем ниже. Автоматный подход в разработке — это обратный подход, это использование высокоуровневого языка для моделирования низкоуровневых процессов. А избавиться от трудноизбавимых goto в рамках СП порой никак! Поэтому всю систему опускают на один уровень ниже — на автоматный подход, и решают задачу в рамках низкоуровневого автоматного подхода. Подробная ссылка на нечто подобное рядом уже была.
Уровнем ниже чем GOTO? Куда ниже? Если что, то if в СП строится именно на GOTO, поэтому можно смело считать что уровень повышается.

V>Именно из-за того, что избавление от goto порой требует усилий, которые в итоге замыливают исходный алгоритм, я отношусь к goto-ненавистникам с некоторой иронией. И время от времи себе позволяю этот оператор. Не факт, чтов каждом году, но бывает регулярно. Просто нужно убедиться, что это именно тот самый goto, который порожден показанными на блок-схеме пересечениями исходного алгоритма, а не неудачной структуризацией его воплощения.
Мне не приходится от него избавляться, потому как он у меня не появляется. Я не спорю с тем что с goto можно решить эффективнее, или с меньшим количеством операторов.

S>>Как и T-образные они сходятся в одну точку. Здесь никаких отличий нет.

V>Они сходятся по исходому алгоитму, а не ради мифического убегания от goto.
Только убегание вовсе не мифическое.

S>>А по поводу читабельности — извини, я не смог прочитать и исходный алгоритм. Так что претензии к читабельности не принимаю.

V>Дело твое. А тебе что-то дадут блоки и текст в них?
Возможность поговорить о читабельности конкретного алгоритма.

S>>Вот потому и не можем, что я считаю что дополнительный уровень косвенности позволил убрать пересечения.

V>Дык, с этим фактом я не спорю. Я рассуждаю о сути предложенного трюка. Если тебе суть трюка неинтересна... ну значит зря распинался. ОК, вопрос исчерпан.
Суть трюка тривиальна, если не оперировать графами автоматов интерпретаторов переходов.

S>>ИМХО, более близкая аналогия — цикл сообщений. Есть ли пересечения в цикле сообщений (без прямых переходов)?

V>Она не более близкая, это одно и то же. Именно оно. Только здесь исходный алгоритм шлет сообщения сам себе в каждой своей ветке.
Дык! А ЦП обычно не занимается тем что шлет себе сообщения на верхнем уровне абстракции. А на других уровнях все гораздо сложнее, чем в очереди сообщений. Потому, думать об очереди сообщений с вырожденной очередью (до одного места) в качестве аналогии для решения задачи — гораздо проще, чем думать о циклах работы ЦП.

Здравствуйте, samius, Вы писали:

V>>Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
S>Закидонов? А кто поставил задачу убрать пересечения стрелок? Вот того и закидоны.

Ну не я же, ес-но... )))
Задачу поставил ДРАКОН, а на текстовом уровне — ограничения СП.

V>>Я не спорю, что ты ИЗБАВИЛСЯ от пересечений своей блок-схемы. Я лишь показывал, что теперь эта схема не показывает целевой алгоритм, а показывает алгоритм диспетчеризации некоей интерпретирующей схемы, которая будет исполнять целевой алгоритм. А схему алгоритма надо нарисовать заново. Эта схема должна показывать граф переходов нашего искуственного интерпретатора по своим одноуровневым теперь) веткам ветвления. И на этом графе переходов опять будут пересечения. Се ля ви.
S>Ты говоришь "нужно избавиться от перекрестков"
S>Я — "давай поставим развязку с мостом"
S>Ты — "надо подпилить опоры, тогда мост упадет и будет как было"
S>Конечно се ля ви. Так чего ради избавлялись от перекрестков?

Гм... сорри, многоуровневая развязка как-раз уже была.

Ведь эти пересечение существуют только на 2D-схеме, но "контакта" линий на самом деле НЕТ. Можно изобразить схему в 3D, задав для разных блоков разные уровни, и убедиться.

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

V>>Отсылка была конкретно к циклу работы ЦП, т.е. к тому факту, что хотя цикл ЦП можно выразить без пересечений, этот ЦП способен выполнять алгоритмы наподобие тех, блок схему одного из которых я привел. До сих пор не понятна аналогия работы ЦП? Или мне надо раскрыть сам цикл работы ЦП?
S>Да какой там цикл? Весь цикл, который необходим на данном уровне абстракции — взять команду и выполнить.

Ну дык, так же работает ЦП.

S>Но в общем случае ЦП довольно нетривиальная вещь и я не понимаю, о каком цикле работы ты говоришь.

Да я уже понял, что не понимаешь... Хотя не мог в это поверить несколько постов. Фиг с ним, считаем что аналогия была неочевидной.

V>>Ограничения структурного программирования предназначены для человека, а не машины.
S>Вот поэтому и избавляются от goto

Не поэтому. Мы тут обсуждаем ту самую тонкость в отличии стратегии от конкретного шага. Для 99% (грубо) случаев наличие goto означает плохую структуризацию алгоритма. Поэтому, стратегия избавления от goto — хорошая, правильная стратегия. Но знаешь, как в играх, наподобие шахмат, реверси и т.д. — если игрок не способен найти оптимальное решение для конкретной ситуации, то использует некую стратегию. Т.е. действует по-сути вслепую, "согласно инструкции". А если может найти наилучшее решение для конкретной ситуации — то стратегия уже не является определяющей в решении хода.

V>>А как вообще работает ЦП?
S>Я не спец по ЦП. Мне достаточно того что он выполняет команды. Даже о том что он их интерпретирует мне знать не надо.

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

V>>Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
S>Тебе не удалось мне это показать.

Это даже где-то обидно.

"Воображение важнее знания" (С) Энштейн.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Ну дык, образно выразился, они же там встречаются. Причем, не по требованию целевого алгоритма, а исключительно из-за закидонов программиста.
S>>Закидонов? А кто поставил задачу убрать пересечения стрелок? Вот того и закидоны.

V>Ну не я же, ес-но... )))
V>Задачу поставил ДРАКОН, а на текстовом уровне — ограничения СП.

Во! Т.е. исключительные закидоны программиста превращаются в закидоны ДРАКОН-а и СП.

S>>Ты говоришь "нужно избавиться от перекрестков"
S>>Я — "давай поставим развязку с мостом"
S>>Ты — "надо подпилить опоры, тогда мост упадет и будет как было"
S>>Конечно се ля ви. Так чего ради избавлялись от перекрестков?

V>Гм... сорри, многоуровневая развязка как-раз уже была.

Да, верно. Я привел не ту аналогию.

V>Ведь эти пересечение существуют только на 2D-схеме, но "контакта" линий на самом деле НЕТ. Можно изобразить схему в 3D, задав для разных блоков разные уровни, и убедиться.
Тсссс! Если ДРАКОН станет 3D, то это будет финиш всему.

V>То, что предлагаешь ты, Дейкстра и автоматный подход к решению задач — это вместо независимых многоуровневых развязок сделать один кольцевой перекрёсток с десятками примыкающих к нему дорог. Как в реальной жизни, так и в IT на этом кольце всегда тормоза.
Верно.

S>>Но в общем случае ЦП довольно нетривиальная вещь и я не понимаю, о каком цикле работы ты говоришь.

V>Да я уже понял, что не понимаешь... Хотя не мог в это поверить несколько постов. Фиг с ним, считаем что аналогия была неочевидной.
угу

S>>Вот поэтому и избавляются от goto

V>Не поэтому. Мы тут обсуждаем ту самую тонкость в отличии стратегии от конкретного шага. Для 99% (грубо) случаев наличие goto означает плохую структуризацию алгоритма. Поэтому, стратегия избавления от goto — хорошая, правильная стратегия. Но знаешь, как в играх, наподобие шахмат, реверси и т.д. — если игрок не способен найти оптимальное решение для конкретной ситуации, то использует некую стратегию. Т.е. действует по-сути вслепую, "согласно инструкции". А если может найти наилучшее решение для конкретной ситуации — то стратегия уже не является определяющей в решении хода.
Вопрос в том, кому и что лучше. Мне проще размотать цикл, описанный в тексте, чем возить пальцем по переходам ДРАКОНА (пусть даже без пересечений). Возможно это вопрос привычки.

V>В общем, он тоже работает в таком же цикле диспетчеризации со многими одноуровневыми ветвлениями из одной точки — начала цикла.
Там есть небольшое отличие. ЦП может крутиться в цикле, но он лишь исполняет код, а не управляет диспетчеризацией. А алгоритм с циклом сообщений сам управляет своим ветвлением.

V>>>Нет никакого противопоставления, ты не так вопрос ставишь. Я лишь хотел показать, что если после твоих преобразований тебе показалось, что ты избавился от пересечений, то ты явно не туда посмотрел. И всех делов.
S>>Тебе не удалось мне это показать.

V>Это даже где-то обидно.

V>"Воображение важнее знания" (С) Энштейн.
Я от пересечений избавился. Как и Дейкстра. Просто ты утверждаешь что если вернуть все обратно, то пересечения все равно будут. Конечно будут. Но в модифицированном алгоритме их нет. Пусть и ценой значительного усложнения. Не упрощай обратно и пересечений не будет.

А в разговор о том, что кому лучше, пересечения или цикл сообщений, я не ввязывался

Здравствуйте, Wawan, Вы писали:

W>Здравствуйте, Владимир Паронджанов,

W>хороший язык и отлично что на нем пишется софт для космоса,
Интересно, а не нём ли писали софт для Фобос-грунта?

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, Wawan, Вы писали:

W>>Здравствуйте, Владимир Паронджанов,

W>>хороший язык и отлично что на нем пишется софт для космоса,
K>Интересно, а не нём ли писали софт для Фобос-грунта?
Вроде как НПО Лавочкина ГРАФИТ-ФЛОКСОМ не пользуется... только Пилюгинский центр...

Про софт для ФГ jбсуждалсь — можно в этой ветке глянуть.

Здравствуйте, VladD2, Вы писали:

V>>А вообще, использование формального языка для постановки задачи — это на самом деле 5 баллов! Вы просто малость не в ту сторону смотрите и не то желаете там увидеть.
VD>Ага. Только языки эти не могут быть одним языком. Они разные. Как на драконе парсер описать? А как 3d-объект?

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

Что такое "описать 3d объект" я не понял. Если речь о внешнем виде — то 3D объекты "описывают" в проекциях и/или изометриях/аксонометриях. ДРАКОН предназначен для алгоритмической части описания.

==============================
Поясню, почему мне интересны все эти вещи насчет наглядности алгоритмической части. Я уже раз 100, если не больше, писал тут в раных эпических флеймах C++ vs дотнет, что доля ошибок, порождаемых низкоуровневостью языка С++ очень мала в общем кол-ве ошибок при разработке реальных проектов. Что подавляющее большинство проблем банально связаны с ошибками в логике, то бишь связаны с неполной или неверной реализацией прикладной модели. И эти ошибки, если быть справедливым, никак от языка не зависят.

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

Это вообще как??? ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.

V>А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%.

Это вообще как??? ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.

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

Что характерно, обычно такие П и ПЦ обитают на oberoncore, что характерно

Здравствуйте, vdimas, Вы писали:

V>Тебе надо описать грамматику парсера или его механику? Как раз механику любого парсера, в том числе вашего TDOP описать без проблем, это же обычный алгоритм.

И то, и другое. Нам надо описывать конкретные грамматики и генерировать по ним эффективный код. Последнее крайне не тривиально. Во-первых нужно гарантированно генерировать низкоуровневый код. Во-вторых, нужно генерировать специализированный код для разных сочетаний случаев.

V>Что такое "описать 3d объект" я не понял.

А то и значит. Видел такие программы как 3DS Max? У них свои языки описания объектов и дизайнеры для их рисования. Потом эти объекты нужно в программу загружать и использовать. Соответственно как-то надо ее представлять.

V>Если речь о внешнем виде — то 3D объекты "описывают" в проекциях и/или изометриях/аксонометриях. ДРАКОН предназначен для алгоритмической части описания.

Тогда он просто на фиг не упал. Никому не нужен язык в котором нельзя представлять нужную для дела информацию.

V>==============================
V>Поясню, почему мне интересны все эти вещи насчет наглядности алгоритмической части. Я уже раз 100, если не больше, писал тут в раных эпических флеймах C++ vs дотнет, что доля ошибок, порождаемых низкоуровневостью языка С++ очень мала в общем кол-ве ошибок при разработке реальных проектов. Что подавляющее большинство проблем банально связаны с ошибками в логике, то бишь связаны с неполной или неверной реализацией прикладной модели. И эти ошибки, если быть справедливым, никак от языка не зависят.

V>А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%.

Это вообще как???

Наверно орлы не согласны с твоими оценками процентных отношений.

V>ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.

Ага. Я на их обращал внимание последние лет 15. В итоге понял, что это все самообман. Чтобы значительно повысить уровень кода и тем самым уменьшить количество ошибок нужно вводить специализированные языки — ДСЛ-и. А Драконы — это развитие блоксхем. Наверно можно сделать блоксхемы для ДСЛ-ей, но похоже авторы об этом не думали.

VD>Ага. Я на их обращал внимание последние лет 15. В итоге понял, что это все самообман. Чтобы значительно повысить уровень кода и тем самым уменьшить количество ошибок нужно вводить специализированные языки — ДСЛ-и. А Драконы — это развитие блоксхем. Наверно можно сделать блоксхемы для ДСЛ-ей, но похоже авторы об этом не думали.

Ну, оно у них используется, как DSL.

Есть Дракон, манипулирующий высокоуровневыми объектами.
Есть Флокс, который является базой данных этих объектов.

Итог — полуавтоматическая связка этих объектов, используя связи из Драконовской схемы.

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

Здравствуйте, Mamut, Вы писали:

M>Ну, оно у них используется, как DSL.

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

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

А мог бы создавать новые ДСЛ-и и проблем со сменой схем не было бы.

Здравствуйте, VladD2, Вы писали:

V>>Поясню, почему мне интересны все эти вещи насчет наглядности алгоритмической части. Я уже раз 100, если не больше, писал тут в раных эпических флеймах C++ vs дотнет, что доля ошибок, порождаемых низкоуровневостью языка С++ очень мала в общем кол-ве ошибок при разработке реальных проектов. Что подавляющее большинство проблем банально связаны с ошибками в логике, то бишь связаны с неполной или неверной реализацией прикладной модели. И эти ошибки, если быть справедливым, никак от языка не зависят.

V>>А здесь я наблюдаю картину, которую не могу понять: местный народ с удовольствием может спорить месяцами о тех технических моментах, которые порождают дай бог 1% ошибок, но абсолютно равнодушны к попыткам уменьшить кол-во остальных 99%.

Это вообще как???

VD>Наверно орлы не согласны с твоими оценками процентных отношений.

Орлов тошнит от самого термина ТЗ. А с оценками они согласны, не боись.

V>>ИМХО, любые попытки разработать систему формализации ТЗ достойны внимания. ДРАКОН в т.ч.
VD>Ага. Я на их обращал внимание последние лет 15. В итоге понял, что это все самообман. Чтобы значительно повысить уровень кода и тем самым уменьшить количество ошибок нужно вводить специализированные языки — ДСЛ-и. А Драконы — это развитие блоксхем. Наверно можно сделать блоксхемы для ДСЛ-ей, но похоже авторы об этом не думали.

Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.
Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

V>Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.
V>Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?

Здравствуйте, vdimas, Вы писали:

V>Орлов тошнит от самого термина ТЗ. А с оценками они согласны, не боись.

Ты бы у них, что ли, спросил.

V>Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.

Императивный ДСЛ — это примерно тоже самое как соленый леденец. Сделать можно, но зачем он нужен не ясно.

V>Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

Это махровое заблуждение. Попробуй на досуге представить в виде блок-схем или диаграмм грамматику какого-нить языка или описание 3D-объекта.

Я помню, что в школе информатику как раз и начинали преподавать с блок-схем.

Здравствуйте, VladD2, Вы писали:

V>>Блок-схемы для императивных ДСЛ-ей будут идентичны блок-схемам для любых других императивных языков.
VD>Императивный ДСЛ — это примерно тоже самое как соленый леденец. Сделать можно, но зачем он нужен не ясно.

Затем же, зачем любой другой ДСЛ — для описания программы в терминах предметной области.

VD>Попробуй на досуге представить в виде блок-схем или диаграмм грамматику какого-нить языка

Как раз ваш TDOP — это обычный императивный алгоритм.

VD>или описание 3D-объекта.

Про 3D я тебе уже отвечал.

Здравствуйте, Mamut, Вы писали:

M>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?

Угу, а ты на sequence-диаграмме покажи ветвление по условию.

M>>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?

V>Угу, а ты на sequence-диаграмме покажи ветвление по условию.

Ты ммне покажи sequence diagram на Драконе хотя бы без условий.

Здравствуйте, Mamut, Вы писали:

M>>>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?
V>>Угу, а ты на sequence-диаграмме покажи ветвление по условию.
M>Ты ммне покажи sequence diagram на Драконе хотя бы без условий.

Типичная sequence diagram показывает глупым программистам упрощенную схему взаимного поведения нескольких независимых программ, а ДРАКОН преназначен для написания каждой из них. Ты никак не получишь из sequence diagram исходник для каждой программы, упомянутой в диаграмме.

M>>>>Как ты в Драконе будешь записывать, например, sequence diagram, необходимую для описания взаимодействия в многокомпонентных средах?
V>>>Угу, а ты на sequence-диаграмме покажи ветвление по условию.
M>>Ты ммне покажи sequence diagram на Драконе хотя бы без условий.

V>Типичная sequence diagram показывает глупым программистам упрощенную схему взаимного поведения нескольких независимых программ, а ДРАКОН преназначен для написания каждой из них. Ты никак не получишь из sequence diagram исходник для каждой программы, упомянутой в диаграмме.

Мне не надо получать из sequence диаграмм исходники «программ».

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

Ах, и да. Вернемся к твоему заявлению:

V>Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

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

Здравствуйте, Mamut, Вы писали:

M>Мне не надо получать из sequence диаграмм исходники «программ».

Тогда это артефакт для менеджеров.

M>Не говоря о том, что sequеnce диаграммы используются не только для схем поведения независимых программ. Для параллельно выполняющихся компонентов одной программы в распределенной среде sequence diagram подходит как нельзя лучше.

В распределенной среде у тебя разве не разные инстансы программ? В принципе, даже если в речь о разных потоках одного процесса, то... То в классике потоки — это легковесные процессы. Поэтому зря ты пытаешься придираться к словам. Тем более, что на сегодня грань м/у "программами" и "компонентами" весьма умозрительна.

M>Итак, повторю вопрос: как мне создать sequence диаграмму для протокола. Ведь описание протокола зачастую описывает, что происходит в разных независимых программах...

Не факт. Описание протокола может декларировать поведение каждого из ендпоинтов. Особенно это хорошо подходит для симметричных (хотя бы частично) протоколов. Например, фиг ты с помощью sequеnce диаграммы опишешь логику вокруг ширины окна в TCP. Или, например, при конкурентном симметричном доступе к ресурсам (сетка по коаксиалу) sequence-diagram не столь хороша для описания происходящего, как обычный алгоритм с ветвлением, описывающий только одного участника.

M>>Мне не надо получать из sequence диаграмм исходники «программ».

V>Тогда это артефакт для менеджеров.

Нет. Это — полезный инструмент для высокоуровнего планирования взаимодействия компонентов.

M>>Не говоря о том, что sequеnce диаграммы используются не только для схем поведения независимых программ. Для параллельно выполняющихся компонентов одной программы в распределенной среде sequence diagram подходит как нельзя лучше.

V>В распределенной среде у тебя разве не разные инстансы программ?

Не обязательно.

V>В принципе, даже если в речь о разных потоках одного процесса, то... То в классике потоки — это легковесные процессы. Поэтому зря ты пытаешься придираться к словам. Тем более, что на сегодня грань м/у "программами" и "компонентами" весьма умозрительна.

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

Итак, у нас есть несколько взаимодействующих потоков. Например, простейший Map/Reduce или parallel quicksort. Покажи мне, как это показать в Драконе

M>>Итак, повторю вопрос: как мне создать sequence диаграмму для протокола. Ведь описание протокола зачастую описывает, что происходит в разных независимых программах...

V>Не факт. Описание протокола может декларировать поведение каждого из ендпоинтов. Особенно это хорошо подходит для симметричных (хотя бы частично) протоколов. Например, фиг ты с помощью sequеnce диаграммы опишешь логику вокруг ширины окна в TCP. Или, например, при конкурентном симметричном доступе к ресурсам (сетка по коаксиалу) sequence-diagram не столь хороша для описания происходящего, как обычный алгоритм с ветвлением, описывающий только одного участника.

Опять куча текста, лишь бы выкрутиться. Я не говорю, применима ли sequence диаграмма к описанию TCP. Я не говорю, о случаях, когда sequnce диаграмма неприменима. Я говорю о случаях, когда sequence диаграмма применима.

Например, http://www.uml-diagrams.org/sequence-diagrams-examples.html Диаграммы "Submit Comments to Pluck" и "Facebook User Authentication in a Web Application".

Здравствуйте, Mamut, Вы писали:

V>>В распределенной среде у тебя разве не разные инстансы программ?
M>Не обязательно.

Обязательно. Даже если программа одна и та же, инстансы разные.

V>>В принципе, даже если в речь о разных потоках одного процесса, то... То в классике потоки — это легковесные процессы. Поэтому зря ты пытаешься придираться к словам. Тем более, что на сегодня грань м/у "программами" и "компонентами" весьма умозрительна.

M>Не пытайся выкрутиться нагромождением слов.

Агащаз. Твои постоянные попытки придираться к словам уже требуют некоторого ликбеза. Ты же вечно не на сути акцентируешься, а на какой-то фигне, конкретно здесь на якобы разнице м/у программой и компонентом. Эта разница весьма условна. И уже очень давно.

M>Итак, у нас есть несколько взаимодействующих потоков. Например, простейший Map/Reduce или parallel quicksort. Покажи мне, как это показать в Драконе

Это я рисовать что ле для тебя должен? Попридержи коней, парниша. Как именно раскладываются диаграммы последовательностей на алгоритмы каждого из участников курить самостоятельно. А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.

M>Опять куча текста, лишь бы выкрутиться. Я не говорю, применима ли sequence диаграмма к описанию TCP. Я не говорю, о случаях, когда sequnce диаграмма неприменима. Я говорю о случаях, когда sequence диаграмма применима.

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

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

M>>Итак, у нас есть несколько взаимодействующих потоков. Например, простейший Map/Reduce или parallel quicksort. Покажи мне, как это показать в Драконе

V>Это я рисовать что ле для тебя должен? Попридержи коней, парниша. Как именно раскладываются диаграммы последовательностей на алгоритмы каждого из участников курить самостоятельно.

V>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.

Как ты покажешь в драконе взаимодействие между этими участниками?

M>>Опять куча текста, лишь бы выкрутиться. Я не говорю, применима ли sequence диаграмма к описанию TCP. Я не говорю, о случаях, когда sequnce диаграмма неприменима. Я говорю о случаях, когда sequence диаграмма применима.

V>И когда это она применима для генерации кода? Ты ничего не путаешь часом? Ну-ка дай пример.

А кто говорил про генерацию кода?

Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

Или для тебя алгоритм — это «сел и начал фигачить код»?

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

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

ТО есть, ты говоришь, что описания сложных алгоритмы/протоклов моментально сразу переводятся в код? Нуну.

Здравствуйте, Mamut, Вы писали:

M>>>Итак, у нас есть несколько взаимодействующих потоков. Например, простейший Map/Reduce или parallel quicksort. Покажи мне, как это показать в Драконе

V>>Это я рисовать что ле для тебя должен? Попридержи коней, парниша. Как именно раскладываются диаграммы последовательностей на алгоритмы каждого из участников курить самостоятельно.

V>>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.

M>Как ты покажешь в драконе взаимодействие между этими участниками?
Сам ВП предлагал два варианта: 1) как раскрыть свои же Z-операторы в этом посте — через работу в "точном времени"; 2) как представить обмен сообщениями — через оператор И20 (отправка сообщений; пример приложения дал Р. Блинов в этом посте на третьей схеме; нужен парный оператор приёма сообщений).

M>>Как ты покажешь в драконе взаимодействие между этими участниками?
VZ>Сам ВП предлагал два варианта: 1) как раскрыть свои же Z-операторы в этом посте — через работу в "точном времени"; 2) как представить обмен сообщениями — через оператор И20 (отправка сообщений; пример приложения дал Р. Блинов в этом посте на третьей схеме; нужен парный оператор приёма сообщений).

Первую ссылку видел в первом пункте видел, остальные еще нет. Увы, большой наглядности предложенные варианты не предлагают

Здравствуйте, Mamut, Вы писали:

M>Первую ссылку видел в первом пункте видел, остальные еще нет. Увы, большой наглядности предложенные варианты не предлагают

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

И ведь дело в том, что сначала идёт содержательное (а ещё раньше — целевое, т.е. прагматика)... а потом уже думаем, как бы это понагляднее представить...

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

К семантике схем есть вопросы... Не говоря о том, что эта работа требует "GAN-алгебраиста"...

Как уже понятно, видимо, я не фанат ни ДРАКОНа, ни Оберона, скажем.

Мне нужны средства представить реальную деятельность — я их подбираю. Если возможно — что-то модифицируя... В этом процессе, разумеется, интересны любые спокойные содержательные мнения.

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

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

Здравствуйте, Mamut, Вы писали:

V>>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.
M>Как ты покажешь в драконе взаимодействие между этими участниками?

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

V>>И когда это она применима для генерации кода? Ты ничего не путаешь часом? Ну-ка дай пример.
M>А кто говорил про генерацию кода?

Тут говорят.

M>

M>Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

M>Или для тебя алгоритм — это «сел и начал фигачить код»?

1. ответ нет.
2. при чем тут своё "или"? фраза вышла нерелевантной.

M>ТО есть, ты говоришь, что описания сложных алгоритмы/протоклов моментально сразу переводятся в код? Нуну.

Да, какие проблемы автоматизировать кодогенерацию? Не писал никогда генерилок кода из "левого", по отношению к целевому коду, описания?

V>>>А для закрепелния материала — нарисовать и показать нам разложение на одопоточные алгоритмы хотя бы parallel quicksort. Жду.
M>>Как ты покажешь в драконе взаимодействие между этими участниками?

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

Набор не обязательно комбинаторный.

V>>>И когда это она применима для генерации кода? Ты ничего не путаешь часом? Ну-ка дай пример.
M>>А кто говорил про генерацию кода?

V>Тут говорят.

Про нее говоришь только ты, и только тогда, когда тебе нужно. Смотрим твою цитату ниже. Если Дракон — способ описания протоколов/алгоритмов, то генерация кода не обязательна.

M>>

M>>Да, ДРАКОН — это развитие блок-схем. Но сложные алгоритмы/протоколы до сих пор даются в блок схемах или альтернативных нотациях (типа графа состояний). И будутвпредь даваться. Бо это многократно удобней словесного описания ТЗ/протокола/алгоритма для случая многих ветвлений.

M>>Или для тебя алгоритм — это «сел и начал фигачить код»?

V>1. ответ нет.

Если ответ — нет, то попрошу аналоги слежующего для Дракона: http://www.uml-diagrams.org/sequence-diagrams-examples.html

M>>ТО есть, ты говоришь, что описания сложных алгоритмы/протоклов моментально сразу переводятся в код? Нуну.
V>Да, какие проблемы автоматизировать кодогенерацию? Не писал никогда генерилок кода из "левого", по отношению к целевому коду, описания?

«"Левого", по отношению к целевому коду, описание» — это как раз описание алгоритма. Пример описания алгоритма: http://www.uml-diagrams.org/sequence-diagrams-examples.html Седьмое, по-моему, сообщение подряд прошу показать мне аналог на Драконе.

Здравствуйте, Cyberax, Вы писали:

C>"Программирование светофора"?

IMHO, ты зря ёрничаешь. Сделать систему, которая позволяет программировать сыетофор/светофоры перекрёстка/улицы/микрорайона и при этом позволяет легко обучить это делать офицера ГИБДД, а не выпускника мехмата -- не такая уж и простая задача, особенно если учесть, что надо обеспечить высокий уровень безопасности ДД и непротиворечиывость на границах участков...

Здравствуйте, elmal, Вы писали:

E>Во первых, сложный алгоритм из 100 000 строк составлять не нужно никогда! Ибо это явно для гениев с IQ под 1000. Люди же со скромным IQ 200 делают декомпозицию и составляют набор простых слабо связанных алгоритмов.

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

E>По поводу понятности. Хорошо — пусть будут Дракон схемы для визуализации алгоритмов! Непонятно, чем он лучше других подобных языков, вроде UML,
UML не позволяет записать алгоритм.

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

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

Здравствуйте, Erop, Вы писали:

E>IMHO, ты зря ёрничаешь. Сделать систему, которая позволяет программировать сыетофор/светофоры перекрёстка/улицы/микрорайона и при этом позволяет легко обучить это делать офицера ГИБДД, а не выпускника мехмата -- не такая уж и простая задача, особенно если учесть, что надо обеспечить высокий уровень безопасности ДД и непротиворечиывость на границах участков...

Ты зачем достал ветку двухгодовой давности?

Здравствуйте, alpha21264, Вы писали:
A>Ты зачем достал ветку двухгодовой давности?

Дракон еще не издох ?

Здравствуйте, alpha21264, Вы писали:

A>Ты зачем достал ветку двухгодовой давности?

Нечаянно.
Когда отправил уже заметил, что несколько занекропостил.

Здравствуйте, Erop, Вы писали:

E>А "Фобос-Грунт" на чём делали?..

Откопал, блин. Закапывай обратно.

Здравствуйте, Ops, Вы писали:

Ops>Откопал, блин.
Сам не рад. Перешёл по какой-то ссылке от Лаптева и только после ответа заметил, что оно двухлетнее уже...

Ops>Закапывай обратно.
А как это сделать?
И, кстати, краткое резюме-то какое?
ДРАКОН-то реально на "Буране" использовали?
И Бату там реально работал или как обычно рапортует из параллельной реальности?

Здравствуйте, Erop, Вы писали:

E>А как это сделать?

E>И, кстати, краткое резюме-то какое?
Это секта.
E>ДРАКОН-то реально на "Буране" использовали?
E>И Бату там реально работал или как обычно рапортует из параллельной реальности?
Я тогда забил на этот флейм, так и не разобравшись.

Здравствуйте, Ops, Вы писали:

Ops>Это секта.
Ну. так это же и прикольно!
Вон немерле, например, тоже секта

Ops>Я тогда забил на этот флейм, так и не разобравшись.
Я вот тоже не осилю, похоже...

Здравствуйте, Erop, Вы писали:

Ops>>Это секта.
E>Ну. так это же и прикольно!
E>Вон немерле, например, тоже секта

Так немерлю делают хотя бы, а тут только восхваляют.

Ops>>Я тогда забил на этот флейм, так и не разобравшись.
E>Я вот тоже не осилю, похоже...
А надо?

Здравствуйте, Трололоша, Вы писали:

Ops>>А ты вот это http://www.rsdn.ru/forum/flame.comp/4086890.aspx застал?
Т>А как же!
Т>Я даже под опусы Сергея "Синтаксический Оверхед" Губанова изволил откушать.
Т>Мы, тролли — древний народ

Да тут каждые пару лет очередное гениальное решение из этой же серии вылезает. Лаптев тоже, помнится, похожее задвигал. А первое из таких решений мне на глаза попалось ещё году примерно в 92-м. Вот же ж тупой и упрямый народ эти программисты: долбишь им долбишь, рассказываешь, как им удобнее, — нет, всё блин по-своему делают.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Да, можно. Для этого надо решительно отобрать эту работу у постороннего человека (программиста, потому что он не в курсе дела) и передать ее компетентному человеку, то есть инженеру.

ВП>Почему? Потому что первоисточником знаний является инженер. Инженер стоит на высшей ступени знаний. Он знает данный вопрос (как обрабатывать ошибки) намного лучше, чем программист. Программист получает знания от инженера.

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

Да, а ещё можно отобрать работу по лечению у доктора и отдать её больному. Потому что больной гораздо лучше доктора знает, где у него болит, и уж точно не забудет об этой боли, в отличие от доктора, у которого не болит.

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

Сколько я имел дело и с инженерами-электронщиками, чьё железо пинал программно, и с бухгалтерами-кладовщиками всякими, и со всеми остальными постановщиками задач, знающими свою область лучше меня — и всегда оказывалось, что моя въедливость в плане обработки нестандартных ситуаций на порядок выше ихней, и это обычно спасало проект. Как раз потому что я не знаю всех ньюансов их предметной области, но зато знаю как писать программы. В отличие от. И когда они мне говорят — "такого не может быть", я этим спецам в своей области тупо не верю, потому что у меня получается не закрытый if без ветки else, и я пишу этот else, которого "не может быть" и который аккурат через 1-2 месяца таки-случается. И любой программист, достаточно долго работавший с экспертами-постановщиками задач, подтвердит, что так оно всегда и происходит.

Каждый должен заниматься своим делом.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, alpha21264, Вы писали:

A>>Ты зачем достал ветку двухгодовой давности?

E>Нечаянно.
E>Когда отправил уже заметил, что несколько занекропостил.

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

Здравствуйте, peterbes, Вы писали:

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

Ну, он как-то мимо меня прошёл, поэтому я и не заподозрил, что оно может быть таким старым...

Так чем там дело закончилось-то? Писали Буран на ДРАКОНе, или оно не взлетело по другим причинам?

Последние новости о языке ДРАКОН

Последние новости о языке ДРАКОН

19 мая 2017 года состоялся доклад Владимира Паронджанова в Институте системного программирования Российской академии наук на тему:

Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН

Я договорился с Александром Константиновичем Петренко, с которым 30 с лишним лет назад мы вместе разрабатывали вычислительную систему орбитального корабля "Буран".

У меня не было его координат, но в наш волшебный век это не проблема.
Гугл мне моментально подсказал все, что нужно: и телефон, и E-mail.

Петренко Александр Константинович — Главная страница
sp.cmc.msu.ru/staff/pak.html
16 июл. 2009 г. — Петренко Александр Константинович ... E-mail: petrenko@ispras.ru ... А. К. Петренко опубликовал свыше 70 научных работ, в том числе:.

Александр Константинович Петренко
panda.ispras.ru/~petrenko/index_ru.html
+7(916)156-3502. Адрес: 109004, Москва, А.Солженицына, 25. E-mail: petrenko < at > ispras.ru a.k.petrenko < at > gmail.com. Skype: ak-petrenko7076 ...

Я подготовил к докладу 104 слайда.

Аннотация доклада

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

Современная теория алгоритмов не имеет удобного (эргономичного) языка, позволяющего облегчить и ускорить понимание алгоритмов ЧЕЛОВЕКОМ. Она не применима к медицинским алгоритмам и не содействует повышению безопасности пациентов. Она не оказывает практической помощи при разработке бизнес-процессов, потоков работ (workflows) и пр.
Современные языки программирования используют управляющие слова (if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и др.) , которые играют роль визуальных помех, провоцируют появление ошибок и мешают понять смысл алгоритма в терминах предметной области.
Предлагаются теоретические и практические средства, чтобы устранить или ослабить указанные недостатки

План доклада

0. Введение
1. Алгоритмы без программистов
2. Формальная управляющая графика

3. Когнитивная эргономика
4. Визуальная логика
5. Визуальное логическое исчисление

6. Алгоритмическая конструкция "Силуэт"
7. Метод Ашкрофта-Манны
8. Двумерное структурное программирование.

9. Заключение

После доклада, как обычно, были вопросы и обсуждение. Семинар длился 3 часа.

Ведущий семинара Заместитель директора Института системного программирования РАН,
Зам. главного редактора журнала "Программирование" Российской академии наук
доктор физико-математических наук, профессор
Александр Константинович Петренко.

Семинар был снят на видео и вскоре будет выложен на YouTube.

Ниже я выкладываю Приветствие Альгирдаса Каралюса (Литва), обращенное к участникам семинара
в Институте системного программирования РАН 19 мая 2017 года.

Альгирдас рассказывает

(1) об успехах литовских медиков, применяющих язык ДРАКОН для обучения врачей, лечения и спасения жизней, а также

(2) об использовании языка ДРАКОН для обучения и оптимизации бизнес-процессов.

Альгирдас Каралюс — основатель Центра "DRAKON Language School"

https://www.youtube.com/watch?v=HHL9-JxL08s

Я полагаю, что в императивном программировании возможен иной путь.

1. Современные языки программирования используют управляющие слова (if, then, else, case, of, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и др.).

2. Давайте подумаем вместе. Нужны ли эти слова? Можно ли без них обойтись?

3. Я доказал, что указанные слова и их аналоги можно без потери точности заменить и преобразовать в эквивалентную графику (образно говоря, превратить их в "линии и квадратики").
Подобная графика есть средство представления алгоритмов.

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

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

6. Удалив указанные ключевые слова и заменив их на графику, мы делаем важный шаг в правильном направлении. Это можно считать доказанным.

7. Но здесь возникает препятствие. Существующие инструменты программирования не рассчитаны на работу с предлагаемой мною идеей.

8. Модификация существующих инструментов программирования для согласования с предлагаемой графикой есть большая и сложная работа. Работа, которая требует времени и средств. Моя цель — пригласить компетентных специалистов и попытаться их заинтересовать.

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

10. На эту тему я написал книгу под названием
"Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины. Клиническое мышление высокой точности и безопасность пациентов. / Предисловие члена-корреспондента РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с. — Иллюстраций: 130".

С книгой можно познакомиться здесь:
http://drakon.su/_media/1_pochemu_vrachi_ubivajut_i_kalechat_pacientov_.pdf

11. Моя цель — внедрить медицинские алгоритмы высокой точности в качестве стандарта в российской медицине.

12. Вторая цель использовать графические алгоритмы высокой точности для обучения предпринимателей и моделирования бизнес-процессов и стартапов.

13. Третья цель (которая пока в перспективе) — внедрить графические алгоритмы высокой точности в качестве стандарта в Вооруженных силах РФ.

14. Четвертая цель. Заменить стандарт на блок-схемы алгоритмов, описанный отечественном ГОСТ 19.701-90 и международном стандарте ISO 5807-85 на стандарт языка ДРАКОН, описывающий графические алгоритмы высокой точности.

15. Когда эти цели будут достигнуты, как мне кажется, будут достигнуты необходимые условия и созреют предпосылки для проведения соответствующих разработок в области программирования и развития ИНОГО ПУТИ в технологии программирования, о котором я говорил выше.

16. Где можно познакомиться с упомянутыми выше доказательствами?
Доказательства представлены в моей книге:
"Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК-пресс, 2012, 2014, 2016. — 520 с. — Иллюстраций 272".
Ссылка для скачивания:
http://drakon.su/_media/01._parondzhanov_uchis_pisat_chitat_i_ponimat_algoritmy.pdf

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Изюминка в том, что Дракон — очень легкий язык. Необыкновенно легкий. Прочитав книгу, вы без труда убедитесь, что управляющая графика Дракона является мощным инструментом, причем ее мощь легка в освоении и легко применима на практике.

Посмотрел "по диагонали". Ведущийся спор прочитал частично.

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

Но это, пока, поверхностные впечатления.

Споры уже растянулись на много страниц. Что бы обсуждение было более предметным, прошу выложить какие-нибудь исходники реального ПО на Драконе, а не учебных примеров. Среда разработки и компилятор Дракона написаны на Драконе? Где можно посмотреть исходники?

С какими парадигмы программирования, кроме процедурного, может работать Дракон?

Здравствуйте, AleksandrN, Вы писали:

AN>прошу выложить какие-нибудь исходники реального ПО на Драконе, а не учебных примеров. Среда разработки и компилятор Дракона написаны на Драконе? Где можно посмотреть исходники?

Я работаю в НПЦАП им. акад. Н.А. Пилюгина (свыше 56 лет). Это закрытый научно-производственный центр. Исходники я выложить, к сожалению, не могу. Не имею права. У нас компилятор написан НЕ на Драконе.

Но. Степан Митькин (Норвегия, Осло)создал два ДРАКОН-конструктора (онлайн и офлайн). Он написал свою инструментальную программу на Драконе.
См. здесь: http://forum.drakon.su/viewforum.php?f=151&sid=87b6fd7385c6593b9bfe4a5585b0eb39

AN>С какими парадигмы программирования, кроме процедурного, может работать Дракон?

Степан Митькин считает, что ДРАКОН может работать с парадигмой функционального программирования.
На конференции в Швеции, посвященной языку Erlang, Степан Митькин делал доклад по гибридному языку Дракон-Erlang.
Вот две ссылки
1. на его доклад https://www.youtube.com/watch?v=yZLedcnFA94&t=52s
2. на его презентацию https://www.youtube.com/watch?v=TYmZExJ4nGI

Здравствуйте, AleksandrN, Вы писали:

AN>С какими парадигмы программирования, кроме процедурного, может работать Дракон?

Если в квадратиках писать код не на C, а на Haskell, то и с функциональной парадигмой тоже может. И далее по индукции.
Ну а что? Квадратик красивый будет. В остальном вопрос упирается в Неуловимого Джо.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>У нас компилятор написан НЕ на Драконе.

Почему?

ВП>Но. Степан Митькин (Норвегия, Осло)создал два ДРАКОН-конструктора (онлайн и офлайн). Он написал свою инструментальную программу на Драконе.
ВП>См. здесь: http://forum.drakon.su/viewforum.php?f=151&sid=87b6fd7385c6593b9bfe4a5585b0eb39

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

По примерам, которые идут в комплекте с редактором:
Открыв файл examples/structure/Tcl/01-simple-Tcl.drn, увидел такую картинку:

http://files.rsdn.org/66988/dragon-bug.png
Слева явно что-то есть, но полосы прокрутки отсутствуют.

Ctrl+A, затем мышью начинаю двигать схему.
http://files.rsdn.org/66988/dragon-bug-1.png

Это ещё не всё.
http://files.rsdn.org/66988/dragon-bug-2.png

И там дальше ещё пару экранов влево нужно прокрутить. Т.е. — даже на простом примере картинка на экран не помещается. Текст тоже не помещается, но — по моему мнению, навигация по тексту удобнее, чем по схеме. Да и без полос прокрутки очнь неудобно.

Ещё моменты, которые мне показались неудобными в редакторе и примерах:
1. Файлы .drn представляют собой БД sqlite. Это затрудняет поиск файла, содержащего нужную строку. А также затрудняет использование систем контроля версий.
2. Редактор сохраняет файл после каждого изменения, даже если все блоки чуть сдвинули. Это неудобно, если файл открыт с целью посмотреть его, а не редактировать.
3. Комментарии не переносятся со схемы в сгенерированный файл.
4. В каталоге examples/structure/C для сборки применяются .cmd-файлы. Зачем? Не лучше ли мэйкфайлы использовать?

В таком виде — не взлетит.

Думаю, годное применение Дракона — прототипирование на высоком уровне, без углубления в детали реализации. На более низком уровне — никакого преимущества перед другими походами, применяющимися в индустрии.

Здравствуйте, samius, Вы писали:

S>Ну а что? Квадратик красивый будет. В остальном вопрос упирается в Неуловимого Джо.

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

Программа «ИС Дракон» Автор Геннадий Тышов (Россия, Северодвинск)

Автор видеороликов: Сергей Ефанов (Россия, Липецк)

Видео. Использование языка ДРАКОН для программирования микроконтроллеров.
Часть 1. Разработка программы управления автоматическим дверным замком.
https://www.youtube.com/watch?v=Ua9dUUONjdk&feature=youtu.be

Видео. Использование языка ДРАКОН для программирования микроконтроллеров.
Часть 2. Программирование битовых операций: инициализация процессора,
настройка таймера и т.д. Компиляция.
Загрузка полученной программы в постоянную память процессора (прошивка).
https://www.youtube.com/watch?v=zeIq_JQhYSI&t=80s

Видео. Использование языка ДРАКОН для программирования микроконтроллеров.
Часть 3. Проектирование сложного алгоритма реального времени.
Проектирование разветвленного алгоритма. Проектирование циклов.
Оператор ожидания. Оператор "пауза". (на примере управления дверным замком).
https://www.youtube.com/watch?v=Sp6AMGzTM78&t=5s

Видео. Использование языка ДРАКОН для программирования микроконтроллеров.
Часть 4. Работа с несколькими таймерами. В какой момент нужно запустить каждый таймер?
Управление шиной процессора (на примере управления дверным замком)
https://www.youtube.com/watch?v=1PWDuPeJ_bk&t=13s

Здравствуйте, AleksandrN, Вы писали:

AN>Споры уже растянулись на много страниц. Что бы обсуждение было более предметным, прошу выложить какие-нибудь исходники реального ПО на Драконе, а не учебных примеров. Среда разработки и компилятор Дракона написаны на Драконе? Где можно посмотреть исходники?
Вот несколько ссылок:
http://drakon-editor.sourceforge.net/
https://drakon-editor.com/
https://github.com/stepan-mitkin/drakon_editor
Прошу различать сам язык ДРАКОН и попытки программно реализовать этот язык.

AN>С какими парадигмы программирования, кроме процедурного, может работать Дракон?
— Функциональное (убираем циклы, делаем ветвление/принятие решений явным)
http://drakon-editor.sourceforge.net/drakon-erlang/intro.html
— Объектно-ориентированное (на уровне алгоритмов отличия от процедурного почти нет)
— Конечные автоматы (это не только про микроконтроллеры. именно ДРАКОН даёт автоматам дорогу в остальлные отрасли программирования)

Здравствуйте, Владимир Паронджанов, Вы писали:

По большому счету у вас есть Дерево из набора нод и переходы.
На C# эта задача легко решается через yeld.
Yield используются в том числе ив acync await там как раз автоматы используются и в куче итераторов, в том числе и рекурсивных

Здравствуйте, Stepan Mitkin, Вы писали:

SM>Прошу различать сам язык ДРАКОН и попытки программно реализовать этот язык.

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

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Здравствуйте, samius, Вы писали:

S>>Ну а что? Квадратик красивый будет. В остальном вопрос упирается в Неуловимого Джо.

ВП>Попробую привести иллюстрации, позволяющие увидеть "Неуловимого Джо".
ВП>Вот простой пример программы управления дверным замком.
Благодарю за примеры. Увидеть-то я его увидел, но желания его поймать таки не возникло.

ВП>Программа «ИС Дракон» Автор Геннадий Тышов (Россия, Северодвинск)

ВП>Автор видеороликов: Сергей Ефанов (Россия, Липецк)

ВП>Часть 1. Разработка программы управления автоматическим дверным замком.

ВП>Часть 2. Программирование битовых операций: инициализация процессора,
Вот в этой части на 11-ой минуте под звук фразы "действуя подобным образом", размер листа увеличивается где-то в 4 раза. Т.е. по идее, полное видео должно было бы быть около часа...

ВП>Часть 3. Проектирование сложного алгоритма реального времени.
ВП>Проектирование разветвленного алгоритма. Проектирование циклов.
ВП>Оператор ожидания. Оператор "пауза". (на примере управления дверным замком).
Это СЛОЖНЫЙ алгоритм? Что же тогда можно сказать про какой-нибудь парсер CSS? Сколько времени займет разработка его на ДРАКОН?

ВП>Часть 4. Работа с несколькими таймерами. В какой момент нужно запустить каждый таймер?
Удивительно сложный пример "простой" программы. Казалось бы, выбор действия (включить таймер или двигатель) — всего лишь функция от состояния окружения (кортеж из положения ригеля, замкнутости контакта кнопки, времени таймера и т.п.).

Здравствуйте, Stepan Mitkin, Вы писали:

SM>- Функциональное (убираем циклы, делаем ветвление/принятие решений явным)
SM>http://drakon-editor.sourceforge.net/drakon-erlang/intro.html

Надеюсь, вы не будете против, еслия положу пару примеров прямо тут?
1)

Now let us compare a text-based and a visual formula for a more sophisticated logic expression.

Text formula:
M = (A and not B and C) or (D and E and not F)
Visual formula:

The text-based formula definitely occupies less space. But it is the reader's job to decompress it. The complexity is still there, but it is hidden.

На мой взгляд, текстовый вариант гораздо понятнее. Да, он требует знания execution model и особенностей выполнения вычислений по короткой схеме. Но у него есть преимущество перед визуальным вариантом. Его можно проговорить, передать по телефону, и даже запомнить и покрутить в голове. Про получить diff при изменении я не говорю, т.к. при соответствующей реализации этого же можно добиться и текстовом представлении визуальной схемы. Но вот лично мне короче и понятнее текстовый вариант. И мне не нужно декомпрессить его, что бы понять.

2)

qsort_r([]) ->
    [];
qsort_r([Pivot | L]) ->
    qsort_r([X || X <- L, X < Pivot]) ++
    [Pivot] ++
    qsort_r([X || X <- L, X >= Pivot]).

Я заметил, что на ДРАКОН реализована чуть другая модификация. Но даже если выкинуть из нее избыточный simple case, то шуму и информации для восприятия в нем все равно гораздо больше, чем в тектсте.

Здравствуйте, samius, Вы писали:

S>На мой взгляд, текстовый вариант гораздо понятнее. Да, он требует знания execution model и особенностей выполнения вычислений по короткой схеме. Но у него есть преимущество перед визуальным вариантом. Его можно проговорить, передать по телефону, и даже запомнить и покрутить в голове. Про получить diff при изменении я не говорю, т.к. при соответствующей реализации этого же можно добиться и текстовом представлении визуальной схемы. Но вот лично мне короче и понятнее текстовый вариант. И мне не нужно декомпрессить его, что бы понять.

Спасибо за интересные критические замечания.
Вы попали в самую точку. В самое сердце Дракона.

Идея Дракона заключается в том, чтобы ОБЛЕГЧИТЬ И УСКОРИТЬ ПОНИМАНИЕ.
Эти слова надо понимать и в таком смысле:
МАКСИМАЛЬНО СНИЗИТЬ ТРЕБОВАНИЯ К КВАЛИФИКАЦИИ ЧИТАТЕЛЯ.

Вы говорите: мне это не надо. Я и так все прекрасно понимаю.
Поэтому мне Дракон не нужен.

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

Скажу проще. Вам приходится отвечать на вопросы въедливого заказчика,
который вместе с тем не знает и не желает знать тонкости программирования.
Попробуйте показать ему дракон-схему вашей программы.
И объяснить ему суть дела с помощью дракон-алгоритма.
С большой долей вероятности он Вас поймет и вопрос будет исчерпан.
Потому что язык ДРАКОН — это язык спецификаций.

В этом случае возникает ПЕДАГОГИЧЕСКАЯ, ДИДАКТИЧЕСКАЯ задача.
Язык ДРАКОН предназначен для решения подобной задачи. Это учебный язык.

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

Приведу классическую цитату.
Эдвард Йодан писал:

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

В данном случае Йодан выступает как Гуманист.
Он заботится о программистах и стремится облегчить их тяжелую работу.
Правильно ли поступает Эдвард Йодан? Думаю, что правильно.

Это только Фридрих Ницше говорил одиозное: "Падающего толкни".

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

Можно ли обойтись в булевых выражениях без пропозициональных связок?
Язык дракон отвечает: можно и нужно.

Степан Митькин показал Вам КАНОНИЧЕСКУЮ ФОРМУ визуальных пропозициональных формул,
в которой полностью исключены пропозициональные связки.
Вам это не понравилось. Вы, разумеется, правы.
Каждый человек имеет право работать как он привык и как ему удобнее.

Заметьте: Дракон не запрещает использовать пропозициональные связки.
Он лишь показывает, что наряду с традиционной формой существует и каноническая форма.

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

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

Язык ДРАКОН предлагает единый алгоритмический подход к различным предметным областям:
и к медицине, и к программированию, и к бизнес-процессам и к сельскому хозяйству и т.д.

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Идея Дракона заключается в том, чтобы ОБЛЕГЧИТЬ И УСКОРИТЬ ПОНИМАНИЕ.
Нету такой идеи. Есть идея-фикс о том, что графическое программирование проще текстового.

ВП>Вы говорите: мне это не надо. Я и так все прекрасно понимаю.
ВП>Поэтому мне Дракон не нужен.
Он никому не нужен, так как не достигает поставленной цели.

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

ВП>Вы, разумеется, правы. Но представьте себе, что Вы неожиданно стали педагогом.
Гнать вас надо от детей, куда подальше.

ВП>В этом случае возникает ПЕДАГОГИЧЕСКАЯ, ДИДАКТИЧЕСКАЯ задача.
ВП>Язык ДРАКОН предназначен для решения подобной задачи. Это учебный язык.
Правильно, так как ни для чего практического он не пригоден. За много лет драконодрочерства на нём не было написано ни одной серьёзной системы. Даже компилятор самого себя не написан.

ВП>Дракон позволяет объяснить логическую задачу людям, которые не знают алгебру логики.
ВП>Совсем не знают.
То есть, он написан неумехами для неграмотных.

ВП>

ВП>«Если это возможно, избегайте отрицаний в булевых выражениях.
ВП>Представляется, что их понимание представляет трудность
ВП>для многих программистов».

Мало ли что ему представляется.

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Здравствуйте, samius, Вы писали:

S>>На мой взгляд, текстовый вариант гораздо понятнее. Да, он требует знания execution model и особенностей выполнения вычислений по короткой схеме. Но у него есть преимущество перед визуальным вариантом. Его можно проговорить, передать по телефону, и даже запомнить и покрутить в голове. Про получить diff при изменении я не говорю, т.к. при соответствующей реализации этого же можно добиться и текстовом представлении визуальной схемы. Но вот лично мне короче и понятнее текстовый вариант. И мне не нужно декомпрессить его, что бы понять.

ВП>Спасибо за интересные критические замечания.
ВП>Вы попали в самую точку. В самое сердце Дракона.

ВП>Идея Дракона заключается в том, чтобы ОБЛЕГЧИТЬ И УСКОРИТЬ ПОНИМАНИЕ.
ВП>Эти слова надо понимать и в таком смысле:
ВП>МАКСИМАЛЬНО СНИЗИТЬ ТРЕБОВАНИЯ К КВАЛИФИКАЦИИ ЧИТАТЕЛЯ.

ВП>Вы говорите: мне это не надо. Я и так все прекрасно понимаю.
ВП>Поэтому мне Дракон не нужен.

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

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

ВП>Скажу проще. Вам приходится отвечать на вопросы въедливого заказчика,
ВП>который вместе с тем не знает и не желает знать тонкости программирования.
ВП>Попробуйте показать ему дракон-схему вашей программы.
ВП>И объяснить ему суть дела с помощью дракон-алгоритма.
ВП>С большой долей вероятности он Вас поймет и вопрос будет исчерпан.
ВП>Потому что язык ДРАКОН — это язык спецификаций.
Дракон-схема программы? Для моих программ это малореально. Используя инкапсуляцию и барьеры абстракции я могу вынести в схему какие-то отдельные аспекты, но скорее всего это будет блок-схема, а не Дракон. Для презентации и обсуждения большего не требуется.

ВП>В этом случае возникает ПЕДАГОГИЧЕСКАЯ, ДИДАКТИЧЕСКАЯ задача.
ВП>Язык ДРАКОН предназначен для решения подобной задачи. Это учебный язык.

ВП>Дракон позволяет объяснить логическую задачу людям, которые не знают алгебру логики.
ВП>Совсем не знают.
Про именно "объяснить" — я согласен, хотя и не вижу превосходство Дракона перед блок-схемами в аспекте задачи "объяснить".

ВП>Приведу классическую цитату.
ВП>Эдвард Йодан писал:

ВП>

ВП>«Если это возможно, избегайте отрицаний в булевых выражениях.
ВП>Представляется, что их понимание представляет трудность
ВП>для многих программистов».

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

ВП>В данном случае Йодан выступает как Гуманист.
ВП>Он заботится о программистах и стремится облегчить их тяжелую работу.
ВП>Правильно ли поступает Эдвард Йодан? Думаю, что правильно.

ВП>Это только Фридрих Ницше говорил одиозное: "Падающего толкни".

ВП>Язык Дракон следует гуманистическим идеалам Йодана.
ВП>Надо избегать отрицаний в булевых выражениях.
ВП>Но почему только отрицаний? Трудности создают не только отрицания,
ВП>но и знаки конъюнкции и дизъюнкции.
Да что там, приведения типов создают трудности.

ВП>Можно ли обойтись в булевых выражениях без пропозициональных связок?
ВП>Язык дракон отвечает: можно и нужно.
На вопрос "можно ли" утвердительно ответит и Паскаль тоже. А на вопрос "нужно ли" не отвечает даже Дракон.

ВП>Степан Митькин показал Вам КАНОНИЧЕСКУЮ ФОРМУ визуальных пропозициональных формул,
ВП>в которой полностью исключены пропозициональные связки.
ВП>Вам это не понравилось. Вы, разумеется, правы.
ВП>Каждый человек имеет право работать как он привык и как ему удобнее.
Как же? Булевой алгебре 200 лет, блок-схемам еще нет 100. Канонической (традиционной) в данном случае является форма, введенная Булем.

ВП>Заметьте: Дракон не запрещает использовать пропозициональные связки.
ВП>Он лишь показывает, что наряду с традиционной формой существует и каноническая форма.

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

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

ВП>Язык ДРАКОН предлагает единый алгоритмический подход к различным предметным областям:
ВП>и к медицине, и к программированию, и к бизнес-процессам и к сельскому хозяйству и т.д.

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

Здравствуйте, Stepan Mitkin, Вы писали:

Перечитал ветку, появился ещё вопрос:

SM>- Конечные автоматы (это не только про микроконтроллеры. именно ДРАКОН даёт автоматам дорогу в остальлные отрасли программирования)

Конечные автоматы известны и применяются давно. Легко реализуются с помощью матриц. Применяются в программировании уже давно — например, при создании лексических анализаторов в компиляторах.
Поэтому прошу пояснить, что имеется в виду в предложении "именно ДРАКОН даёт автоматам дорогу в остальные отрасли программирования"?

Здравствуйте, AleksandrN, Вы писали:

AN>Конечные автоматы известны и применяются давно. Легко реализуются с помощью матриц. Применяются в программировании уже давно — например, при создании лексических анализаторов в компиляторах.
AN>Поэтому прошу пояснить, что имеется в виду в предложении "именно ДРАКОН даёт автоматам дорогу в остальные отрасли программирования"?

Размещаю ответ Степана Митькина:

Здравствуйте, AleksandrN, Вы писали:

AN>например, при создании лексических анализаторов в компиляторах.

Правильно! А ещё для парсеров.
Также они удобны для: хождения по деревьям/графам, управления гуём, управления долгими операциями ввода-вывода (например, в браузере) и много чего другого.

AN>Поэтому прошу пояснить, что имеется в виду в предложении "именно ДРАКОН даёт автоматам дорогу в остальные отрасли программирования"?

К сожалению, для большинства программистов конечные автоматы — экзотика.
Скажешь "класс" — кивают головой.
Скажешь "автомат" — морщат лоб, вспоминают универ. То есть каждый день автоматы не применяют.
Оно понятно. В языке C#, например, родной поддержки автоматов нет. А ДРАКОНовская конструкция "силуэт" прям как будто специально сделана для автоматов.

ДРАКОН чем тут хорош? На одной визуальной сцене есть:
1. Описание состояний и переходов.
2. Логика автомата (то есть принятие решений, чего делать. "если, то" и т.п.)

Доступненько тут:
http://drakon-editor.sourceforge.net/auto.html

Степан

Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Скажешь "автомат" — морщат лоб, вспоминают универ. То есть каждый день автоматы не применяют.
ВП>Оно понятно. В языке C#, например, родной поддержки автоматов нет. А ДРАКОНовская конструкция "силуэт" прям как будто специально сделана для автоматов.

Еще раз в C# есть yield который используется в куче итераторов. В том числе и для async await
Так что поддержка есть и используется в огромном числе итераторов для рекурсивного обхода деревьев и для асинхронного программирования.
Во всех случаях запоминается состояние и при вызове MoveNext переходит в новое состояние.

Так, что если не знают, это не значит, что не используют

Здравствуйте, Владимир Паронджанов, Вы писали:

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

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

Вот когда "ДРАКОН" или кто там ещё научится понимать постановку задачи "сделай мне чтобы как скайп, только цвета поприкольнее, и чтоб не тормозило.", тогда прорыв и случится.

Здравствуйте, 0x7be, Вы писали:

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

Таких людей очень много. Например, инженеры НПЦАП, где я работаю. Добавьте сюда (отчасти) программистов-любителей, то есть непрофессиональных программистов. Да и у профессионалов тоже есть трудности.

Вот цитата:

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

0>Более серьёзно по теме: по-моему все эти затеи с рисованием вместо писания решают не ту проблему. Проблема не в том, что алгоритм сложно записать. Проблема в том, что алгоритм сложно составить. Для этого надо иметь определенный набор интеллектуальных навыков, которые позволяют формализовать проблему и её решение. То есть перейти от неполного и неоднозначного описания на естественном языке к полному, однозначному и непротиворечивому описанию на формальном. Какой формальный язык не придумай — он останется формальным.
Вы высказываете очень интересные соображения. Спасибо.

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

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

Что касается визуального программирования, то оно делает лишь первые робкие шаги.
Здесь еще пахать и пахать. Тут я с Вами не могу согласиться. Вы говорите: "не сработало".

А я говорю: пока еще рано делать выводы. Цыплят по осени считают.

Что значит "рисовать"? Рисовать можно плохо. А можно хорошо.
Можно ли отличить плохое рисование от хорошего?
Плохое визуальное программирование от хорошего? Где критерий?

Одним из критериев является КОГНИТИВНАЯ ЭРГОНОМИКА.

Я согласен с Вами, что

"Проблема не в том, что алгоритм сложно записать.
Проблема в том, что алгоритм сложно составить".

Мое добавление. Чтобы облегчить сложную работу по составлению сложного алгоритма,
нужно создать не просто формальный язык, а ЭРГОНОМИЧНЫЙ ВИЗУАЛЬНЫЙ формальный язык.

ДРАКОН и является именно таким языком.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Что касается визуального программирования, то оно делает лишь первые робкие шаги.
ВП>Здесь еще пахать и пахать. Тут я с Вами не могу согласиться. Вы говорите: "не сработало".
ВП>А я говорю: пока еще рано делать выводы. Цыплят по осени считают.
Ну так продемонстрируйте это! Напишите хотя бы компилятор самого себя и пару крупных проектов.

Здравствуйте, Cyberax, Вы писали:

C>Ну так продемонстрируйте это! Напишите хотя бы компилятор самого себя и пару крупных проектов.

Такая работа уже давно проделана.
С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.

Цитирую:

Язык ДРАКОН и ДРАКОН-технология эксплуатируются в НПЦАП уже 20 лет (1996–2016 годы). За это время они помогли создать системы управления четырнадцати космических проектов:

— разгонный блок космических аппаратов ДМ-SL (проект «Морской старт»);

— модернизированная ракета-носитель тяжелого класса ПРОТОН-М;

— семейство разгонных блоков ФРЕГАТ, которое включает: просто ФРЕГАТ, ФРЕГАТ-СБ (со сбрасываемыми баками), ФРЕГАТ-УТТХ (с улучшенными тактико-техническими характеристиками), ФРЕГАТ-МT, предназначенный для запусков из Южной Америки, ФРЕГАТ-СУМ (с модернизированной системой управления);

— разгонный блок космических аппаратов ДМ-SLБ (проект «Наземный старт»),

— разгонный блок космических аппаратов ДМ-03,

— первая cтупень южнокорейской ракеты-носителя KSLV,

— три проекта семейства Ангара: ракета-носитель легкого класса АНГАРА-1.2 первого пуска, ракета-носитель легкого класса АНГАРА-1.2 с агрегатным модулем, ракета-носитель тяжелого класса АНГАРА-А5;

— разгонный блок КВТК (кислородно-водородный тяжелого класса) [5, с. 515].

Пуски ракет-носителей и разгонных блоков, при создании которых использовался язык ДРАКОН, производятся или производились с пяти космодромов мира:
— Плесецк,
— Байконур,
— Kuru (Французская Гвиана),
— плавучий космодром «Морской старт» (экваториальная зона Тихого океана),
— Naro (Южная Корея).

Я процитировал источник, опубликованный в 2016 году. Сегодня к списку космодромов следует добавить шестой космодром — Восточный.

Здравствуйте, Владимир Паронджанов, Вы писали:

C>>Ну так продемонстрируйте это! Напишите хотя бы компилятор самого себя и пару крупных проектов.
ВП>Такая работа уже давно проделана.
Не верю.

ВП>С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.
Покажите код.

Привожу цитату из статьи DRAKON английской Wikipedia
https://en.wikipedia.org/wiki/DRAKON

DRAKON is an algorithmic visual programming language developed within the Buran space project following ergonomic design principles. The language provides a uniform way to represent flowcharts of any complexity that are easy to read and understand.

The DRAKON Editor, which was released in September 2011, is an implementation of the language available in the public domain. It can be used for creating documentation, or for creating visual programs that can be converted to source code in other languages.

Unlike UML's philosophy, DRAKON language philosophy is based on being augmented if needed, by using a hybrid language, which can be illustrated as "eating code snippets from text language used". This way, DRAKON stays a simple visual language, that can, in fact, be used itself as an augmentation language for a programmer, who is interested in improving ergonomics of coding process or to make code easy to review and understand.

DRAKON is Russian acronym that says "Дружелюбный Русский Алгоритмический [язык], Который Обеспечивает Наглядность", i.e. "Friendly Russian algorithmic [language] that provides illustrativeness". The word "наглядность" (pronounced approximately as "naa-glya-dno-st-th") refers to a quality of concept or idea being easy to imagine and understand, and may be translated as "clarity" as well.

It is to note, that DRAKON language can be used both as modelling language (standalone use) and as programming language (use as part of a hybrid language). Such approach allows to view DRAKON as a way to add syntactic sugar into any supported programming language user programmer is qualified to use.

Contents [hide]

1 History
2 Family of DRAKON-languages (hybrid languages)
3 DRAKON's philosophy and purposes
4 Examples
4.1 Branching
4.2 Check-do (while) loop
4.3 Do-check (do-while) loop
5 DRAKON Editor
5.1 Features
6 Notes
7 References
8 External links

History[edit]

The development of DRAKON started in 1986 and was directed by Vladimir Parondzhanov with the participation of Russian Federal Space Agency (Academician Pilyugin Center, Moscow) and Russian Academy of Sciences (Keldysh Institute of Applied Mathematics). The language was constructed by formalization, ergonomization and nonclassical structurization of flowcharts described in the ISO 5807-85 standard and Russian standard «Гост 19.701-90» and for the development of real time programs.[1][2]

The goal was to replace specialised languages PROL2 (ПРОЛ2) (assigned for developing onboard complex software for embedded computer system Biser-4 (Бисер-4) on board of Buran),[3] DIPOL (ДИПОЛЬ) (assigned for developing software for ground maintenance computer system of Buran)[3] and LAKS (ЛАКС) (assigned for modelling) used in the Buran project with one universal programming language.

The work was finished in 1996 (3 years after the Buran project was officially closed), when an automated CASE programming system called "Grafit-Floks" was developed.[4]

This CASE is used since 1996 in many major space programs: an international project Sea Launch, Russian orbit insertion upper stage Fregat (Russian: Фрегат, frigate),[5] upgraded heavy launch vehicle (carrier rocket) Proton-M, etc.

DRAKON rules for creating diagrams are cognitively optimized for easy comprehension, making it a tool for intelligence augmentation.[1][6][7][8]

Family of DRAKON-languages (hybrid languages)[edit]

Icons of DRAKON language

Macroicons of DRAKON language.

DRAKON (Russian: ДРАКОН) is designed with humanistic ideas in mind, as usage of three different languages for the same project was a source of human factor-related hardships such risks of having a mutual misunderstanding.

DRAKON is used not as a single stand-alone language but as a family of hybrid languages, such as DRAKON-C, DRAKON-ASM, DRAKON-Java, etc. All hybrid languages of the DRAKON-family have the uniform graphical syntax, based on flowcharts. The standard graphical syntax provides similarity of drakon-charts for different hybrid languages. The text language used uses its own syntax.

Strict distinction of the graphical and textual syntax along with rich graphics improves flexibility and variety of expressive means of the language. The unification of the rules of the graphical syntax in the hybrid languages secures their conceptual unity.

The basis of the graphical syntax is a graphical alphabet. Graphical elements (graphical letters) of the DRAKON alphabet are called icons (not symbols). There are 27 icons in the DRAKON graphical alphabet.

DRAKON has not only icons, but also macroicons. Macroicons are the graphical words of the DRAKON language. Just as words are made up of letters, macroiсons (graphical words) consist of the icons (graphical letters). There are 21 macroicons in the DRAKON language.

Icons and macroiсons are the building blocks for constructing drakon-charts.

The important parts of maсroiсons are valence points (in the illustration to the right, they are depicted as little black circles). Into these points, icons or microicons can be successively entered and arranged by drakon-editor in neat, orderly vertical rows.

DRAKON's philosophy and purposes[edit]

DRAKON was created as a language with a set of rules that would allow to depict algorithms in fields, not necessarily related to computing, being easy to learn. The main reason that led to the development of the language was emerging risk of misunderstanding, and following errors upon interaction between different programming languages (namely, DIPOL, LAX and PROL2).

DRAKON serves as an easy to use tool, that improves communication between programmers, who mastered different programming languages: drakon-chart, by being closely similar to a traditional flowchart (yet with additional functionality for text language code, such as code snippeds, provided a hybrid is used) allows to produce and keep readable flowchart at hand simultaneously with process of making the program in question.

DRAKON is notable for being used without programming language syntax, but with spoken language, for illustrative purposes. Namely, in the medicine field in Russia as a way to compose flowchart-like algorithms, that both create a map-like gide for patients and form instructions for medical personnel.

Sometimes DRAKON icons are being modified by inserting a photo as icon's filler under the text, forming a sort of formally strict and easy to modify infographics.

Read more: https://en.wikipedia.org/wiki/DRAKON

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Привожу цитату из статьи DRAKON английской Wikipedia
Спасибо, я поправил Вики.

ВП>https://en.wikipedia.org/wiki/DRAKON
Код мне покажите, код. Хватит уже цитат самого себя.

Что сложного-то написать хотя бы компилятор себя? Тем более, что ДРАКОН в текущем виде — это просто препроцессор, без реальной логики.

Рассказываю как это делают другие проекты. Например, возьмём язык Rust — он основан в 2010-м году и предназначен для создания надёжных систем.

Первая версия была на OCaml'е, но уже через год компилятор была переписан на сам Rust.

Первый крупный проект (Servo) был начат в 2012-м году и к 2014-му году уже начал быть полезным на практике. К 2016-му году имеются тысячи проектов сторонних разработчиков (https://crates.io/).

В 2015-м году начат проект по статическому доказательству правильности небезопасных частей стандартной библиотеки ( http://plv.mpi-sws.org/rustbelt/ ). Параллельно идёт проект по переформулировке системы типов в виде логических утверждений с возможностью автоматического доказательства их корректности ( https://github.com/nikomatsakis/chalk ).

Здравствуйте, Cyberax, Вы писали:

C>Код мне покажите, код.

Я уже отвечал на такой вопрос:

Дата: 29.05.17 19:15
Здравствуйте, AleksandrN, Вы писали:

AN>прошу выложить какие-нибудь исходники реального ПО на Драконе, а не учебных примеров. Среда разработки и компилятор Дракона написаны на Драконе? Где можно посмотреть исходники?

Я работаю в НПЦАП им. акад. Н.А. Пилюгина (свыше 56 лет). Это закрытый научно-производственный центр. Исходники я выложить, к сожалению, не могу. Не имею права.

Спасибо за информацию по Rust.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Такая работа уже давно проделана.
ВП>С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.

Так у вас же и алгоритм управления дверным замком "сложный" с ваших слов. Нет ли у поклонников Дракона тенденции гипертрофировать сложность и размер задач, как это видно на примерах с логическими выражениями и сортировкой?
У Маска ведь как-то что-то летает без 20-и лет разработок и сверхкрупных программных проектов...

Можно узнать критерии, по которымм вы оцениваете проекты как сверхкрупные? LOC, или там, человеко-часы... Хотя, человеко-часы не надо. Просто я работал в одном ядерном НИИ. Там тоже делали сверхкрупные проекты, умудряясь коллективом из 5и активных разработчиков создавать двухнедельную очередь в тетради на обладание дискетой, на которой был файл с определением глобальных переменных проекта. В этом веке, кстати.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Такая работа уже давно проделана.
ВП>С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.

Грандиозность и сверхкрупность это сколько строк кода и сколько элементов на схемах Дракона?

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

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

P.S. Вы изучаете, как работают конкуренты? На habrahabr есть интересная статья 10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками (перевод). Нашёл ещё 2 интресных документа: JPL Institutional Coding Standard for the C Programming Language и NASA Software Safety Guidebook.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Я работаю в НПЦАП им. акад. Н.А. Пилюгина (свыше 56 лет). Это закрытый научно-производственный центр. Исходники я выложить, к сожалению, не могу. Не имею права.
Я уже это слышал. Потому повторяю, вы врёте про то, что ДРАКОН для чего-то существенного используется и просто прикрываетесь "секретностью".

Иначе за 6 лет могли бы потратить пару месяцев на то, чтобы продемонстрировать всю крутизну, написав ХОТЯ БЫ ОДИН существенный публичный проект.

Здравствуйте, AleksandrN, Вы писали:

AN> вы позиционируете Дракон как инструмент для создания ПО для любой цели и утверждаете, что ваш подход лучше, чем другие технологии.

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

Во избежание недоразумений, позвольте мне заново сформулировать свою позицию.

1. Нотация Дракона лучше, чем другие нотации для записи АЛГОРИТМОВ (именно алгоритмов, а не программ).

2. Существующие нотации для записи алгоритмов (именно алгоритмов, а не программ) уступают нотации ДРАКОНа.

3. Исходя из этого, я делаю предположение (или, что одно и то же, выдвигаю гипотезу), что использование нотации ДРАКОНа в области программирования может дать заметные преимущества. Я отчетливо сознаю, что разработка новых технологий программирования на основе нотации ДРАКОНа — это очень большая работа, которая займет многие годы или даже десятилетия.

4. Но я верю, что рано или поздно найдутся энтузиасты, которые примут близко к сердцу идею ДРАКОНа, поверят в нее и дадут ей путевку в жизнь.

AN>Если хотите убедить всех в преимуществах Дракона перед другими технологиями — нужно что-то больше, чем учебные примеры и рассказы о применении. Создайте на Драконе инструменты для программирования на Драконе. Степан Митькин некоторые такие инстументы создал, но их недостаточно. Сделайте библиотеки для работы с, часто используемыми, структурами данных — связанными списками, бинарными деревьями, строками. Сделайте библиотеки для, часто возникающих, задач — работа с сетью, потоками, файлами, GUI, БД, временем (с учётом часовых поясов). Сделайте средства инеграции с системами контроля версий, что бы можно было посмотреть когда и какие изменения вносились в схему. Выложите исходники всех этих библиотек. Если Дракон имеет преимущества, то весь этот код скажет о них лучше, чем множество слов и учебных примеров. Да и обсуждение вашей технологии будет более предметным и можно будет лучше понять преимущества и недостатки вашего подхода к разработке ПО.

Вы говорите дельные вещи и я полностью согласен с Вашими соображениями.
Для реализации этого нужны молодые силы и соответствующие ресурсы.
Мне 79 лет и мои силы ограничены.

Я вижу свою задачу в том, чтобы написать еще несколько книг про язык ДРАКОН и передать эстафету молодежи.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>1. Нотация Дракона лучше, чем другие нотации для записи АЛГОРИТМОВ (именно алгоритмов, а не программ).
Очень может быть. С поправкой — другие ГРАФИЧЕСКИЕ нотации.

ВП>2. Существующие нотации для записи алгоритмов (именно алгоритмов, а не программ) уступают нотации ДРАКОНа.[/b]
Аналогично.

ВП>3. Исходя из этого, я делаю предположение (или, что одно и то же, выдвигаю гипотезу), что использование нотации ДРАКОНа в области программирования может дать заметные преимущества. Я отчетливо сознаю, что разработка новых технологий программирования на основе нотации ДРАКОНа — это очень большая работа, которая займет многие годы или даже десятилетия.[/b]
А вот тут нет. Современное программирование практически никогда не имеет дело с графическим представлением алгоритмов. Ибо это никому не нужно. Первоначальный дизайн алгоритма чаще всего делают на бумажке на псевдокоде в текстовом виде. Графически представлять алгоритмы требуется крайне редко. Графическое представление имеет смысл для общей архитектуры системы, это реально бывает полезно.
Проблема графического представления следующая. Простой алгоритм одинаково легко читается как в графическом представлении, так и в текстовом. Но текстовое представление всегда более компактное. Для текстового представления можно сделать diff, то есть видно что когда поменял ранее. И кстати, современное текстовое представление программ де факто является еще и графическим. Ибо путем хорошего форматирования добиваются понятности, плюс современные среды разработки еще дополнительно стараются выделить важные элементы, например другим шрифтом, другим цветом и т.д, зачастую прямо в IDE делают преобразование каких то громоздких конструкций в гораздо более читаемый вид. То есть именно в программировании сейчас никаких революций именно в нотациях не сделать. Можно только эволюционно делать уже существующее все более и более удобным, что собственно делается и делается весьма успешно.

ВП>4. Но я верю, что рано или поздно найдутся энтузиасты, которые примут близко к сердцу идею ДРАКОНа, поверят в нее и дадут ей путевку в жизнь.[/b]
Вполне возможно. Но только не в программировании! Современное программирование ОЧЕНЬ отличается от того программирования, которое было 30 лет назад. Очень отличается даже от того программирования, которое было 10 лет назад. И будет отличаться от того программирования, которое будет через 10 лет. Здесь революции делаются за годы, и зачастую по ряду причин здесь не взлетают гораздо более перспективные идеи.

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

.

А именно в программировании сейчас и так все достаточно неплохо, и будет еще лучше

Для тех, кто хочет познакомиться с языком ДРАКОН, сообщаю:

1. Скачайте мою книгу http://drakon.su/_media/01._parondzhanov_uchis_pisat_chitat_i_ponimat_algoritmy.pdf

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

2. Чтобы сократить затраты вашего драгоценного времени, можно читать выборочно, например:

— стр. 255-266 Глава 16. Коротко о программировании.

— стр. 293-300 Глава 20. Алгоритмы бухгалтерского учета.

— стр. 393-424 Часть VI. Конструктор алгоритмов и формальное описание языка.

— стр. 425-472 Часть VII. Теоретические основы языка ДРАКОН.

Все имеющиеся инструментальные средства созданы на основе этой книги.
http://forum.drakon.su/viewforum.php?f=151

Здравствуйте, elmal, Вы писали:

ВП>>1. Нотация Дракона лучше, чем другие нотации для записи АЛГОРИТМОВ (именно алгоритмов, а не программ).
E>Очень может быть. С поправкой — другие ГРАФИЧЕСКИЕ нотации.

Не могу согласиться с этой поправкой.

ВП>>2. Существующие нотации для записи алгоритмов (именно алгоритмов, а не программ) уступают нотации ДРАКОНа.[/b]
E>Аналогично.

Не могу согласиться с этим замечанием.

ВП>>3. Исходя из этого, я делаю предположение (или, что одно и то же, выдвигаю гипотезу), что использование нотации ДРАКОНа в области программирования может дать заметные преимущества. Я отчетливо сознаю, что разработка новых технологий программирования на основе нотации ДРАКОНа — это очень большая работа, которая займет многие годы или даже десятилетия.[/b]

E>А вот тут нет. Современное программирование практически никогда не имеет дело с графическим представлением алгоритмов. Ибо это никому не нужно.

Вы правы. Сегодня не нужно. Потому что почти никто не знает, что есть альтернатива (дракон).

E>Первоначальный дизайн алгоритма чаще всего делают на бумажке на псевдокоде в текстовом виде.

Вы правы. Но это плохо.

E>Графически представлять алгоритмы требуется крайне редко. Графическое представление имеет смысл для общей архитектуры системы, это реально бывает полезно.

Вы правы. Такова практика. Но это устаревшая практика.

E>Проблема графического представления следующая. Простой алгоритм одинаково легко читается как в графическом представлении, так и в текстовом.

Вы правы. Но вся суть в сложных алгоритмах.

E>Но текстовое представление всегда более компактное.

Вы правы. Компактность важное качество. Но не самое главное. Безошибочность важнее.

E>Для текстового представления можно сделать diff, то есть видно что когда поменял ранее.

Вы правы. Это очень важно.

E>И кстати, современное текстовое представление программ де факто является еще и графическим. Ибо путем хорошего форматирования добиваются понятности, плюс современные среды разработки еще дополнительно стараются выделить важные элементы, например другим шрифтом, другим цветом и т.д, зачастую прямо в IDE делают преобразование каких то громоздких конструкций в гораздо более читаемый вид.

Вы правы. Но возможности такого способа очень ограничены.

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

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

ВП>>4. Но я верю, что рано или поздно найдутся энтузиасты, которые примут близко к сердцу идею ДРАКОНа, поверят в нее и дадут ей путевку в жизнь.[/b]

E>Вполне возможно. Но только не в программировании!

Не могу согласиться.

E>Современное программирование ОЧЕНЬ отличается от того программирования, которое было 30 лет назад. Очень отличается даже от того программирования, которое было 10 лет назад. И будет отличаться от того программирования, которое будет через 10 лет.

Вы правы. Согласен с Вами.

E>С ДРАКОНом лучше идти, например, к юристам, бухгалтерам. Описывать алгоритмы получения какой либо справки, или алгоритмы начисления налогов, или просто правила ПДД, воинские уставы и тому подобное.

Вы правы. Я полностью согласен с Вами.

E>И на уровне конституции прописать максимальную степень запутанности определенных законов и тому подобному. Вот здесь реально непаханное поле. То, что есть сейчас — это текстовое многословное и зачастую противоречивое представление, в котором крайне проблематично разобраться. И этот бардак не меняется не то, что десятилетиями. А столетиями, а то и вообще хуже становится. Вот здесь графическое представление вполне могло бы помочь. Возможно юристов оно и устраивает, они привыкли к этому многословию. А вот для простых граждан очень бы хотелось чего попроще, с картинками

.

Вы правы. Согласен с Вами.

E>А именно в программировании сейчас и так все достаточно неплохо, и будет еще лучше

.

В этом пункте с Вами согласны не все.
Цитирую:

"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".

Источник:
Ильин В.П. Вычислительная математика и информатика: Мировые вызовы и Российская "Дорожная карта". // Вестник Российской академии наук, 2015, том 85, №2. — С. 107-114.

Для распространения идей языка ДРАКОН важную роль может сыграть система образования и университеты.
Сегодня в этой области дела обстоят неблагополучно.

Преподавание ведется (если ведется) лишь в единичных университетах, причем явно недостаточно.
Вот один из примеров.
Цитирую:

http://skado.dissw.ru/media/docs/2/52/19273/rpd_01.04.02_mm_b1.v.dv.08.02_prostranstvenno-atributnye%20modeli%20i%20gis-tehnologii_0HOJF57.pdf

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Кемеровский государственный университет»
Новокузнецкий институт (филиал)
федерального государственного бюджетного образовательного учреждения
высшего образования
«Кемеровский государственный университет»

Факультет информационных технологий

Кафедра Математики и математического моделирования

УТВЕРЖДАЮ
Декан ____ В.О. Каледин
"11" марта 2016 г.

Рабочая программа дисциплины
Б1.В.ДВ.8.2 Инструментальные средства визуального программирования
Направление подготовки

01.04.02 Прикладная математика и информатика
Направленность (профиль) подготовки
«Математическое моделирование»

Программа академической магистратуры

Квалификация выпускника
Магистр

Форма обучения
Очная

Новокузнецк 2016

Стр. 5

2.

Визуальное программирование в ИС ДРАКОН

Язык ДРАКОН и его визуальный синтаксис. Дракон-схемы и их преимущества.
Визуализация циклических алгоритмов. Визуализация
логических формул.
Интегрированная среда ДРАКОН.
Примеры алгоритмов для различных отраслей знаний.
Алгоритмы и формализация профессиональных знаний.

ОПК-1

уметь:
генерировать и продвигать новые идеи применения инструментальных средств ДРАКОН

владеть:
опытом участия в научных и научно-практических конференциях, посвященных современным инструментальным средствам визуального программирования

П-11

знать:
историю развития информационных технологий – предпосылки появления языка ДРАКОН

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

Здравствуйте, Владимир Паронджанов, Вы писали:

E>>А вот тут нет. Современное программирование практически никогда не имеет дело с графическим представлением алгоритмов. Ибо это никому не нужно.
ВП>Вы правы. Сегодня не нужно. Потому что почти никто не знает, что есть альтернатива (дракон).
Иногда "не нужно" это именно "не нужно", а не что-то другое.

E>>Первоначальный дизайн алгоритма чаще всего делают на бумажке на псевдокоде в текстовом виде.
ВП>Вы правы. Но это плохо.
Лучше сразу делать его в ИДЕ и запускать на исполнение.

E>>Проблема графического представления следующая. Простой алгоритм одинаково легко читается как в графическом представлении, так и в текстовом.
ВП>Вы правы. Но вся суть в сложных алгоритмах.
Тут графическое представление никак не поможет.
Особенно если алгоритм не просто сложный, а ещё и оптимизированный.

ВП>Вы правы. Компактность важное качество. Но не самое главное. Безошибочность важнее.
Безошибочность достигается другими средствами.
Например, вот такими:
Dafny доказательство сортировки выбором.

E>>И кстати, современное текстовое представление программ де факто является еще и графическим. Ибо путем хорошего форматирования добиваются понятности, плюс современные среды разработки еще дополнительно стараются выделить важные элементы, например другим шрифтом, другим цветом и т.д, зачастую прямо в IDE делают преобразование каких то громоздких конструкций в гораздо более читаемый вид.
ВП>Вы правы. Но возможности такого способа очень ограничены.
Они более чем достаточны.

E>>А именно в программировании сейчас и так все достаточно неплохо, и будет еще лучше

.

ВП>В этом пункте с Вами согласны не все.
ВП>Цитирую:

ВП>"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".
Только дракон не является решением.
Для того чтобы поднять производительность программистов нужно уменьшить количество сущностей в программе. В идеале там должны быть только сущности предметной области.
Например, вот этот код:
1)Разбирает текстовое представление арифметических выражений.
2)Вычисляет значение выражения.
3)Генерирует качественные сообщения об ошибках.
4)Может быть встроен в текстовый редактор, в котором будет обеспечена подсветка кода и ошибок в реальном времени.

  syntax expr
  {
    Value() : double;
    missing Value = double.NaN;

    | [SpanClass(Number)]
      num        = number              { override Value = Number.Value(); }
    | rounds     = '(' expr ')'        { override Value = Expr.Value(); }

    precedence Additive:
    | add        = expr sm '+' sm expr { override Value = Expr1.Value() + Expr2.Value(); }
    | sub        = expr sm '-' sm expr { override Value = Expr1.Value() - Expr2.Value(); }

    precedence Multiplicative:
    | mul        = expr sm '*' sm expr { override Value = Expr1.Value() * Expr2.Value(); }
    | div        = expr sm '/' sm expr { override Value = Expr1.Value() / Expr2.Value(); }
    | mod        = expr sm '%' sm expr { override Value = Expr1.Value() % Expr2.Value(); }

    precedence Power:
    | pow        = expr sm '^' sm expr right-associative
                                       { override Value = System.Math.Pow(Expr1.Value(), Expr2.Value()); }

    precedence Unary:
    | neg        = '-' expr            { override Value = -Expr.Value(); }
}

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".

ВП>Источник:
ВП>Ильин В.П. Вычислительная математика и информатика: Мировые вызовы и Российская "Дорожная карта". // Вестник Российской академии наук, 2015, том 85, №2. — С. 107-114.

Эта мысль посетила не только Ильина. Схожие мысли высказывались уже давно и высказываются до сих пор.

Фредерик Брукс ещё в 1986 году написал статью "Серебряной пули нет", в которой утверждал "ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту". В, переизданной в 90-х своей книге "Мифический человеко-месяц" Брукс писал, что несмотря на то, что индустрия сильно развилась со времён первого издания книги, серебряной пули всё ещё нет. И как мы видим — этой пули нет до сих пор. И Дракон тоже не является "серебряной пулей".

Здравствуйте, AleksandrN, Вы писали:

ВП>>"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".

ВП>>Источник:
ВП>>Ильин В.П. Вычислительная математика и информатика: Мировые вызовы и Российская "Дорожная карта". // Вестник Российской академии наук, 2015, том 85, №2. — С. 107-114.

AN>Эта мысль посетила не только Ильина. Схожие мысли высказывались уже давно и высказываются до сих пор.

AN>Фредерик Брукс ещё в 1986 году написал статью "Серебряной пули нет", в которой утверждал "ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту". В, переизданной в 90-х своей книге "Мифический человеко-месяц" Брукс писал, что несмотря на то, что индустрия сильно развилась со времён первого издания книги, серебряной пули всё ещё нет. И как мы видим — этой пули нет до сих пор. И Дракон тоже не является "серебряной пулей".

Вы правы. Я согласен с Вами целиком и полностью.
Я согласен, что «Дракон тоже не является "серебряной пулей"».

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

Я использовал аккуратное выражение: Дракон обещает дать заметное преимущество в программировании.

Согласитесь, что это намного скромнее, чем "серебряная пуля", которая, по Бруксу, "увеличивает на порядок производительность, надёжность и простоту".

Уважаемые коллеги!

Благодарю всех, кто принял участие в обсуждении и высказал критические замечания.
Ваша критика представляет для меня (и не только для меня) огромную ценность.
Критика — воздух науки.

НОВАЯ ИДЕЯ

Дракон — это новая идея, которая нуждается в обсуждении, развитии и дальнейших научных исследованиях.

ПРИГЛАШАЮ ЖЕЛАЮЩИХ НАПИСАТЬ И ЗАЩИТИТЬ ДИССЕРТАЦИЮ

Приглашаю желающих принять участие в научно-исследовательской работе по развитию языка ДРАКОН, смежным вопросам и разработкам.
Цель — по результатам научных исследований написать и защитить диссертацию на соискание ученой степени кандидата или доктора наук.
Я готов вам всячески помогать.

Литературу можно скачать здесь:
http://drakon.su/knigi_vladimira_parondzhanova._skachat

Для оперативной связи сообщаю свои данные:

Владимир Данилович Паронджанов
Тел: 8-916-111-91-57
Viber: 8-916-111-91-57
E-mail: vdp2007@bk.ru
Скайп: facebook:vdp2007
Сайт: http://drakon.su/
Форум: http://forum.drakon.su/

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

Можно начать и с организации кружка в ближайшей школе.

Желаю успехов.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Цитирую:
ВП>

ВП>Язык ДРАКОН и ДРАКОН-технология эксплуатируются в НПЦАП уже 20 лет (1996–2016 годы). За это время они помогли создать системы управления четырнадцати космических проектов:

Правильно понимаю, что Дракон в этих проектах использовался только как нотацию для записи и возможно документирования алгоритмов?

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

Здравствуйте, pagid, Вы писали:

P>Правильно понимаю, что Дракон в этих проектах использовался только как нотацию для записи и возможно документирования алгоритмов?

P>Мне показалось, что спорящие с Вами пытаются увидеть в нем язык программирования, и совершенно зря.

1.Нет, неправильно. В НПЦАП ДРАКОН используется как язык программирования для разработки программ реального времени для бортового и наземного компьютера Бисер, разработанного в НПЦАП.

Разумеется, язык программирования ДРАКОН, используемый в НПЦАП, заточен для выполнения специфических функций ракетной техники. Он не обладает такими обширными функциями, как известные языки.

2. Я бы не делал особый акцент на варианте ДРАКОНа в НПЦАП. Дело не в этой частной и закрытой разработке. Дело в книгах, где я все подробно описал.

Я дал ссылки на литературу, где идея ДРАКОНа описана подробнейшим образом. Прочитав литературу, каждый будет обладать полным объемом имеющейся информации и сможет, если захочет, разработать свой вариант системы.

Никто из имеющихся разработчиков, создавших ДРАКОН-конструкторы, ни Генннадий Тышов, ни Степан Митькин, ни Эдуард Ильченко, ни Олег Гарипов, ни Артем Бразовский не были в НПЦАП и не знают, какая кухня там варится. Это совершенно не важно.

Все они руководствовались имеющейся открытой литературой, выложенной на сайте drakon.su
И на форуме forum.drakon.su
Разумеется, эти книги изданы и бумажном виде и продаются в книжных магазинах.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>1. Скачайте мою книгу http://drakon.su/_media/01._parondzhanov_uchis_pisat_chitat_i_ponimat_algoritmy.pdf

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

Здравствуйте, pagid, Вы писали:

P>Альбом блок-схем в ДРАКОНовской нотации на все случаи жизни и слегка приближенных к жизни. А смысл в чем, изучение нотации на жизненных примерах? А дальше что? На вопрос зачем это же не отвечает.

Спасибо за очень интересный вопрос. Я отвечу на вопрос "Зачем?" для случая медицины.

Отвечу не сам, а приведу мнения врачей.

ОТЗЫВЫ ВРАЧЕЙ О ЯЗЫКЕ ДРАКОН

Доктор медицинских наук A. Кудрявичене, неонатолог:

«Язык ДРАКОН – отличный инструмент для обучения практическим навыкам и их стандартизации. Он позволяет выявить все, даже мельчайшие, но очень важные действия» [22, с. 316].

Доктор медицинских наук , профессор M. Ключинскас, акушер-гинеколог:

«Язык ДРАКОН позволяет систематизировать процессы с минимальным применением текста – как при организации работы, так и при выполнении медицинских процедур. Он помогает всем одинаково понимать и выполнять конкретные действия… Позволяет ускорить запоминание действий» [22].

Доктор медицинских наук, профессор Ж. Дамбраускас, абдоминальный хирург:

«Огромным преимуществом языка ДРАКОН является то, что он позволяет конкретно выявить все этапы процедуры или процесса… Мысленно можешь повторить процесс этап за этапом, а затем каждый этап разделить на шаги… Процедуру или процесс можно выполнить мысленно, а затем и в реальности. ДРАКОН является инструментом мысленной тренировки» [22, с. 315].

Врач Б. Кумпайтене, анестезиолог-реаниматолог:

«Польза языка ДРАКОН для разрабатывающего алгоритм автора состоит в том, что проявляется, кристаллизуется и стандартизируется каждый навык, каждая процедура. Польза для обучающегося – это ясный путь выполнения действий. ДРАКОН дает ответ на вопросы “что делать, если”» [22, с. 316].

А. Вилейките:

«Применение языка ДРАКОН позволяет стандартизировать и эргономично представить самую сложную процедуру… Если всё правильно описано на ДРАКОНе, значит, всё будет отлично выполнено» [22, с. 316].

Доктор медицинских наук, профессор Динас Вайткайтис, зав. кафедрой экстремальной медицины:

«Язык ДРАКОН даёт ясность и чёткость процессам, применяемым в медицине. Он позволяет “автоматизировать” обучение студентов практическим навыкам. Может стать основой для технологии принятия клинических решений» [22, с. 314].

Доктор медицинских наук, П. Добожинскас, исполнительный директор медицинского Центра:

«Применение языка ДРАКОН действенно помогает в создании и описании сложных, динамичных решений медицинских проблем. Тем самым значительно облегчается проведение стандартизированного симуляционного обучения, внедряя культуру безопасности пациентов и принципы качественного оказания медицинских услуг в масштабах медицинского учреждения, региона или государства» [22, с. 314].

Доктор медицинских наук, профессор Р.Й. Надишаускене, зав. клиники акушерства и гинекологии:

«Алгоритмизация медицины подразумевает значительную перестройку системы медицинского образования и перевод ее на алгоритмический путь… Накопленный в Литве практический положительный опыт использования языка ДРАКОН для представления сложных и разнообразных медицинских алгоритмов может послужить серьезной основой для принятия крупных структурных решений руководителями здравоохранения и системы медицинского образования в области алгоритмизации медицины» [22, с. 317].

Доклад «Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН»

Месяц назад, 19 мая 2017 года, состоялся Доклад Владимира Паронджанова на семинаре в Институте системного программирования Российской академии наук

Вступительное слово произносит
Заместитель директора Института системного программирования РАН,
Зам. главного редактора журнала "Программирование" Российской академии наук
доктор физико-математических наук, профессор
Александр Константинович Петренко.

Длительность видеоролика 2 часа 38 минут

https://www.youtube.com/watch?v=MFPqCqcv7kY

скажите, как на картинку 2017-го года проникли ДИСКЕТЫ (кстати, что это такое?)

Правильно ли я понимаю, что это происходит потому, что российские производители дискет не освоили выпуск флешек и карт памяти?

Где купить российскую дискету и устройство чтения/записи дискет российскийского производства?

Хотелось бы ещё уточнить технологию получения твёрдых копий.

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

Лазерная гравировка приводит к повреждению и последующему отслаиванию верхнего слоя со временем,
такая же проблема у термоштамповки самонаборными штампами.
Чернила недолговечны, недаром их не использовали в Нижнем Новгороде (менее 3 случаев на тысячу).

Как Вы решали эту проблему — увеличением штата переписчиков или при помощи Дракон-программ?

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>скажите, как на картинку 2017-го года проникли ДИСКЕТЫ (кстати, что это такое?)

Арсен, картинка сделана давно. Сегодня, конечно, используются флешки.

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>скажите, как на картинку 2017-го года проникли ДИСКЕТЫ (кстати, что это такое?)

Ну, хоть не перфокарты, и то хлеп.

Британская вещательная корпорация BBC
выпустила видеоролик и статью о языке ДРАКОН:

https://www.bbc.com/russian/features-48583773

Космический ДРАКОН.
Как заброшенный проект "Роскосмоса"
подарил язык литовской медицине

Николай Воронин
Корреспондент Русской службы ВВС по вопросам науки

"Переходим к искусственной вентиляции легких! — девушка лет 20 отрывается от планшета, переводя взгляд на неподвижно лежащего перед ней мужчину. — Начали!"

На лицо пострадавшего мгновенно ложится кислородная маска. Груша приходит в движение.

"Раз... Два... Три..." — с каждым нажимом в грудь пациента устремляется живительная струйка воздуха.

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

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

Мы в симуляционном классе Гибридной лаборатории клиник Литовского университета здравоохранения в Каунасе. Здесь обучают навыкам экстренной медицины: от оказания первой помощи при травмах до приема сложных родов и проведения эндоскопических операций.

Однако, в отличие от традиционных медицинских курсов, тут нет преподавателей или инструкторов. Студенты отрабатывают медицинские навыки самостоятельно, в тройках: один оказывает помощь, другой ее оценивает, третий ("пациент") просто наблюдает за процессом со стороны. Затем они меняются ролями — и все повторяется заново.

HYBRIDLAB

Инструктора заменяет планшет с подробным пошаговым алгоритмом, написанным на языке ДРАКОН, который позволяет "автоматизировать" обучение, максимально просто и понятно описав любой, даже самый сложный процесс. Так, чтобы исключить возможность путаницы — и, соответственно, врачебных ошибок.

Гибридное обучение с использованием драконных алгоритмов произвело настоящую революцию в медицинском образовании. На Всемирной выставке систем экстренной врачебной помощи в 2017 году литовская методика была представлена в номинации "инновация года".

И вот тут начинается самое интересное. Дело в том, что ДРАКОН — отнюдь не собственное изобретение литовских медиков, а наследие еще советской космической программы, ее побочный продукт. И изначально разрабатывался он совсем не для медицинских алгоритмов, а как язык программирования для бортового компьютера орбитального корабля "Буран".

Но — обо всем по порядку.

"Буран" на старте

Дружелюбный алгоритм

Космическая программа "Энергия — Буран" должна была стать достойным ответом Советского Союза американскому проекту "Спейс шаттл". Предполагалось, что "Буран" будет кораблем многоразового использования (челноком), чтобы доставлять космонавтов и грузы на орбиту и возвращать их обратно.

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

Так появился язык ФЛОКС — Формализованное Логическое Описание Команд и Сигналов. Именно он лег в основу программного обеспечения бортового компьютера БИСЕР-4, который выводил советский челнок на орбиту. Свой первый полет "Буран" совершил в 1988 году, в беспилотном режиме, — и благополучно вернулся на Землю.

Это был безусловный триумф советской космонавтики, однако продлился он недолго. Хотя корабль и был рассчитан примерно на 100 запусков, вскоре из-за распада Советского Союза и последовавшего экономического кризиса программу заморозили, а в 1993 году и вовсе закрыли.

Первый полет "Бурана" оказался последним.

Тем не менее автор ФЛОКСа, сотрудник "Роскосмоса" Владимир Паронджанов, продолжил работу над новым перспективным языком в рамках других проектов. А вскоре придумал своему детищу более подходящее и звучное название: ДРАКОН.

"ДРАКОН" расшифровывается как Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность", — объясняет Паронджанов. — Причем слово "русский" здесь означает только то, что он сделан в России. Потому что, какой язык используется на самом деле — русский, английский или еще какой, — не играет никакой роли".

Владимир Паронджанов написал о ДРАКОНе полтора десятка книг

Сейчас Паронджанову уже 80 лет. 58 из них он проработал в космической отрасли — на пенсию вышел только осенью прошлого года. За последние три десятилетия на созданном им визуальном языке ДРАКОН выросло немало проектов "Роскосмоса".

В конце 90-х с помощью ДРАКОНа был создан плавучий космодром "Морской старт" — совместный проект России, США, Украины и Норвегии. Тот же язык использовался, в частности, при разработке ракеты-носителя тяжелого класса "Протон-М" и разгонного блока космических аппаратов "Фрегат".

Превратить сложное в простое

В отличие от большинства языков программирования, понятных только компьютерам (набор команд автоматически переводится в машинный код и обрабатывается процессором) и людям со специальным образованием, ДРАКОН изначально разрабатывался именно как визуальный алгоритмический язык, для наглядного объяснения.

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

Именно поэтому драконный алгоритм так не похож на обычный машинный код и на вид напоминает обычную блок-схему.

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

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

Методик составления графических алгоритмов в мире множество — понятно, что разбивать процесс на части и указывать последовательность шагов придумали далеко не только в "Роскосмосе". Есть даже утвержденный в 1985 году международный стандарт.

Впрочем, по словам Паронджанова, язык ДРАКОН "превосходит по качеству любые другие графические аналоги".

"В международном стандарте блок-схем алгоритмов есть ряд важных недостатков, — объясняет разработчик. — Там слишком многое разрешено, отсутствует строгая формализация. Этот стандарт допускает хаотическое изображение алгоритма — схема получается запутанной. ДРАКОН же вводит жесткую формализацию, опираясь на принципы когнитивной эргономики".

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

"Этот язык устраняет хаос и превращает его в порядок, — уверен разработчик. — Он более удобен. Он превращает сложное в простое".

С такой оценкой в целом согласен доцент департамента информатики ВШЭ-Санкт-Петербург Тимофей Брыксин — хоть и с важной оговоркой: по его словам, "говорить о какой-либо научности этого языка сложно".

Тем не менее, когда несколько лет назад вместе со своими коллегами с кафедры системного программирования СПбГУ Брыксин занимался изучением и разработкой графических языков для визуального моделирования, некоторые удачные элементы разработчики напрямую заимствовали из ДРАКОНа.

"ДРАКОН — это попытка добавить эргономичность в классические блок-схемы, — объясняет он. — То есть это набор правил, как составлять блок-схемы так, чтобы алгоритм был представлен более понятным и удобным для работы образом. По большому счёту, это практическая реализация и дальнейшее развитие идей Эдсгера Дейкстры".

"Кроме ДРАКОНа, я таких попыток больше не знаю, — признается эксперт, — как применительно к блок-схемам, так и вообще к каким-либо другим диаграммным языкам (не считая работы нашей группы лет 5-7 назад)".

Авторы написанных на ДРАКОНе учебников — в самых разных областях — также утверждают: алгоритмический язык Паронджанова позволяет изложить материал в максимально доступной форме. А заодно позволяет "отжать всю воду", оставив только самый минимум, необходимый для описания процесса. За счет этого объем учебных пособий сокращается даже не в десятки, а в сотни раз.

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

"Это революция"

За три десятилетия работы над ДРАКОНом Владимир Паронджанов попутно написал полтора десятка научно-популярных книг на стыке информатики, управления и психологии — о том, как можно использовать его визуальный язык для лучшего запоминания материала.

Одну из таких книг, "Как улучшить работу ума", совершенно случайно купил в начале 2000-х в Москве литовский бизнесмен Альгирдас Каралюс. Так он узнал о существовании языка ДРАКОН — и ему в голову пришла блестящая бизнес-идея: применить этот язык для автономного обучения студентов.

"У меня в домашней библиотеке около 4000 книг, но ни одна из них не произвела на меня такого впечатления, как книга Паронджанова, — вспоминает бизнесмен. — Она стала тем самым недостающим звеном, которого мне так не хватало. Это была настоящая революция в образовании. Я понял, что эта идея должна обойти весь мир".

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

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

"Дело в том, что раньше в медицине алгоритмы писались как придется, — объясняет профессор. — Просто делались какие-то блок-схемы, а какого-то единого принципа — как и что нужно писать — попросту не было. А когда мы начали работать с языком ДРАКОН, мы поняли, что он позволяет очень легко описать сложные процессы — так, чтобы они стали понятны для совершенно незнакомых с ними людей".

Паулюс Добожинскас с коллегами написал на ДРАКОНе несколько учебников

"Если перед литовскими коллегами стояла задача выбрать графический язык для наглядного представления алгоритмов, они сделали вполне понятный выбор, — соглашается Тимофей Брыксин. — Тут большую роль начинают играть уже вопросы вкуса и личных предпочтений, но мне ДРАКОН видится вполне конкурентоспособным в этой нише".

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

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

"Это был язык ДРАКОН — тот самый ракетно-космический язык, который я и создал, работая в "Роскосмосе", — но они приспособили его для медицинских целей!" — восхищается изобретатель.

Проанализировав работу литовских медиков, Паронджанов написал на ее основе еще одну книгу, под названием "Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов?"

"Вторая грамотность"

Сейчас Добожинскас возглавляет в Каунасе медицинский Центр исследования кризисов и инновационную Гибридную лабораторию, где учатся студенты из разных стран.

Гибридной она называется потому, что объединяет два метода обучения: студенты учатся онлайн, но отрабатывают навыки руками в симуляционном классе, тренируя мышечную память.

Симуляционное обучение на манекенах гораздо эффективнее интернет-курсов, но заодно намного сложнее и дороже, так как требует наличия проводящего тренинг инструктора. ДРАКОН помог решить эту проблему.

"Драконный алгоритм помог нам удалить инструктора из симуляционного класса, так как все действия — пошагово — расписаны в процессе, — объясняет Добожинскас. — И студент, приходя в симуляционный класс, может весь процесс проводить самостоятельно — без активного участия инструктора".

А это значит, что студенты могут отрабатывать навыки медицинской помощи в любое время — не подстраиваясь под тренера и даже без поправки на часовые пояса. В классе ведется видеозапись, и преподаватель отсматривает только итоговый, "экзаменационный" вариант — тоже тогда, когда ему или ей удобно.

Литовцы отмечают: помимо того что ДРАКОН существенно повышает скорость обучения, он еще и делает его невероятно эффективным — по сравнению с обычными курсами.

"Если при традиционном обучении только 3% студентов достигают мастерства и еще 17% приобретают какие-то навыки (а 80%, к сожалению, так и не овладевают успешно никакими навыками), то при драконном обучении мы можем обеспечить 97-процентное достижение результата", — уверяет Каралюс.

Альгирдас Каралюс говорит, что ДРАКОН изменил его жизнь
Он даже создал международную академию языка ДРАКОН, чтобы алгоритмы Паронджанова можно было применять в обучении любым другим практическим навыкам.

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

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Показываю картинки

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

Сложную программу на "Драконе" не напишешь.

Здравствуйте, Владимир Паронджанов, Вы писали:

AS>>>скажите, как на картинку 2017-го года проникли ДИСКЕТЫ (кстати, что это такое?)
ВП>Показываю картинки 2019 года.
Та же профанация, что и раньше.

Покажите хотя бы компилятор ДРАКОНа на ДРАКОНе.

Здравствуйте, Cyberax, Вы писали:

AS>>>>скажите, как на картинку 2017-го года проникли ДИСКЕТЫ (кстати, что это такое?)
ВП>>Показываю картинки 2019 года.
C>Та же профанация, что и раньше.

C>Покажите хотя бы компилятор ДРАКОНа на ДРАКОНе.

(Плюсик поставил)

Ну, это конечно интересное умственное упражнение,
но разве у тебя есть сомнение в том, что его можно написать?

Презентация нового дракон-редактора DrakonIDE
в компании «Овен»

24-го октября 2019 года в 11.00
в компании Овен, будет проходить
презентация нового редактора DrakonIDE.
Разработчик кандидат технических наук, доцент
Астраханского государственного технического университета
Валерий Викторович Лаптев.

Презентация состоится по адресу
Москва, 2-я ул. Энтузиастов, д. 5, корп. 5 (метро Авиамоторная).

Желающие могут подать заявку на участие в презентации на электронную почту a_koverina@okbamur3.ru

Здравствуйте, Socrat, Вы писали:

S>Здравствуйте, vdimas, Вы писали:

V>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

S>Я немного в курсе как делали Буран. В советские времена к ПО относились несколько иначе, его проверяли и перепроверяли, в том числе и сторонние организации. Вплоть до того, что дизассемблировали и сравнивали с исходным кодом.

А как сейчас пишут и тестируют ПО для космонавтики?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>презентация нового редактора DrakonIDE.
ВП>Разработчик кандидат технических наук, доцент
ВП>Астраханского государственного технического университета
ВП>Валерий Викторович Лаптев.

IDE написана на Драконе? Исходники открыты?

Здравствуйте, AleksandrN, Вы писали:

AN>IDE написана на Драконе? Исходники открыты?

Сообщаю сведения о двух дракон-редакторах с открытым исходным кодом (разработчик Степан Митькин).

1. В дракон-редакторе DRAKON Editor (2011 год) есть возможность из дракон-схем генерировать код на разных языках.
DRAKON Editor написан на скриптовом языке программирования Tcl/Tk.
DRAKON Editor — это программа с открытым исходным кодом. Лицензия Public domain.

2. Степан Митькин открыл исходный код редактора DrakonHub (2018 год) и выложил его в GitHub.

Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде DRAKON Editor.

https://github.com/stepan-mitkin/drakonhub

Дракон-редактор DrakonHub предназначен для разработки алгоритмов (но не программ). Лицензия Public domain.

Здравствуйте, alpha21264, Вы писали:

C>>Покажите хотя бы компилятор ДРАКОНа на ДРАКОНе.
A>(Плюсик поставил)
A>Ну, это конечно интересное умственное упражнение,
A>но разве у тебя есть сомнение в том, что его можно написать?
В теории можно написать всё на всём, но на практике любой нетривиальный код на ДРАКОНе будет неподдерживаемым и уродливым.

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

Здравствуйте, AleksandrN, Вы писали:

ВП>>презентация нового редактора DrakonIDE.
ВП>>Разработчик кандидат технических наук, доцент
ВП>>Астраханского государственного технического университета
ВП>>Валерий Викторович Лаптев.
AN>IDE написана на Драконе?
Какой смешной вопрос — конечно нет.

Уважаемые коллеги!

Мое предыдущее сообщение не привлекло к себе внимания. А жаль.
Разработки Степана Митькина (Норвегия) представляют несомненный интерес.
Он создал три ДРАКОН-конструктора в 2011, 2018 и 2019 годах.

Повторю информацию о первых двух дракон-редакторах с открытым исходным кодом .

1. В дракон-редакторе DRAKON Editor (2011 год) есть возможность из дракон-схем генерировать код на разных языках.
DRAKON Editor написан на скриптовом языке программирования Tcl/Tk.
DRAKON Editor — это программа с открытым исходным кодом. Лицензия Public domain.

2. Степан Митькин открыл исходный код редактора DrakonHub (2018 год) и выложил его в GitHub.

Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде разработки DRAKON Editor.
Что это значит?
Это значит, что ДРАКОН-конструктор DrakonHub написан на ДРАКОНе.

https://github.com/stepan-mitkin/drakonhub

Дракон-редактор DrakonHub предназначен для разработки алгоритмов и бизнес-процессов (но не программ). Лицензия Public domain.

Заодно даю ссылку на статью на Хабре.
Митькин С.Б. Визуальное программирование на языке ДРАКОН Публикация 22 декабря 2017 под ником rykkinn

ВП> Мое предыдущее сообщение не привлекло к себе внимания. А жаль.

Почему же не привлекло? Привлекло, было оценено топовыми реальными экспертами из реальной жизни.
И оценка эта: "не нужно".

Вот когда доработаете хотя бы до состояния UML (который тоже не нужен), тогда и поговорим.

Здравствуйте, Socrat, Вы писали:

V>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

S>Я немного в курсе как делали Буран. В советские времена к ПО относились несколько иначе, его проверяли и перепроверяли, в том числе и сторонние организации. Вплоть до того, что дизассемблировали и сравнивали с исходным кодом.

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

Новые идеи, безусловно дело хорошее.

Однако, форумы закрыты от широкой общественности.

О каком развитии может идти речь?

Это типичный научный междусобойчик. Замкнутое на себя сообщество.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Мое предыдущее сообщение не привлекло к себе внимания. А жаль.

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

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

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>http://drakon-practic.ru/drakon.pdf

Дико извиняюсь, но это ж на bpmn похоже

Здравствуйте, Bigger, Вы писали:

ВП>>http://drakon-practic.ru/drakon.pdf

B>Дико извиняюсь, но это ж на bpmn похоже

Вы правы, на BPMN похоже. Но при этом возникает вопрос:
Что лучше BPMN или ДРАКОН?

Преимущество ДРАКОНа в том, что он позволяет очень точно и наглядно отобразить алгоритмы (бизнес-процессы, workflows) ЛЮБОЙ СЛОЖНОСТИ.

Посмотрите Народные отзывы о языке ДРАКОН
https://forum.drakon.su/viewforum.php?f=155

Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Посмотрите Народные отзывы о языке ДРАКОН
ВП>https://forum.drakon.su/viewforum.php?f=155
Дык и программирование на BPM — тоже квадратики рисовать, только ещё внутри можно и на обычном ЯП кастомизировать

ВП>Посмотрите Народные отзывы о языке ДРАКОН
ВП>https://forum.drakon.su/viewforum.php?f=155

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

Можно, ты осилишь не только Дракон, но и форумный этикет?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>https://forum.drakon.su/viewforum.php?f=155

Форум одного постера? Поздравляю.

Здравствуйте, Cyberax, Вы писали:

C>Потому его авторы и не занимаются вообще ничем практическим. Полный ноль собственно нетривиального кода.
А разве это не примерно то, на чём было написано ПО "Бурана"?..

Здравствуйте, Erop, Вы писали:

E>А разве это не примерно то, на чём было написано ПО "Бурана"?..

Уже много раз объясняли, что Буран слетал безо всякого Дракона. Его тогда не было, и, тем не менее, все получилось.
Картинку Бурана на старте в статьях о Драконе можно рассматривать как недобросовестную рекламу.

Здравствуйте, кт, Вы писали:

кт>Уже много раз объясняли, что Буран слетал безо всякого Дракона. Его тогда не было, и, тем не менее, все получилось.
кт>Картинку Бурана на старте в статьях о Драконе можно рассматривать как недобросовестную рекламу.

О! Это намного интереснее самого Дракона

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

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

Здравствуйте, Erop, Вы писали:

E>Ясно, что тогда Дракона не было, но они свои циклограммы на какой-то полувизуальной системе программирования делали. Потом этим делом кто-то вдохновился и соорудил дракон.

Какая там «полувизуальная система» в 1987 году?
Писали программы на специально разработанном в ИПМ языке «Пролог-Ц», который потом стал называться ПРОЛ-2. Обычные тексты, ключевые слова – русские. При оформлении документации иногда составлялись и блок-схемы, но всегда задним числом, для уже отработанных программ.
Лично я скептически отношусь к графическому представлению программ. Если алгоритм тривиален – и блок схема тривиальна (и нафиг не нужна). Если же алгоритм сложен – и блок схема будет сложна и трудно воспринимаема глазами.
Другое дело, если схема отображает реальное устройство. Например, электрическая схема где-нибудь на пульте управления АЭС. Там она к месту, а абстрактный алгоритм прекрасно пишется и обычным текстом.

Здравствуйте, кт, Вы писали:

кт>Какая там «полувизуальная система» в 1987 году?
Э, а в чём проблемы с 1987 годом и визуальными системами? Ты какой-нибудь Нортон Коммандер видел?..

кт>Писали программы на специально разработанном в ИПМ языке «Пролог-Ц», который потом стал называться ПРОЛ-2. Обычные тексты, ключевые слова – русские. При оформлении документации иногда составлялись и блок-схемы, но всегда задним числом, для уже отработанных программ.
Ну вот это интересно, как раз. А есть где про это подробнее почитать? Что за язык, при чём тут пролог и т. д?

кт>Лично я скептически отношусь к графическому представлению программ. Если алгоритм тривиален – и блок схема тривиальна (и нафиг не нужна). Если же алгоритм сложен – и блок схема будет сложна и трудно воспринимаема глазами.
кт>Другое дело, если схема отображает реальное устройство. Например, электрическая схема где-нибудь на пульте управления АЭС. Там она к месту, а абстрактный алгоритм прекрасно пишется и обычным текстом.

Я тоже скептически отношусь

Но это не значит, что у такого рода DSL совсем нет ниши...

Здравствуйте, Erop, Вы писали:

E>Ну вот это интересно, как раз. А есть где про это подробнее почитать? Что за язык, при чём тут пролог и т. д?
Пролог от ПРОграммирование ЛОГики. К японскому Прологу с его транспьютерами отношения не имеет.
Язык как язык. Для управления материальными объектами. Имел процессы, исполнители, признаки, сигналы, команды и т.п. вещи. Ориентирован на реальное время. Почитать где-нибудь, наверное, на сайте ИПМ. ПРОЛ-2 это была доработанная версия, так сказать, ПРОЛОГ 2.0

кт>>Какая там «полувизуальная система» в 1987 году?
E>Э, а в чём проблемы с 1987 годом и визуальными системами? Ты какой-нибудь Нортон Коммандер видел?..

А ты его видел? Много там визуальных блок-схем?

E>Я тоже скептически отношусь

Но это не значит, что у такого рода DSL совсем нет ниши...

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

Здравствуйте, Mamut, Вы писали:

M>А ты его видел? Много там визуальных блок-схем?
Ты, прости, на я в конце 1980-х на всяких машинках вроде Атари программировал. Там с гуями всё уже тогда очень хорошо было...

Здравствуйте, Erop, Вы писали:

C>>Потому его авторы и не занимаются вообще ничем практическим. Полный ноль собственно нетривиального кода.
E>А разве это не примерно то, на чём было написано ПО "Бурана"?..

Я не видел кода от БУРАНа. И никто тут не видел. Так что про него можно говорить что угодно.

Здравствуйте, Cyberax, Вы писали:

C>Я не видел кода от БУРАНа. И никто тут не видел. Так что про него можно говорить что угодно.

Кодов Бурана, конечно, у меня нет, но вот есть один из тестов проверки компилятора. По нему можно получить некоторое представление о том, как выглядели программы:

%         ПРОВЕРКА  ФУНКЦИЙ И ОПЕРАТОРОВ ЯЗЫКА ПРОЛ-2

МОДУЛЬ TST2;
ПРИЗНАКИ
ВРЕМЯ    ВРМ ()();
ОЖИДАНИЕ ВРМ ()();
КОНЕЦ

КОМАНДЫ
KK1 K2H.КОЛЬЦВТЯН                      (TEST);
КОНЕЦ

СИГНАЛЫ
S1 SU2HKОЛВТЯН                         (TEST);
КОНЕЦ

КОНСТ
НУЛЬ=0;
НУЛЬ1="12345678";
НУЛЬ2="ABCD";
НУЛЬ3=1Д 2Ч 30М 10C;
КОНЕЦ

МОДУЛЬ TST1 МОДЕЛЬ;

ПРОЦЕСС TST1;
TEST :1T;
TEST2:1T;
КОНЕЦ

СОБЫТИЯ
C1                     (TEST)(TEST);
КОНЕЦ

ПРИЗНАКИ
X1 ЛОГ                 (TEST)(TEST);
X2 ЦЕЛ (-1234..100000) (TEST)(TEST);
X3 ВРМ                 (TEST)(TEST);
X4 ПОЛУСЛОВО           (TEST)(TEST);
X5 СЛОВО               (TEST)(TEST);
X6 ВРМ                 (TEST)(TEST);

ОШИБКА ЦЕЛ(1000)       (TEST)(TEST);
ТИП ЦЕЛ(1000)          (TEST)(TEST);

Z1 ЛОГ                 (TEST)(TEST);
Z2 ЛОГ                 (TEST)(TEST);
Z3 ЛОГ                 (TEST)(TEST);
Z4 ЛОГ                 (TEST)(TEST);
Z5 ЛОГ                 (TEST)(TEST);

КОНЕЦ

ШАБЛОН Ш1;
Ф1 :ВРМ,
Ф2 :ЦЕЛ(1000)
КОНЕЦ

ТАБЛИЦА Т1: Ш1(10) (TEST)(TEST);
3T,100;
<<M2>>
ПОВТ 7 РАЗ
10T,55
КОНЕЦ


ШАБЛОН Ш2;
Ф1 :СОБ,
Ф2 :РЗР,
Ф3 :БЛК,
Ф4 :ЛОГ,
Ф5 :ВРМ,
Ф6 :ЦЕЛ(1000),
Ф7 :СИГ,
Ф8 :ШКЛ(100),
Ф9 :ТАБ(Ш1,100),
Ф10:ИСП,
Ф11:УСТ,
Ф12:ВЫП,
Ф13:МТК,
Ф14:ПРЗ ЛОГ,
Ф15:ПРЗ ВРМ,
Ф16:ПРЗ ЦЕЛ(100)
КОНЕЦ

ТАБЛИЦА Т2: Ш2(12) (TEST)(TEST);
Z1,Z2,Z4,1,2M,100,S1,(1,2,3,4,5,6,7,8),T1,TEST2,X1:=1,TEST2,M2,X1,X3,X2;
<<M2>>
ПОВТ 7 РАЗ
Z1,Z2,Z3,0,1Ч,200,S1,(1,2,3,4,100),    T1,TEST2,X2:=10,X1,M2,X1,X3,X2;
КОНЕЦ

ПРИЗНАКИ
X7 ТАБ(Ш2,12)      (TEST)(TEST);
КОНЕЦ

ИСПОЛНИТЕЛЬ TEST2;
НАЧАЛО
<<M>> ПАУЗА 0T;
НА М;
КОНЕЦ

ИСПОЛНИТЕЛЬ TEST;
X3:ЦЕЛ (-1..10000000);
Y1:ЛОГ;Y2:ЛОГ;Y3:ЛОГ;Y4:ЛОГ;
НАЧАЛО

%--------- ПРОВЕРКА АРИФМЕТИЧЕСКИХ ОПЕРАЦИЙ --------------

ТИП:=1;
X3:=1234;
X2:=-X3;
X2:=-X2;
X3:=X2*X2;
X2:=X3/X2;
X3:=X3 MOД X2;
X3:=X2+X2+X3;
X2:=X3-X2;

%--------- ПРОВЕРКА ОПЕРАЦИЙ СРАВНЕНИЯ -------------------

X3:=0;
ЕСЛИ X2 =1234 ТО X3:=X3+0;
ЕСЛИ X2^=1234 ТО X3:=X3+1;
ЕСЛИ X2 >1234 ТО X3:=X3+10;
ЕСЛИ X2 <1234 ТО X3:=X3+100;
ЕСЛИ НУЛЬ>1234 ТО X3:=X3+1000;
ЕСЛИ X2>=1234 ТО X3:=X3+0;
ЕСЛИ X2<=1234 ТО X3:=X3+0;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА СТАНДАРТНЫХ ФУНКЦИЙ ------------------

%--------- ПРОВЕРКА ФУНКЦИИ ПРОВБИТ ----------------------
ТИП:=2;

X4:="0001";
X5:="00000001";

ЕСЛИ ПРОВБИТ(X4,0) ^=0 TO X3:=X3+1;
ЕСЛИ ПРОВБИТ(X4,15)^=1 TO X3:=X3+1;

ЕСЛИ ПРОВБИТ(X5,0) ^=0 TO X3:=X3+10;
ЕСЛИ ПРОВБИТ(X5,31)^=1 TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ УСТБИТ -----------------------
ТИП:=3;

X4:=УСТБИТ(X4,10,1);
ЕСЛИ X4^="0021"     TO X3:=X3+1;
X5:=УСТБИТ(X5,11,1);
ЕСЛИ X5^="00100001" TO X3:=X3+1;

X4:=УСТБИТ(X4,0,1);
ЕСЛИ X4^="8021"     TO X3:=X3+10;
X5:=УСТБИТ(X5,1,1);
ЕСЛИ X5^="40100001" TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ НОМБИТ -----------------------
ТИП:=4;

ЕСЛИ НОМБИТ(X4)^=0  TO X3:=X3+1;
ЕСЛИ НОМБИТ(X5)^=1  TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ПСДВИГ -----------------------
ТИП:=5;

ЕСЛИ ПСДВИГ(X4,4)^="0802"      TO X3:=X3+1;
ЕСЛИ ПСДВИГ(X5,4)^="04010000"  TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;


%--------- ПРОВЕРКА ФУНКЦИИ ЛСДВИГ -----------------------
ТИП:=6;

ЕСЛИ ЛСДВИГ(X4,2)^="0084"      TO X3:=X3+1;
ЕСЛИ ЛСДВИГ(X5,1)^="80200002"  TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ОТРИЦАНИЯ --------------------
ТИП:=7;

ЕСЛИ ^X4^="7FDE"      TO X3:=X3+1;
ЕСЛИ ^X5^="BFEFFFFE"  TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ЛОГИЧЕСКОГО УМНОЖЕНИЯ --------
ТИП:=8;

ЕСЛИ (X4&"8007")^="8001"           TO X3:=X3+1;
ЕСЛИ (X5&"00000001")^="00000001"   TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ЛОГИЧЕСКОГО СЛОЖЕНИЯ ---------
ТИП:=9;

ЕСЛИ (X4!"8007")^="8027"           TO X3:=X3+1;
ЕСЛИ (X5!"10000001")^="50100001"   TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ИСКЛЮЧАЮЩЕГО ИЛИ -------------
ТИП:=10;

ЕСЛИ (X4#"FFFF")^="7FDE"           TO X3:=X3+1;
ЕСЛИ (X5#"FFFFFFFF")^="BFEFFFFE"   TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ И ----------------------------
ТИП:=11;

Y1:4:=1;
ЕСЛИ И(Y1:4)=0 TO X3:=X3+1;
Y1:4(2):=0;
ЕСЛИ И(Y1:4(1))= 1 TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ИЛИ --------------------------
ТИП:=12;

Y1:4:=0;
ЕСЛИ ИЛИ(Y1:4)=1 TO X3:=X3+1;
Y1:4(5):=1;
ЕСЛИ ИЛИ(Y1:4(1))= 0 TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ СУМ --------------------------
ТИП:=13;

Y1,Y2:4(1):=0;
Y1,Y2,Y3:=1;
ЕСЛИ СУМ(Y1:4)^=3 TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ АБС --------------------------
ТИП:=14;

X2:=-100;
ЕСЛИ X2=АБС(X2) TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ПУСТО ------------------------
ТИП:=15;

T1$Ф1(4):=0T;
T1$Ф2(5):=0;
ЕСЛИ ^ПУСТО(T1$Ф1(4)) TO X3:=X3+1;
ЕСЛИ ^ПУСТО(T1$Ф2(5)) TO X3:=X3+10;
ЕСЛИ  ПУСТО(T1$Ф2(6)) TO X3:=X3+100;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ДЛТАБ ------------------------
ТИП:=16;

ЕСЛИ ДЛТАБ(T1)^=8 TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ВХОДИТ -----------------------
ТИП:=17;

ЕСЛИ ^ВХОДИТ(T2$Ф8(7),100) TO X3:=X3+1;
ЕСЛИ  ВХОДИТ(T2$Ф8(1),ТИП) TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ ДАЙСОБ -----------------------
ТИП:=18;

Z1:3:=1;
Z4:=0;

ЕСЛИ ДАЙСОБ(T2,2,6)^=0 TO X3:=X3+1;
ЕСЛИ ДАЙСОБ(T2,1)^=1   TO X3:=X3+10;
ЕСЛИ Z2=1              TO X3:=X3+100;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ФУНКЦИИ СЛУЧАЙ -----------------------
ТИП:=19;

ЕСЛИ (СЛУЧАЙ()=СЛУЧАЙ())&(СЛУЧАЙ()=СЛУЧАЙ()) TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ОПЕРАТОРА УСТАНОВКИ ------------------
ТИП:=20;

X1:=0;
X2:=0;

УСТ T2$Ф11(1);
ЕСЛИ X1^=1  TO X3:=X3+1;
УСТ T2$Ф11(2);
ЕСЛИ X2^=10 TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ОПЕРАТОРА ВЫПОЛНЕНИЯ ------------------
ТИП:=21;

X1:=0;
X7:=T2;

ВЫП T2$Ф12(1);
ЕСЛИ ^TEST2 TO X3:=X3+1;  ПРЕК TEST2;
ВЫП X7$Ф12(2);
ЕСЛИ X1^=1 TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ОПЕРАТОРА ПУСК ------------------------
ТИП:=22;


ПУСК T2$Ф10(1);
ЕСЛИ ^TEST2 TO X3:=X3+1;  ПРЕК TEST2;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ЦИКЛА         ------------------------
ТИП:=23;
X6:=0T;
ДЛЯ X2 OT 10 ДО 20 ПОВТ 5 РАЗ
    X6:=X6+1T;
КОНЕЦ;

ЕСЛИ X6^=5T       TO X3:=X3+1;
ЕСЛИ X2^=15       TO X3:=X3+10;

X6:=0T;
ДЛЯ X2 OT 10 ДО 20 ПОВТ
    X6:=X6+1T;
КОНЕЦ;

ЕСЛИ X6^=11T       TO X3:=X3+100;
ЕСЛИ X2^=21        TO X3:=X3+1000;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ВЫБОРА -------------------------------
ТИП:=24;

X2:=200;
ВЫБОР
КОГДА X2=1 TO X3:=X3+1;
КОГДА X2=2 TO X3:=X3+1;
ЛИБО  X2:=100;
КОНЕЦ;

ЕСЛИ X2^=100       TO X3:=X3+10;

X2:=2;
ВЫБОР
КОГДА X2=1 TO X3:=X3+100;
КОГДА X2=2 TO X2:=300;
ЛИБО  X3:=1000;
КОНЕЦ;

ЕСЛИ X2^=300       TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ПЕРЕКЛЮЧАТЕЛЯ   ----------------------
ТИП:=25;

X2:=200;
ПЕРЕКЛ X2
КОГДА 1 TO X3:=X3+1;
КОГДА 2 TO X3:=X3+1;
ЛИБО  X2:=100;
КОНЕЦ;

ЕСЛИ X2^=100       TO X3:=X3+10;

X2:=2;
ПЕРЕКЛ X2
КОГДА 1 TO X3:=X3+100;
КОГДА 2 TO X2:=300;
ЛИБО  X3:=1000;
КОНЕЦ;

ЕСЛИ X2^=300       TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ОЖИДАНИЯ        ----------------------
ТИП:=26;

X2:=200;
ЖДАТЬ
КОГДА X2=1 TO X2:=300;
КОНЕЦ;

ЕСЛИ X2^=300       TO X3:=X3+10;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ОЖИДАНИЯ СОБЫТИЯ ---------------------
ТИП:=27;

X2:=0;
ЖДАТЬ СОБЫТИЯ 10T
КОГДА C1 TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=301       TO X3:=X3+1;

ТИП:=28;
ПАУЗА 0T;

X2:=0;
ЖДАТЬ СОБЫТИЯ 10T
КОГДА C1 TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=1         TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ОЖИДАНИЯ КОМАНДЫ ---------------------
ТИП:=29;

X2:=0;
ЖДАТЬ КОМАНДЫ 10T
КОГДА K2H.КОЛЬЦВТЯН TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=301       TO X3:=X3+1;

ТИП:=30;
ПАУЗА 0T;

X2:=0;
ЖДАТЬ КОМАНДЫ 10T
КОГДА K2H.КОЛЬЦВТЯН TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=1         TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

%--------- ПРОВЕРКА ПРЕРЫВАНИЙ  ---------------------
ТИП:=31;

X2:=0;

БЛОК
ЖДАТЬ
КОГДА X2=400 TO X2:=300; КОНЕЦ;
X2:=500;

ПРЕРЫВАНИЯ
КОГДА S1    ПРОДОЛЖИТЬ X2:=100;Y2:=0;
КОГДА K2H.КОЛЬЦВТЯН    ЗАВЕРШИТЬ  ЕСЛИ X2=100 TO X2:=400;Y2:=1;
КОНЕЦ;

ЕСЛИ X2^=400       TO X3:=X3+1;

ОШИБКА:=X3; ПАУЗА 0T;

КОНЕЦ

%*****************************************************************

МОДУЛЬ TST0 TECT;

ПРОЦЕСС TST0;
A:1T;
КОНЕЦ

ИСПОЛНИТЕЛЬ A;
НАЧАЛО

ОШИБКА:=0;
ПУСК TEST;
<<M>>
ЕСЛИ ^TEST TO
НАЧАЛО ПЕЧАТЬ(/,'ТЕСТ ОКОНЧЕН',/);  ВЫЙТИ A; КОНЕЦ;

ЕСЛИ ТИП=26 TO X2:=1;
ЕСЛИ ТИП=27 TO C1:=1;
ЕСЛИ ТИП=28 TO C1:=0;
ЕСЛИ ТИП=29 TO ВЫДАТЬ(32T) KK1; %K2H.КОЛЬЦВТЯН;
ЕСЛИ ТИП=30 TO K2H.КОЛЬЦВТЯН:=0;
ЕСЛИ ВРЕМЯ> 90T TO S1:=1;
ЕСЛИ ВРЕМЯ>100T TO ВЫДАТЬ(32T) K2H.КОЛЬЦВТЯН;
ЕСЛИ ОШИБКА^=0 TO
НАЧАЛО ПЕЧАТЬ(/,'ОШИБКА ',ТИП,' ',ОШИБКА,/);
ПРЕК TEST;
ВЫЙТИ А; КОНЕЦ;
ПАУЗА 0T; НА М;
КОНЕЦ

M>>А ты его видел? Много там визуальных блок-схем?
E>Ты, прости, на я в конце 1980-х на всяких машинках вроде Атари программировал. Там с гуями всё уже тогда очень хорошо было...

Учитывая, что в 2020-м Дракону для того, чтобы показать схему сортировки пузырьком не хватит 27-дюймового 5K экрана, я сильно сомневаюсь, что в конце 70-х начале 80-х, когда Буран собственно разрабатывался, Дракон (если он тогда хоть как-то существовал) присутствовал хоть в какой-то значимой мере.

Уважаемые коллеги!

С языком ДРАКОН можно ознакомиться по книге
https://drakon.su/_media/24_zhizneritm20.pdf

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>С языком ДРАКОН можно ознакомиться по книге

Здравствуйте, Эйнсток Файр, Вы писали:

ВП>> Мое предыдущее сообщение не привлекло к себе внимания. А жаль.

ЭФ>Почему же не привлекло? Привлекло, было оценено топовыми реальными экспертами из реальной жизни.
ЭФ>И оценка эта: "не нужно".

Почему не нужно? Это не так.

Вот пример. На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании «Сургутнефтегаз» и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.

Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.

Подробности по ссылке https://www.youtube.com/watch?v=_XOuhV_8N_I&feature=youtu.be

ЭФ>>Почему же не привлекло? Привлекло, было оценено топовыми реальными экспертами из реальной жизни.
ЭФ>>И оценка эта: "не нужно".

ВП> Почему не нужно?

По завоёванному объёму рынка.
Вот когда программисты (китайцы и англоговорящие) будут голосовать на github
за Дракон вместо Rust в категории "наиболее желанный язык",
тогда и поговорим.

А пока русскоговорящие выбирают Rust — не годится Дракон, значит.

Здравствуйте, Erop, Вы писали:

Лично мне кажется, что тема мёртворождённая, но если у кого-то есть какой-то реальный опыт, то интересно было бы его понять.

Вот что пишет Роман Озеров в комментарии на YouTube:
https://www.youtube.com/watch?v=ZCBIZleP1BA&feature=youtu.be

Я на ДРАКОНе работаю уже 6 лет.
Любое создание программы начинаю с него и при отладке работаю только с ним.

Скорость разработки, качество возрастает в разы!
ДРАКОН это сила, но многие не догоняют, думаю что это обычная блок-схема...

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вот что пишет Роман Озеров в комментарии на YouTube:
ВП>https://www.youtube.com/watch?v=ZCBIZleP1BA&feature=youtu.be

Подсказка: смотреть на скорости 1,5x

P.S. Навеяло: Устный счёт — Википедия

	Устный счёт в начальной школе
	Выработка навыков устного счёта занимает особое место в начальной школе и является одной из главных задач обучения математике на этом этапе[1]. Именно в первые годы обучения закладываются основные приёмы устных вычислений, которые активизируют мыслительную деятельность учеников, развивают у детей память, речь, способность воспринимать на слух сказанное, повышают внимание и быстроту реакции[1]. Для обучения детей устному счету часто используют счетную доску — абак. Многие эксперты считают, что метод счета с использованием абака (этот метод также называют ментальной арифметикой) появился в Древнем Китае, однако подтверждений этому не существует. Абак представлял собой доску до счета. Этими приспособлениями пользовались по всему миру, а не только в Китае[2]. Программа обучения ментальной арифметике обычно занимает несколько лет. Сначала дети учатся считать на настоящем абаке. Далее вместо реальной доски обучающиеся начинают использовать её изображение: глядя на рисунок во время вычислений, нужно представлять, как передвигаются костяшки. В конце концов дети начинают представлять абак мысленно, что позволяет им производить умственно те же операции, что и с использованием настоящей доски. Многие эксперты считают, что ментальная арифметика позволяет эффективно развивать логическое мышление, аналитические навыки, а также улучшать память. Учащиеся могут визуализировать задачи, глубже их понимать и мыслить креативно. Эти навыки помогают им лучше концентрировать свое внимание, систематизировать получаемые знания и лучше адаптироваться к меняющимся условиям[2]. Однако некоторые педагоги и ученые относятся к данному методу немного скептически. Так, по словам заслуженного учителя России Леонида Звавича, устный счет — дело полезное, но есть масса других приемов устного счета и какой из них лучше, сказать сложно. Успехи ребёнка в обучении во многом зависят от того, какие у него были учителя, но развивающие занятия, безусловно, помогают ему подтянуть разные предметы[2]. Но даже критики данного метода признают, что какая-то польза от ментальной арифметики все же есть, особенно если ребёнку тяжело дается математика. Кроме того, в процессе обучения у детей вырабатывается привычка трудиться, что обязательно пригодится в дальнейшей жизни[2].

Примерно такое же впечатление о языке «ДРАКОН» у меня сложилось в процессе просмотра видеоролика.

Ничего не имею против блок-схем, но программировать таким способом...

Больше всего порадовало, когда разработчик сначала внес изменение в комментарий, а потом отразил это изменение в коде программы:
https://youtu.be/ZCBIZleP1BA?t=547

P.P.S. Навскидку выразил на Python фрагмент блок-схемы, показанный в видео по указанному выше таймкоду:

set_table_heat_on(True)

if table_heat_on:
    if dt4 <= 5 or dt4 > 38:
        high_limit_and_protection()
        set_heat_power_percent(0)
    elif dt4 <= 29:  # (5, 29]
        set_heat_power_percent(100)
    elif dt4 <= 36:  # (29, 36]
        set_heat_power_percent(60)
    else:            # (36, 38]
        set_heat_power_percent(40)    
else:
    set_heat_on(False)
    if heat_power_percent > 0:
        set_heat_power_percent(0)

if heat_power_percent > 0:
    calculate_pulse_duration()  # ms

set_heat_endoscope(True)

if heat_endoscope_on:
    # some code
else
    # some code

Как мне кажется, в блок-схеме запутаться легче, чем в коде.

P.P.P.S. Также порадовали goto по всему тексту программы:
https://youtu.be/ZCBIZleP1BA?t=697

Здравствуйте, Lazytech, Вы писали:

L>Как мне кажется, в блок-схеме запутаться легче, чем в коде.

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

Здравствуйте, alpha21264, Вы писали:

A>Это потому что ты по привычке сначала переводишь блок-схему в текст и только потом пытаешься понять.
A>Вообще у человека в мозгу тоже есть видео-процессор, который гораздо мощнее обычного процессора.
A>Когда ты смотришь на схему, ты СРАЗУ видишь где что не так.
A>Да, при этом должна быть привычка мыслить визуально.

Я же говорю, ~~шаманство~~ ментальная арифметика.

Здравствуйте, l33thaxor, Вы писали:

L>Форум одного постера? Поздравляю.

Это называется уютный маленький бложик.

Здравствуйте, Lazytech, Вы писали:

L>>Форум одного постера? Поздравляю.

L>Это называется уютный маленький бложик.

Тут возникали очень интересные археологические находки https://rsdn.org/forum/philosophy/4788166?tree=tree так что тема полезная

Здравствуйте, l33thaxor, Вы писали:

L>Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>>https://forum.drakon.su/

L>Форум одного постера? Поздравляю.

Это не так. На форуме зарегистрирован

291 человек

.

Форум https://forum.drakon.su/ пользуется популярностью. Смотрите — всего за пять минут —

Больше всего посетителей (188) здесь было
Понедельник, 04 Май, 2020 13:19

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Уважаемые коллеги!

ВП>С языком ДРАКОН можно ознакомиться по книге
ВП>https://drakon.su/_media/24_zhizneritm20.pdf

А чё такая вёрстка странная?
Нельзя из оглавления перейти к нужной главе.

Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, alpha21264, Вы писали:

A>>Это потому что ты по привычке сначала переводишь блок-схему в текст и только потом пытаешься понять.
A>>Вообще у человека в мозгу тоже есть видео-процессор, который гораздо мощнее обычного процессора.
A>>Когда ты смотришь на схему, ты СРАЗУ видишь где что не так.
A>>Да, при этом должна быть привычка мыслить визуально.

L>Я же говорю, ~~шаманство~~ ментальная арифметика.

Ну вот не надо так говорить.
Если бы ты так писал программу, у тебя получилась бы ссылка на несуществующий объект.

Здравствуйте, alpha21264, Вы писали:

A>Ну вот не надо так говорить.
A>Если бы ты так писал программу, у тебя получилась бы ссылка на несуществующий объект.

Нич-чего не понимаю. (c)

Речь идет о моей попытке выразить кусок ДРАКОНовской блок-схемы на Python?

P.S. Если что, я не имею ничего против языка ДРАКОН, только вот возможность написать на нем сколько-нибудь серьезную программу (имеется в виду, с достаточно большим объемом кода) даже у меня, новичка в программировании, вызывает огромные сомнения. Хотя для обучения азам информатики — не путать с программированием — он, наверное, вполне сгодится.

P.P.S. Если же речь идет о вышеупомянутой ментальной арифметике, я всего лишь попытался эмоционально выразить впечатление от языка ДРАКОН. Я имел в виду, что ведение счета на абаке в общем случае, наверное, не очень эффективно.

Здравствуйте, alpha21264, Вы писали:

ВП>>С языком ДРАКОН можно ознакомиться по книге
ВП>>https://drakon.su/_media/24_zhizneritm20.pdf

A>А чё такая вёрстка странная?
A>Нельзя из оглавления перейти к нужной главе.

Верстка нормальная. По крайней мере, не нашел в Firefox такой проблемы. Если скачать этот PDF-файл и открыть в каком-нибудь просмотрщике, ссылки в оглавлении тоже работают как надо.

ВП>Я на ДРАКОНе работаю уже 6 лет.
ВП>Любое создание программы начинаю с него и при отладке работаю только с ним.

ВП>Скорость разработки, качество возрастает в разы!
ВП>ДРАКОН это сила, но многие не догоняют, думаю что это обычная блок-схема...

А больше подробностей нет?
Вот, например, возможно если написать ДРАКОНО-образный framework для ML, то это дало бы какой-то заметный выигрыш?
Можно ли где-то скачать саму ИС ДРАКОН что бы побаловаться? Бывают ли под неё какие-то библиотеки ли другие способы расширения?
Это что-то вроде форт-системы, насколько я понял? Некая замкнутая в себе исполняющая среда?

Здравствуйте, Erop, Вы писали:

E>Можно ли где-то скачать саму ИС ДРАКОН что бы побаловаться?
Скачать ИС Дракон можно здесь https://forum.drakon.su/viewtopic.php?p=104445#p104445

E>Бывают ли под неё какие-то библиотеки или другие способы расширения?
Есть понятие гибридного языка. Это значит, что ДРАКОН работает в паре с другим языком, например, Дракон-С, Дракон-Java, Дракон-JavaScript и т.д. Графика ДРАКОНа определяет разветвления и циклы, а парный (целевой) язык задает линейные участки программ и данные.

E>А больше подробностей нет?
Подробности см. в книге https://drakon.su/_media/24_zhizneritm20.pdf

Кто такой Роман Озеров, я не знаю.

V>этот (или похожий) язык будет очень хорош для планшетов.
Точно! Для пальцАми-тычащего контингента, которому в детстве не поставили развитие мелкой моторики.
V>управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд.
Особенно в сочетании с тем, какие тесные и галдёжные через 20 лет будут опенспейсы.
>При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах.
Не возрастёт от этого скорость взаимодействия с мозгом. Потому что без мелкой моторики не будет мозга. Вся эта тема с примитивизацией и гей-ми-фикацией — для отучения писать и читать большие тексты, и чтобы не развивалось абстрактное мышление.

Появление статьи "DRAKON" в турецкой Википедии стало юбилейным, так как теперь статья ДРАКОН (DRAKON) имеется в Википедии на 10 языках.
https://tr.wikipedia.org/wiki/DRAKON

Вниманию преподавателей

Выкладаваю список моих книг по языку ДРАКОН:

1. Паронджанов В. Д. Как улучшить работу ума. (Новые средства для образного представления знаний, развития интеллекта и взаимопонимания). — М.: Радио и связь, 1998, 1999. — 352 с.

2. Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто! — М.: Дело, 2001. — 360 с. http://bit.ly/2PtjSNy

3. Паронджанов В. Д. Язык Дракон. Краткое описание. — М., 2009. — 124 с. https://drakon.su/_media/biblioteka/drakondescription.pdf

4. Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. (Как улучшить работу ума без лишних хлопот). — М.: ДМК-пресс, 2010, 2014, 2016. — 464 с.

5. Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с. http://bit.ly/2Mlg4Ou

6. Паронджанов В. Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М., 2019. — 374 с. https://drakon.su/_media/24_zhizneritm20.pdf

7. В издательстве «Юрайт» вскоре выйдет из печати учебное пособие: «Паронджанов В. Д. Алгоритмические языки и программирование: ДРАКОН».
Учебное пособие будет издано в двух сериях:
— для высшего профессионального образования;
— для среднего профессионального образования.

Для начинающих могут быть полезны книги:

8. Паронджанов В. Д. Занимательная информатика. — М.: Росмэн, 1998. — 152 с. — Серия Школьнику для развития интеллекта.

9. Паронджанов В. Д. Занимательная информатика, или Волшебный Дракон в гостях у Мурзика. — М.: Росмэн, 2000. — 160 с. — Серия Школьнику для развития интеллекта. https://drakon.su/_media/biblioteka_1/zanim_inf_optimizacija1_.pdf

10. Паронджанов В. Д. Занимательная информатика. — М.: Дрофа, 2007. — 192 с. — Серия Познавательно! Занимательно!

Минимизация числа ошибок

Язык ДРАКОН обеспечивает минимизацию числа ошибок

Некоторые пользователи говорят, что ДРАКОН — безошибочный или почти безошибочный язык.

Отзыв Сергея Иголкина (Orthodox) о языке ДРАКОН

Дракон, на самом деле — чертовски хорош.
Не тем, что красивые диаграммки. Или охрененные разнообразные возможности (хотя хватает).

А тем, что главную свою цель обеспечивает — сложные алгоритмы писать и отлаживать без ошибок. http://sharaga.org/index.php?s=&showtopic=1953&view=findpost&p=170889

Отзыв индивидуального предпринимателя Сергея Ефанова о языке ДРАКОН:

Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.

Функция заработала сразу!

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

В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»! http://we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html

Отзыв инженера vtral о языке ДРАКОН

Язык Дракон — это способ визуального описания алгоритмов, исключающий ошибки. http://ledway.ru/post136332.html#p136332

Дракон исключает ошибки алгоритмов.
http://ledway.ru/post136337.html#p136337

Отзыв преподавателя Александра Порошина о языке ДРАКОН

Дракон предписывает осмысленное направление движения глаз человека в поле блок-схемы (по вертикали и горизонтали), за счет чего многократно улучшается «понимаемость» алгоритма и минимизируется вероятность появления ошибок. https://forum.drakon.su/viewtopic.php?p=103688#p103688

Luke Alan пишет на форуме языка ДРАКОН:
https://forum.drakon.su/viewtopic.php?f=62&t=6908

These are the features I would like in future Drakon editors, I think they would increase the power of Drakon.

All of the features already present in the latest drakon editor (desktop)

All of the features present in drakon tech such as auto arrangement of diagrams and adding/pasting by clicking + icons.

Dark theme which is easy on the eyes over many hours

Keyboard navigation for all functionality, such as arrow key navigation to select where to add a new icon and to traverse the diagram, as well as all other functionality with keyboard shortcuts

Single line icons. It would be nice if the only option was single line icons. I have ideas for how to improve the only case where multi line is beneficial: lists of things like parameters or arrays/associative arrays. See "mini-icons".

Mini icons for lists, such as parameters or arrays/associative arrays would be able to be added inside other icons, and would have their own outline shape and border color to distinguish between the three options (parameters, arrays, associative arrays). These mini icons would be on 'new lines' inside the parent icon, removing the need for making new lines manually or using commas.

Mini type icons having its own unique outline shape and border color for each type could be added inside parent icons such as action or question icons. These type icons would be: string, boolean, number, function, array, associative array, etc. These mini icons would remove plain text inside icons and instead encode all of the data in types visually — these type mini icons could be added by hotkeys or right click context menus.

Trigger icons would be unique icon headers for diagrams to indicate this diagram is an 'entry' point, such as when an event fires, or a user provides some input like a mouse click or keypress that triggers the diagram to fire. This would help distinguish which diagrams are the 'initiators' of a program procedure, and helps remove the need for silheouttes, which can get too big to fit on a screen.

Parent/Child diagrams and scope. This feature would help abstraction by allowing diagrams to exist only in the scope of being a child to another parent diagram, therefore, you could have duplicate diagrams in the same file as long as they were children to different parents.

Imagine you have two parent diagrams, one is called 'arithmetic' and the other is called 'string'. Under each of these parent diagrams there is a child diagram named 'add'. One is for adding arithmetic, the other is for adding strings together.

Because they are child diagrams, they can share the same name and would exist in a hierarchical relationship in the diagram tree, below their parent diagrams. This also helps show which diagrams are only related to certain other diagrams, and helps organize a large code base.

Custom type icons should be able to be created by users, by using custom RGB color borders and a selection of custom outline shapes. The reason custom types may be useful is for specific domains where certain objects are commonly used: such as vectors, seconds, milliseconds, cartesian points, feet, meters, game characters, user accounts, etc. By making them into their own mini icon types it helps to identify them at a glance and abstract them into single entities, rather than passing around named arrays or associative arrays which all look too similar.

Find and replace should allow for three modes: targeting entire diagrams, the names of diagrams only, or the bodies of diagrams only. This helps with refactoring the names of diagrams without messing up the body of each diagram accidentally.

Global and local variable mini-icons should be allowed instead of forcing only local variables to be inherently created. In the context of games especially, global objects are often very common, and it would be useful to know if variables are global or not in the editor without having to keep this information in human memory.

Diagram metadata should be visible on the diagram tree, such as numbers next to each diagram name indicating things like: how many icons are in the diagram, how many parameters are specified in the diagram, how many branches does the diagram have. This helps show which diagrams need refactoring because they are too complex, without having to traverse each diagram and count yourself.

Readable .drn source files. It would be useful if source .drn files were readable ASCII diagrams, because then they could be parsed by text editors to perform regex operations and so on, if the drakon editor itself hasn't implemented all of those text manipulation features. It would also help unify the .drn source format to be easier to convert one type of language to another, because the diagram would stay the same only the syntax behind the scenes would change.

Breadcrumbs at the top of the editor to show where you are in relation to the Parent/Child diagram hierarchy would be useful. Imagine you are looking at the `add` diagram from earlier, but you don't know if you're in the `string` child or the `arithmetic` child. Breadcrumbs at the top, like breadcrumbs on webpages, would show you this information. This also aids in abstraction.

Autocomplete for variable names and function names based on the existing drn file would be useful.

Highlighting functions which are not defined yet in the drn, and variables which are not used yet in the diagram would be useful for refactoring and debugging before code is live.

Auto center diagrams which fit totally in the window screen space should be done automatically — not pushing the diagrams to the top right, but instead centering the entire diagram in the center of the drawing space. This should only happen if the diagram would fit in the space at once, otherwise use the existing behavior.

The zoom level in the current diagram should be displayed as an overlay, so it's apparent if the zoom is 100% or not at all times.

Luke Alan пишет на форуме языка ДРАКОН (Гугл перевел его слова на русский язык):

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

Оригинальный текст на английском языке см. здесь
https://forum.drakon.su/viewtopic.php?p=105187#p105187

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Luke Alan пишет на форуме языка ДРАКОН (Гугл перевел его слова на русский язык):

ВП>[q]Если бы у меня было время, первое, что я сделал бы, — это направил все свои усилия на новый редактор Drakon, поскольку я считаю, что это следующий большой скачок в человеческом программировании, но он требует значительных исследований и разработок для инструментария IDE, чтобы сделать его бесшовным. достаточно, чтобы люди переключались с рабочего процесса текстового редактора, к которому они привыкли.

У нас на проекте есть несколько алгоритмически сложных задач, которые пока не были успешно решены, подозреваю во многом из-за того, что мы пытались решить их в лоб, сразу начав писать код, мало что вышло, затем по одной задаче пытались рисовать классическую блок-схему, но в итоге тоже ничего толкового не получилось. Поэтому заинтересовался Драконом, т.к. пишут что но прям крут в упрощении алгоритмизации. Какую IDE посоветуете? Их вроде 2 сейчас — родная и опенсорсная на tkl?

Здравствуйте, gyraboo, Вы писали:

G>У нас на проекте есть несколько алгоритмически сложных задач, которые пока не были успешно решены, подозреваю во многом из-за того, что мы пытались решить их в лоб, сразу начав писать код, мало что вышло, затем по одной задаче пытались рисовать классическую блок-схему, но в итоге тоже ничего толкового не получилось. Поэтому заинтересовался Драконом, т.к. пишут что но прям крут в упрощении алгоритмизации. Какую IDE посоветуете? Их вроде 2 сейчас — родная и опенсорсная на tkl?

Если вы с драконом не знакомы, начните с DrakonHub (автор Степан Митькин) https://drakonhub.com/ru/
Инструкцию скачайте тут https://forum.drakon.su/viewtopic.php?p=105181#p105181
Это наилучший вариант для первого знакомства.
Недостаток: вы получите алгоритм, но не программу. Для программирования DrakonHub не подходит.

Для программирования:

Инструментальная программа ИС Дракон (автор Геннадий Тышов) по желанию пользователя автоматически преобразует дракон-программу в исходный код любого из 10 целевых языков:
С, Delphi, Java, Lua, PL/SQL, ABAP, Forth, Oberon, 1С, BASCOM.
https://bit.ly/2OOgXgN

2. Инструментальная программа DRAKON Editor (автор Степан Митькин) преобразует дракон-программу в исходный код любого из 13 целевых языков:
Java, Processing, D, C#, C/C++ (with Qt support), Python, Tcl, JavaScript, Lua, Erlang, AutoHotkey, КуМир и Verilog http://sourceforge.net/projects/drakon-editor/files/

3. Инструментальная онлайн-программа Drakon.Tech (автор Степан Митькин) преобразует дракон-программу в исходный код JavaScript
https://drakon.tech

Что выбрать для программирования? Советовать не берусь. У Тышова лучше функциональность, у Митькина лучше эргономика (people-friendly).

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Если вы с драконом не знакомы, начните с DrakonHub (автор Степан Митькин) https://drakonhub.com/ru/
ВП>Инструкцию скачайте тут https://forum.drakon.su/viewtopic.php?p=105181#p105181
ВП>Это наилучший вариант для первого знакомства.

Благодарю за консультацию.

Здравствуйте, Холодный, Вы писали:

G>>У нас на проекте есть несколько алгоритмически сложных задач, которые пока не были успешно решены, подозреваю во многом из-за того, что мы пытались решить их в лоб, сразу начав писать код, мало что вышло, затем по одной задаче пытались рисовать классическую блок-схему, но в итоге тоже ничего толкового не получилось. Поэтому заинтересовался Драконом, т.к. пишут что но прям крут в упрощении алгоритмизации. Какую IDE посоветуете? Их вроде 2 сейчас — родная и опенсорсная на tkl?
Х>А что за задачи? У меня есть новая технология я б сказал что Дракон часть ее. Или порождает Дракон. Реализует недетерминированную МТ. Интересно с точки зрения применения. И свой язык программирования

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

Здравствуйте, gyraboo, Вы писали:

G>Если в двух словах, то задачи связаны например со сравнением структурированных данных по бизнесовым правилам и выявлении общих черт и различий. Сложность в том, что нужно сравнить два набора данных, применив сложный набор правил, одни из которых могут частично исключать другие.
G>А подробнее про технологию можно почитать?
Сори. Я нигде не печатался.. Вот очень коротко на сайте того же Дракона попытался изложить. Не уверен что успешно. Очень рекомендую пример с электросчетчиком разобрать. Ну, и ко мне лично. Поговорим, пришлю материалы.. А можно конкретную задачу? Я попытаюсь предложить решение.. На примерах оно более наглядно.
Вот здесь посмотрите https://forum.drakon.su/viewtopic.php?f=62&t=6850

Вышла в свет моя книга
Учебное пособие по языку ДРАКОН для вузов

Паронджанов В.Д. Алгоритмические языки и программирование: ДРАКОН

http://bit.ly/30rhCL2

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вышла в свет моя книга
ВП>Учебное пособие по языку ДРАКОН для вузов

ВП>Паронджанов В.Д. Алгоритмические языки и программирование: ДРАКОН

ВП>http://bit.ly/30rhCL2

А где её можно бесплатно скачать?

Здравствуйте, gyraboo, Вы писали:

ВП>>http://bit.ly/30rhCL2

G>А где её можно бесплатно скачать?
К сожалению, бесплатно скачать изданную книгу нельзя.
Но можно бесплатно скачать мою рукопись этой книги
https://drakon.su/_media/24_zhizneritm20.pdf

Дополнительные сведения о моей книге
Учебное пособие по языку ДРАКОН для вузов
«Паронджанов В.Д. Алгоритмические языки и программирование: ДРАКОН»
http://bit.ly/30rhCL2

Рекомендовано Учебно-методическим отделом высшего образования в качестве учебного пособия для студентов высших учебных заведений, обучающихся по ИТ, инженерно-техническим направлениям

Рецензенты:

Терехов А. Н. — доктор физико-математических наук, профессор, заведующий кафедрой системного программирования математико-механического факультета Санкт-Петербургского государственного университета;

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

Страниц 436
Обложка Твердая
Гриф УМО ВО
ISBN978-5-534-13146-8

Библиографическое описание
Паронджанов, В. Д. Алгоритмические языки и программирование: ДРАКОН : учебное пособие для вузов / В. Д. Паронджанов. — Москва : Издательство Юрайт, 2021. — 436 с. — (Высшее образование). — ISBN 978-5-534-13146-8. — Текст : электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/449292 (дата обращения: 13.04.2021).

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

Книга доступна на образовательной платформе «Юрайт» urait.ru, а также в мобильном приложении «Юрайт.Библиотека»

Серия
Высшее образование

Тематика/подтематика
Компьютеры. Интернет. Информатика. / Информатика

Дисциплины
Программирование и основы алгоритмизации, Алгоритмические языки и программирование, Методика обучения информатике, Основы алгоритмизации и программирования, Методика преподавания информатики, Методы разработки и анализа алгоритмов, Разработка и анализ алгоритмов, Построение и анализ алгоритмов, Алгоритмизация и программирование, Основы программирования и алгоритмизации, Программирование и алгоритмизация, Алгоритмы и алгоритмические языки, Основы алгоритмизации и программирование

Хочу сердечно поблагодарить Главного редактора журнала RSDN Magazine Купаева Михаила Викторовича http://rsdn.org/account/info/12684

Дело в том, что в издательстве учебной литературы "Юрайт" Михаил Купаев был назначен редактором учебного пособия по языку ДРАКОН для вузов «Паронджанов В.Д. Алгоритмические языки и программирование: ДРАКОН» http://bit.ly/30rhCL2

Уважаемый Михаил Викторович!

От всего сердца благодарю Вас за качественное редактирование моего учебного пособия, за неоценимую помощь и поддержку в работе. Благодаря Вашим ценным замечаниям и умелому редактированию книга, содержащая 200 иллюстраций (ДРАКОН-алгоритмов), получилась высококачественной. Она издана одновременно в двух сериях: для высшего профессионального образования и для среднего профессионального образования.

Уважаемые коллеги!

На Хабре опубликована моя статья по языку ДРАКОН:
https://habr.com/ru/post/537294/

Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>На Хабре опубликована моя статья по языку ДРАКОН:
ВП>https://habr.com/ru/post/537294/

Прочёл. Опять — много эмоций, повторения мантр. Никаких обоснований того, что Дракон волшебным образом помогает писать безошибочные программы, нету.
Одни намёки, и наваливание бессмысленных подробностей вроде "аксиоматического подхода".
Ну да — ограничение возможности рисовать стрелки и произвольно размещать блоки в схеме гарантирует синтаксическую корректность алгоритма.
Ну и что? Ценность её близка к нулю — синтаксические ошибки в современном мире вообще не являются предметом борьбы.
Их в любом случае отловит компилятор; и 99.9% современных IDE указывают на такие ошибки ещё в процессе набора текста.

Чтобы претендовать на спасение жизней, нужно предложить что-то большее, чем "в нашем языке нет прямого способа задавать тело цикла, поэтому разработчик не забудет закрыть фигурную скобку".
В частности, в алгоритме летающей тарелки — ошибка. Помог ли её обнаружить Дракон? Нет, не помог.
Вместо этого начинается елозинье задом по муравейнику:

Если левый двигатель в норме, то мы включаем плазменный реактор. Так и должно быть. Здесь нет никакой ошибки

А в моей конструкции тарелки так нельзя — неисправный двигатель при подаче энергии взрывается. Ну, и где же "доказательство корректности"? Ничего подобного нет.
В общем, ДРАКОН как не обладал никакими волшебными свойствами, так и не обладает. К корректности программ он никакого отношения не имеет — нет в нём средств сопоставить алгоритм с ограничениями (предусловиями, постусловиями, и инвариантами). Всё, что есть — это способ редактирования программ, при котором экран замусоривается визуально громоздкими конструкциями, а текстовые операции типа копирование/вставка и контекстная замена затруднены.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>На Хабре опубликована моя статья по языку ДРАКОН:
ВП>https://habr.com/ru/post/537294/

ВП>

Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН

Человечество вообще ничего не умеет делать без ошибок. Ошибаются все.

В комментариях к статье на Хабре было много просьб привести доказательства утверждений, приведённых в статье, но это не было сделано.
Много эмоций по поводу аварии Боинга 737 MAX, но не приведено доказательств, что на Драконе нельзя сделать ту-же самую ошибку, которые допустили разработчики Боинга.

Много говорится про алгоритмы, но ничего не говорится ни про типы данных, ни про структуры данных.
Для гибридных языков объявление переменных делается средствами языка, который в паре с Драконом применяется.
А были ли попытки сделать язык, предназначенный для использования в Драконе?

Для примеров схем не приводится тот же самый алгоритм в псевдокоде, что бы сравнить схему и псевдокод и показать преимущество схемы.
набросайте, например, псевдокод для схемы покраски забора https://hsto.org/webt/4o/jo/nv/4ojonvww3gylmlj6hc0rkcwxfp4.png

Первое сообщение в этой теме сделано в 2012 году и за это время только 3 редактора появилось. Но в них и близко нет возможностей современных IDE, например — перехода к объявлению функции и поиска мест, где она используется. Так и не сделан контроль версий.

Рассмотрим простой пример из редактора — сравнение строк (взят первый попавшийся пример).

	В экран не влезает

Это не способствует удобству работы и уменьшению числа ошибок.

В сгенерированном коде struct String объявлена как

struct String
{
    char* Buffer;
    int Length;
};

Но где эта структура в схеме задаётся?

В статье и комментариях много говорится про то, что goto это плохо, но посмотрим на

код, сгенерированный по схеме

int String_Compare(
    const struct String* left,
    const struct String* right
) {
    // item 237
    int i;
    int leftChar, rightChar;
    int result = 200;

    // item 229
    if (left == 0) {
        /* item 230 */
        printf("String_Compare: left is null.\n");
        abort();
    } else {
    }

    // item 233
    if (right == 0) {
        /* item 234 */
        printf("String_Compare: right is null.\n");
        abort();
    } else {
    }

    // item 665
    if (left == right) {
        /* item 666 */
        result = 0;
        goto item_677;
    } else {
        /* item 238 */
        i = 0;
    }

    item_239 :
    if ((i < left->Length) && (i < right->Length)) {
        /* item 244 */
        leftChar = left->Buffer[i];
        rightChar = right->Buffer[i];
    } else {
        /* item 259 */
        goto item_253;
    }

    // item 245
    if (leftChar < rightChar) {
        goto item_249;
    } else {
    }

    // item 246
    if (leftChar > rightChar) {
        /* item 248 */
        result = 1;
        goto item_677;
    } else {
        /* item 251 */
        i++;
        goto item_239;
    }

    item_253 :
    if (left->Length < right->Length) {
    } else {
        goto item_254;
    } 

    item_249 :
    result = -1;
    goto item_677;

    item_254 :
    if (left->Length > right->Length) {
        /* item 256 */
        result = 1;
    } else {
        /* item 257 */
        result = 0;
    }

    item_677 :
    return result;

}

В этом коде goto применяется. Противоречние со статьёй.

А теперь, сравним с кодом, написанным традиционным способом

int String_Compare(
    const struct String* left,
    const struct String* right
)
{
    int result = 0;
    for ( int i = 0; i < left->Length && i < right->Length && !result; i++)
        result = left->Buffer[ i ] - right->Buffer[ i ];
        
    if ( !result )
        result = left->Length - right->Length;

    // Что бы возвращаемый результат был в том же виде, что и у сгенерированной функции.
    if ( result < 0 )
        result = -1;
    else if ( result > 0 )
        result = 1;
        
    return result;
}

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>На Хабре опубликована моя статья по языку ДРАКОН:
ВП>https://habr.com/ru/post/537294/

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

Имеет смысл пересмотреть структуру и подачу материала, вне зависимости от того, насколько он годный по существу, по качеству. Сам профессионально в разработке софта с 90-х, более четверти века, а реально читать подобное не в состоянии. Несмотря на привычку продираться сквозь многочисленные и убогие документации в корпоративном мире.
Если не удаётся достучаться до таких вот, то и до остальных не получится и подавно.

А спекуляция на катастрофе Боинг 737 MAX с кучей погибших не вызывает ничего кроме чувства гадливости, как посещение кладбища с разрытыми могилами.

Здравствуйте, Sinclair, Вы писали:

S>Ну да — ограничение возможности рисовать стрелки и произвольно размещать блоки в схеме гарантирует синтаксическую корректность алгоритма.
S>Ну и что? Ценность её близка к нулю — синтаксические ошибки в современном мире вообще не являются предметом борьбы.
S>Их в любом случае отловит компилятор; и 99.9% современных IDE указывают на такие ошибки ещё в процессе набора текста.

Наконец-то началась критика по существу.
Плюсик поставил.

На Хабре я опубликовал статью:

Как улучшить блок-схемы алгоритмов по ГОСТ 19.701-90? Эргономичный визуальный алгоритмический язык ДРАКОН. Критерии

https://habr.com/ru/post/541478/

Статья содержит критику стандарта ГОСТ 19.701-90 и обоснование необходимости создания нового стандарта для представления алгоритмов.

Здравствуйте, AleksandrN, Вы писали:

AN>Первое сообщение в этой теме сделано в 2012 году и за это время только 3 редактора появилось. Но в них и близко нет возможностей современных IDE, например — перехода к объявлению функции и поиска мест, где она используется. Так и не сделан контроль версий.

Ну, это не аргумент. Скажем для Немерла или Нитры тоже не хватает ресурсов качественную ИДЕ замутить. Но не от того, что языки плохие, а из-за того, что тупо нет людей готовых выделить средства.

Но вот я за недельки сбацан на них новый ДСЛ и таки душа радуется. Ни на каких Шарпах или СыПлюсПлюс такое за такие сроки не возможно сделать. А если вложить денег, то можно такие вещи не за неделю делать, а за пару дней.

Дракон это — тупо рисовалка блок-схем. Сделать к ней финтифлюшки вроде навигации более чем можно. Вопрос лишь в том, что за задачи он позволит решать (хоть с ними, хоть без них). Наверно есть класс задач, который он решит. Но согласен с Синклером — это точно не про корректность программ и не про AI.

AN>Это не способствует удобству работы и уменьшению числа ошибок.

+1

AN>В статье и комментариях много говорится про то, что goto это плохо, но посмотрим на
AN> goto item_677;

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

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

Вот потому лично я тяготею к DSL-ям. Где выразительность рвет все пределы дозволено.

AN>В этом коде goto применяется. Противоречие со статьёй.

В Драконе их нет. Так что не гони.
AN>А теперь, сравним с кодом, написанным традиционным способом
AN>

AN>int String_Compare(
AN>    const struct String* left,
AN>    const struct String* right
AN>)
AN>{
AN>    int result = 0;
AN>    for ( int i = 0; i < left->Length && i < right->Length && !result; i++)
AN>        result = left->Buffer[ i ] - right->Buffer[ i ];
        
AN>    if ( !result )
AN>        result = left->Length - right->Length;

AN>    // Что бы возвращаемый результат был в том же виде, что и у сгенерированной функции.
AN>    if ( result < 0 )
AN>        result = -1;
AN>    else if ( result > 0 )
AN>        result = 1;
        
AN>    return result;
AN>}
AN>

Откровенно говоря тоже говнокод. Я бы это написал как-то так:

Compare(xs : string, ys : string) : int
{
   | (x : tailX,  y : tailY) when x != y => x - y                 // строка состоит из символов префиксов и продолжения и префиксы не равны
   | (x : tailX,  y : tailY) when x == y => Compare(tailX, tailY) // тоже самое но префиксы равны, продолжаем рекурсивно...
   | ([],  _ : _) => 1  // xs содержит пустой список, а ys - нет.
   | (_ : _, [])  => -1 // наоборот
   | ([], [])     => 0  // все символы равны и списки пусты
}

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

Ну, а от объемов позволяет избавиться банальное процедурное программирование. Вводим именованную функцию и она может скрыть любой по сложности алгоритм.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>На Хабре я опубликовал статью:
ВП>

Как улучшить блок-схемы алгоритмов по ГОСТ 19.701-90? Эргономичный визуальный алгоритмический язык ДРАКОН. Критерии

ВП>https://habr.com/ru/post/541478/
ВП>Статья содержит критику стандарта ГОСТ 19.701-90 и обоснование необходимости создания нового стандарта для представления алгоритмов.

Мне кажется, что что за 10 лет пора бы было понять, что нельзя улучшить блок-съемы до уровня приемлемо для практического программировангия сложных систем. Да, что-то можно описывать в блок-схемах. Для детей осваивающих информатику. Или для каких-то далеких от программирования служащих от которых нужно описание бизнес процессов и можно удовлетворится примитивными описаниями. Но на них нельзя написать Виндоввс, Антивирус или сайт. Это слишком сложные задачи требующие более подходящих инструментов. Сосредоточьтесь на обучении. Там блок-схемы имеют право быть. Я сам учился на блок-схемах.

Здравствуйте, VladD2, Вы писали:

VD>Мне кажется, что что за 10 лет пора бы было понять, что нельзя улучшить блок-съемы до уровня приемлемо для практического программирования сложных систем. Да, что-то можно описывать в блок-схемах. Для детей осваивающих информатику. Или для каких-то далеких от программирования служащих от которых нужно описание бизнес процессов и можно удовлетворится примитивными описаниями.

Это не совсем так.
Вот пример.
Язык ДРАКОН в военно-патриотическом парке «Патриот»
на военно-техническом форуме «АРМИЯ-2021»

В рамках форума 26 августа 2021 состоялся Круглый стол:

«Актуальные вопросы развития и применения автоматизированных систем управления комплексом технических средств жизнеобеспечения объектов военной инфраструктуры»

Ссылка на <u>Круглый стол</u>

Цель круглого стола:
— обмен опытом и информацией о новых научно-технических разработках в области создания и развития автоматизированных систем управления, мониторинга и контроля комплексов технических средств,
— объединение ведущих научных школ,
— поиск партнёров и установление деловых контактов.

Организатор Круглого стола:
9-е Управление Министерства обороны Российской Федерации

Модератор:
начальник 43 кафедры Военно-космической академии имени А.Ф.Можайского, доктор технических наук, доцент, полковник Абсалямов Дамир Расимович.

На круглом столе представлен доклад И.Е. Ермакова и А.М. Муравицкого:

Русский визуальный язык ДРАКОН — инструмент для быстрой и надёжной разработки алгоритмов систем управления

ie@iermakov.ru
a_muravitsky@okbamur3.ru

Краткое содержание доклада:

В ОКБ АМУР 3 разрабатывается широкий спектр управляющих алгоритмов для ПЛК, для разнообразных промышленных, инфраструктурных и коммунальных объектов.

По нашему опыту, все языки МЭК мало приспособлены для быстрой и надёжной разработки алгоритмов управления.

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

Как следствие – разработка ведется «методом проб и ошибок», с последующей «агонией отладки».

Мы постоянно встречаем в открытых библиотеках на языке ST пропуски целых логических веток, игнорирование особых случаев – а ведь эти библиотеки используются на тысячах реальных объектов.

Как выход мы применили визуальный язык ДРАКОН (https://drakon.su/), который выводит на другой уровень наглядность и проверяемость алгоритмов управления, улучшает повторное использование логических блоков.

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

Ключевая особенность языка – двумерное структурное программирование, дающее большую свободу управляющих структур, чем классическое структурное программирование (см. И. Е. Ермаков, Н. А. Жигуненко. Двумерное структурное программирование; класс устремлённых графов. – https://drakon.su/_media/biblioteka_1/ermakov_zhigunenko.pdf).

ДРАКОН определяет однозначное размещение схем на плоскости, для автоматической реализации редакторами. Схема не рисуется, а быстро набирается блоками.

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

Кроме того, ДРАКОН непосредственно поддерживает программирование на основе конечно-автоматной модели.

Опыт ОКБ АМУР 3 по разработке систем управления на основе ПЛК ОВЕН, с генерацией кода на ST из ДРАКОН-схем:
— насосные станции;
— станции высокого давления СОЖ;
— станции поддержания пластового давления;
— тепловые пункты и вентиляционные установки;
— водозаборно-очистительные узлы;
— туннельные водооткачивающие установки;
— сверлильные станки;
— гибочные прессы;
— координатно-режущие станки;
— пищевые производства (пивзаводы и др.);
— процессы взаимодействия ПЛК с базами данных SQL.

Мы использовали ДРАКОН-редактор предыдущего поколения (ИС ДРАКОН), который позволял чертить схемы и в полуручном режиме генерировать ST-код.

В настоящее время мы ведём разработку новой интегрированной среды программирования ПЛК на основе ДРАКОН-схем.

Её преимущества: поддержка проекта ПЛК в целом, высокопродуктивный ДРАКОН-редактор с быстрым вводом схем, поддержка сильной инкапсуляции и повторного использования блоков, экспорт проекта в формате PLCopenXML.

Результатом нашего проекта должна стать отечественная универсальная визуальная система программирования ПЛК нового поколения.

Доклад вызвал интерес участников Круглого стола.

От:	Владимир Паронджанов	http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата:	23.05.12 19:31
Оценка:	21 (4) +2 -6

	От:	Трололоша
	Дата:	23.05.12 20:13
	Оценка:

	От:	Ops
	Дата:	23.05.12 21:39
	Оценка:

	От:	Трололоша
	Дата:	24.05.12 01:12
	Оценка:	+2

	От:	batu
	Дата:	24.05.12 02:28
	Оценка:

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	24.05.12 05:14
Оценка:

От:	a_g_99	http://www.hooli.xyz/
Дата:	24.05.12 11:47
Оценка:	+1 -1

От:	Курилка	http://kirya.narod.ru/
Дата:	24.05.12 12:30
Оценка:	+1

	От:	minorlogic
	Дата:	24.05.12 18:34
	Оценка:	38 (1) +5

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	24.05.12 19:32
Оценка:	6 (2)

От:	mazurkin	http://mazurkin.info
Дата:	25.05.12 11:08
Оценка:

От:	Don Reba	https://stackoverflow.com/users/49329/don-reba
Дата:	25.05.12 13:27
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	25.05.12 22:51
Оценка:	39 (2) +5

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	27.05.12 06:23
Оценка:	+6

От:	Vain	google.ru
Дата:	27.05.12 13:32
Оценка:	1 (1) +1 -1

От:	samius	http://sams-tricks.blogspot.com
Дата:	28.05.12 06:50
Оценка:

От:	AlexCab	LinkedIn
Дата:	29.05.12 12:44
Оценка:

От:	lseder	lseder.livejournal.com
Дата:	30.05.12 15:05
Оценка:

От:	Mna	404 and heavy formation
Дата:	01.06.12 19:07
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	03.06.12 13:15
Оценка:

От:	VladD2	www.nemerle.org
Дата:	13.06.12 22:13
Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	15.06.12 23:15
Оценка:	40 (2)

От:	Степан Митькин	http://drakon-editor.sourceforge.net
Дата:	17.06.12 19:55
Оценка:

	От:	Аноним931
	Дата:	21.06.12 11:35
	Оценка:	+1

	От:	VladZharinov
	Дата:	25.06.12 11:21
	Оценка:	16 (1)

Доклад «Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН»

Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине

Дружелюбный алгоритм

Превратить сложное в простое

"Это революция"

"Вторая грамотность"

Презентация нового дракон-редактора DrakonIDE в компании «Овен»

Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде разработки DRAKON Editor. Что это значит? Это значит, что ДРАКОН-конструктор DrakonHub написан на ДРАКОНе.

291 человек

Больше всего посетителей (188) здесь было

Космический ДРАКОН.
Как заброшенный проект "Роскосмоса"
подарил язык литовской медицине

Презентация нового дракон-редактора DrakonIDE
в компании «Овен»

Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде разработки DRAKON Editor.
Что это значит?
Это значит, что ДРАКОН-конструктор DrakonHub написан на ДРАКОНе.

От:	Wawan	http://www.wawan.ru/resume
Дата:	25.06.12 19:25
Оценка:	+1

От:	_Obelisk_	http://www.ibm.com
Дата:	01.07.12 15:58
Оценка:

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	08.07.12 18:10
Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	17.10.14 18:10
Оценка:

От:	Stepan Mitkin	https://drakon-editor.com/
Дата:	30.05.17 07:20
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	30.05.17 08:29
Оценка:

	От:	Arsen.Shnurkov
	Дата:	16.07.17 07:40
	Оценка:	18 (1)

От:	Эйнсток Файр	Странный реагент
Дата:	23.10.19 17:21
Оценка:	-1

От:	TaF	http://arpadar.ru
Дата:	15.11.19 06:01
Оценка:

	От:	Холодный
	Дата:	24.10.20 08:36
	Оценка: