DRAKON.SU

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

Также заметил что объявление переменной byte val; Вы вынесли в икону Модуль. Не самое хорошее решение. Если алгоритм сложный и много переменных то искать их будет неудобно. Лучше сделать отдельно схему Примитив и в ней описать все переменные по блочно.

Опишите как работалось над этой задачей (имею ввиду "Вот подружил ИС ДРАКОН с Ардуино") ?

На каждый язык программирования, если у него есть поддержка переходов типа GoTo, можно создать текстовый файл с описанием его конструкций if, знака комментария, знака перехода и знака метки перехода. Своего рода таблица по которой ИС Дракон понимает как ему для этого языка обозначить if и вышеупомянутые конструкции согласно синтаксису языка. В поставке ИС Дракон уже есть набор языков C++, Java и другие. Вот и для Ардуино я сделал такой файлик. Показал его "ИС Дракону" и он стал генерировать код на нужном языке. Созданный файл скачать можно выше.

Данное замечание считаю очень важным.
Я полностью согласен с участником Arhat109.

Текст надо писать не в окнах (и не в подвале), а прямо в иконе.

В DrakonBar можно двигаться по шампуру, не закрывая окно редактирования текста. Т.е. получилось что-то типа линзы. Режим экспериментальный, тестируем.

Окно редактирования текста — ненужный и вредный элемент.
Редактировать текст нужно прямо в иконе.
1. Так сделано в системе Visio.
2. Так сделано в редакторе Фабула.
И это очень хорошо.

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

Дмитрий, похоже, что мы говорим о разных вещах.

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

Дмитрий, посмотрите статью
https://portal.tpu.ru/appnews/files/19104/sbornik_2.pdf

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

Я увидел из статьи, что авторы планируют разработать собственную интегрированную среду разработки (ИСР), с Питоном и микроконтроллерами. Сравнение в подходах к программированию микроконтроллеров в статье описано вскользь, хотя и достаточно метко. Авторы совершенно не рассматривали DrakonBar, и не смогли отметить то, что идеология моего редактора довольно сильно отличается от идеологии DRAKON Editor, в котором код действительно нужно вписывать полностью. DrakonBar позволяет почти полностью собирать программу из готовых кирпичиков, и это приближает его по функциональности к Скретчу, хотя и не абсолютно, конечно. У любого из трех вариантов есть плюсы и минусы, но в публикации их особо не рассматривают.

В целом, статья соответствует своему названию: "Разработка ....".

Расскажите об этих отличиях

Идеология программирования Scratch:

- берем готовые блоки,
- пробуем/запускаем блоки,
- комбинируем конструкцию из блоков по правилам Scratch,
- запускаем конструкцию,
- комбинируем систему,
- запускаем на исполнение

Идеология программирования Drakon Editor:

- берем пустые блоки,
- строим конструкцию из блоков по правилам DRAKON
- наполняем блоки кодом,
- запускаем генерацию,
- запускаем на исполнение

Идеология программирования DrakonBar:

- берем готовые примеры заполненных блоков,
{ если предусмотрено генератором, то пробуем/запускаем блоки, }
{ если необходимо, то изменяем содержание заполненных блоков, }
- строим конструкцию из блоков по правилам DRAKON,
- комбинируем систему,
- запускаем на исполнение

Все три подхода, насколько мне представляется, являются примерами компонентно-ориентированного программирования.

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

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

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

Я подумаю об этом, тема интересная. А пока приложу статью с Хабра, в которой можно почитать про КОП.