Визуальный язык Дракон (программирование микроконтроллеров)

[Smitt&Wesson]

Сообщение от Vapaamies

Текстовое представление у этой красоты есть? Типа как в DFM?

Да есть. В данный момнт он может генерировать код на Ассемблере, С++, Java. Причём, как я понял из описания, спецификации ассемблера, т.е. соответствие мнемоники командам исполняемого кода можно задавать в специальном файле - декларация. Поэтому он не привязан к определённому типу микроконтроллера.

Сообщение от _Bers

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

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

Главное, что есть у дракона, и даже близко нет у редакторов UML - у него есть среда исполнения драконо-кода.

Ну по крайней мере какое то её подобие.

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

зы/ критика дракона - глупа.

Нужно иметь в виду, что Дракон предназначен в основном для микроконтроллеров. При размере их памяти максимум до 32 Кб, неструктурированность не очень напрягает.
Да, в некоторых сгенерированных ним листингах на С++ присутствует оператор goto, но этот недостаток легко устраняется при шлифовке кода в редакторе языка, более высокого уровня.
Я не считаю это существенным недостатком.

[Smitt&Wesson]

................

[Utkin]

Одна из особенностей языка UML - он мертв без ИДЕ.

Rational Rose, вообще ИДЕ для него много. UML не предназначен для исполнения, он предназначен проектирования. Но при этом может быть переведен в нужный язык программирования при минимуме требований. При этом есть средства автоматического перевода в ИДЕ соответствующих языков.

у него есть среда исполнения драконо-кода.

А зачем средствам UML исполнять драконовский код? Глупость какая-то. Для тех кто в танке повторяю - UML-универсальное средство моделирования. Но! Уважаемые ИДЕшки на вроде Эмбекадеровского Рад Студио или Визуал Студио есть свои редакторы UML, которые также переводят то, что там напроектировали в соответствующий программный код. Если и так не ясно еще раз по буквам:
- Хотим делфи
- Открываем Делфи
- Находим/доустанавливаем UML-инструмент
- Работаем
- Переводим в юнит(ы), насколько это возможно.
Драконовские схемы принадлежат только дракону. UML это стандарт проектирования и большая часть диаграмм тупым переводом может быть переложена на нужный язык программирования.

зы/ критика дракона - глупа.

Тупой и ничем не подтвержденный тролльский вброс фаната Дракона. Ни одного аргумента не представлено.

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

Я не большой спец в UML, но предполагаю, что есть ИДЕшки, которые умеют также генерить по шаблону.

При размере их памяти максимум до 32 Кб, неструктурированность не очень напрягает.

Прикольно. Как быть с микроконтроллерами, для которых объем памяти поболее 32К?

Я не считаю это существенным недостатком.

В автоматически сгенерированных программах это и так преимущество, а не недостаток. Смысл править генерированный текст, если потом в ассемблере опять будут JMP? Goto не нужен именно на этапе проектирования, а на этапе исполнения программы всем класть и так наверно даже проще и быстрей.

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

Давно пора, а то наваяют, потом ракеты падают (Дракон юзают в космической промышленности).

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

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

[Smitt&Wesson]

Rational Rose, вообще ИДЕ для него много. UML не предназначен для исполнения, он предназначен проектирования.

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

А зачем средствам UML исполнять драконовский код? Глупость какая-то.

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

Прикольно. Как быть с микроконтроллерами, для которых объем памяти поболее 32К?

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

В автоматически сгенерированных программах это и так преимущество, а не недостаток. Смысл править генерированный текст, если потом в ассемблере опять будут JMP? Goto не нужен именно на этапе проектирования, а на этапе исполнения программы всем класть и так наверно даже проще и быстрей.

Если прога пишется "для себя" то да. Мне лично пофигу, есть там готы, нет там готов, но если предполагается встраивать этот кусок в структурированную прогу, плевков от структурщиков не оберёшься.

Давно пора, а то наваяют, потом ракеты падают (Дракон юзают в космической промышленности).

Юзали. Его недавно рассекретили. А ракеты падают реже самолётов и внезапно, не из-за ошибок в программном обеспечении.

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

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

[Utkin]

А ракеты падают реже самолётов и внезапно, не из-за ошибок в программном обеспечении.

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

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

Сейчас на данном этапе безусловно данный вариант вреден для проекта. Но если бы проект изначально проектировался с UML проблем было бы меньше.

плевков от структурщиков не оберёшься.

Объясняете - код генерирован автоматически. Если не понимают, ну не знаю это уже проблемы с тараканами в голове. Вы здесь однозначно не причем.

А ракеты падают реже самолётов и внезапно, не из-за ошибок в программном обеспечении.

Самолетов больше и летают они чаще, уровень юзеров хуже.

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

Не важно. Важно что сейчас одна из методик такая - сначала проект в UML, потом это дается программистам, которые занимаются реализацией. Фактически программисты становятся техническими специалистами переводящими с языка на язык. Базовые основы и ключевые моменты проекта уже расписаны системным аналитиком / проектировщиком / руководителем проекта. И метода данная модная и распространенная.

[Smitt&Wesson]

Фактически программисты становятся техническими специалистами переводящими с языка на язык. Базовые основы и ключевые моменты проекта уже расписаны системным аналитиком / проектировщиком / руководителем проекта. И метода данная модная и распространенная.

С этим трудно не согласиться. Алгоритмы давно и тщательно отработаны. Я тоже себя больше переводчиком ощущаю, чем программистом. У меня с прошлых времён, накопилось дофига книг с алгоритмами и прогами, но все они написаны, какая на бейсике, какая на паскале. Есть фортрановские алгоритмы, сишные. Есть даже Фокал и Форчь (Fortch). Вот и приходится знать их все (синтаксис), что-бы вставить кусок в свою прогу.
Печалька

Ща надыбал в Драконе одну несуразицу. У меня по брейку (break) прога должна выходить из цикла, а он ветку не переносит за пределы цикла. Блин, косяк.
И ещё пара косяков.
1. Ветвление идёт только по правой стороне Ифа (картинка внизу)
2. "Да" - "Нет", у него-же не меняются местами. Отменяю претензию, нашел как меняются.
Начинаю подозреват, что автор, мягко говоря 3,14здит, что на этом ракеты летают.
Блин, начал разочаровываться.

[Utkin]

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

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

Начинаю подозреват, что автор, мягко говоря 3,14здит, что на этом ракеты летают.

Думаю нет. Но как летают сами знаете.

Блин, начал разочаровываться.

Не торопитесь. Слишком мало уделили времени, возможно косяки решаются правильной настройкой, которую Вы не сделали потому что не знаете о такой возможности. Этот вопрос надо задавать там где пользуются Драконом.
А про UML тоже почитайте. Я сначала тоже считал его так себе, но когда делал проекты принудительно (для контрольных и курсовых), то понял, что идея не лишена смысла.

[gtyshov]

Smitt&Wesson, Вы рано разочаровываетесь.

Пока Ваших знаний языка Дракон недостаточно.
Надо прочитать описания языка в книгах С.Д. Паронджанов.
http://drakon.su/biblioteka_1/start - Здесь скачайте книгу "Язык Дракон. Краткое описание".

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

======

ИС Дракон - интегрированаая среда имеет широкое применение, смотрите тему "Применение ИС Дракон" - http://forum.oberoncore.ru/viewtopic.php?f=78&t=5033
www.drakon-practic.ru

[_Bers]

Сообщение от Utkin

Rational Rose, вообще ИДЕ для него много.

Это редактор. Не путайте.

(кстати, как редактор - говно редкостное. yEd, eDraw max, да что там - exel и то, лучше подойдёт для таких задач)

Это не среда разработки. И я не смогу исполнять код языка. Пусть это "визуальный код". Но это - код. UML - это язык.

Я хочу видеть конструкцию в действии, а не в сферическом вакууме.

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

Толку от этого будет не меньше, чем от вашего Rational Rose

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


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

[Smitt&Wesson]

Сообщение от Utkin

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

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

Сообщение от gtyshov

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

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