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

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

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

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

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

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

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

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

Я просто увлекался (да и сейчас все подмывает заняться) автоматным программированием, у нас это Шалыто (ИТМО) популяризирует (Switch-технологии), наваял такую штуку

Автор: Marty
Дата: 31.07.08

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

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