DRAKON.SU

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

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

Вторая "строка" - "зуммер" подключен к порту 8 и получает целое число в параметр "частота", которое ему выдает блок "джойстик", сам подключенный к порту №1. третий параметр - также целое число - количество миллисекунд "сколько петь времени".

Третья "строка" - вывод текста на дисплей из переменной "string name", предваренный текстовой константой "Oled I2C", в 1-ю строку дисплея с яркостью 255.

В целом, тут надписи играют ровно туже самую роль комментариев и при улучшении картинок могут быть просто убраны за ненадобностью. Присоединить блок "get button" ко входу "порт№" как видим не представляется возможным: форма стыкующегося узла - иная, поскольку "не тот тип данных".

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

Кто и что думает по этому поводу? Можно ли это внедрить в ДРАКОН, внутрь икон где применимо "выражение"?

Я не понял, что изображено на картинке.

1. Слева желтый ЦИКЛ. Это действительно цикл, то есть повторение?

Что именно повторяется?
Вверху желтой плашки есть неразборчивая надпись. Что именно написано? Это слово ВЫПОЛНИТЬ? Или нет?

2. Желтый ЦИКЛ охватывает три элемента: светодиод, зуммер и Oled I2c.

Что это значит?
Эти три элемента последовательно вступают в работу? Или нет?
О чем тут вообще идет речь?

3. Почему светодиод вверху, а зуммер внизу?
Что это значит? Какой смысл?
Что значат здесь верх и низ? Или они ничего не значат?

4. Почему Oled I2c в самом низу?
Потому что он позже всех вступает в работу в ЦИКЛе? Или нет?

5. Я задал вопросы только по левой части картинки. Потому что мне показалось, что левая часть главная и описывает алгоритм.
Я правильно выделил левую часть, как главную? Или я ошибся?

6. Почему светодиод и зуммер коричневые, а Oled I2c зеленый?
Что означают разные цвета? Или они ничего не значат?

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

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

Светодиод - подключен к порту №1 (вывод МК) и может быть включен или выключен, что определяется результатом, возвращаемым из кнопки "getbutton". Если кнопка нажата - светодиод будет включен, если отпущена - выключен. Кнопка в той библиотеке, откуда я её взял - некая типовая "по умолчанию" .. не смотрел внимательно. Взял просто как пример функции, возвращающей логическое значение.

Зуммер - подключен к порту №8 и может пищать с заданной частотой в течение указанного времени в мсек. Тут, просто показано, что частота получается как результат, возвращаемый из блока "Джойстик" как целое число. Джойстик возвращает уровень напряжения в виде 0..1023 (чтение 10-и битного АЦП) для напряжений 0..5в, вот этот результат и попадает как значение для частоты Зуммера. Сам Джойстик оказался тоже подключенным к порту №1 (просто так вышло при сборке, не поменял значение по умолчанию).

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

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

P.S. картинка кликабельна и показывается в увеличенном и разборчивом виде.
P.P.S. Цвета блоков частично приняты в Ардублоке как разграничение "базовых" и библиотечных" икон-блоков, но по большей части этот выбор произволен .. но, глядя на такие алгоритмы у сына, тоже вот задумываюсь под какое свойство языка DDL можно было бы использовать цветовое деление ..

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

Попробовал изобразить Икону "Выбор" в которой используется объект данных с именем "Стоп", класса "Кнопка" (картинкой) и возвращающий логическое выражение.

Мне кажется это достаточно наглядно, но смущает "нестыковка" округлых боков объекта и углов иконы .. может тогда надо поменять что - чего обозначает?
То есть, сделать угловые боковины - для булевых значений, а для целых взять какие-то ещё?

Есть идеи на что опереться?

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

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

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

На вашем рисунке использованы теже самые соединительные лианы "вправо" от блока к блокам описания требуемых данных, которые Вы и предложили мне заполнить. В стандартном ДРАКОН вместо блоков используется (и тоже справа) икона "комментарий" для описания данных.

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

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

Очень хорошо. Приветствую ваш вариант.

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

Вот примерно так, я вижу дополнение языка ДРАКОН использованием данных и функций. Возможно, было бы правильнее рисовать не Иконы-действия, а иконы - вызовы, но у меня уже "сил не хватило" тоже.

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

Выношу на Ваш высокий суд. Особенно интересно мнение Владимира Даниэловича.

Очень хорошо, тем более, что высший судья (ребенок) одобрил этот вариант.

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

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

Если у вас возникнут трудности, я попытаюсь вам помочь. А если трудностей не будет, то мне лучше отойти в сторону и не отвлекать вас от дела.

============================

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

Прочитал вот тут: https://sourceforge.net/p/drakon-editor/discussion/general/thread/ad3441fe/?limit=25#1c8e

..

Да, спасибо. Икона "ромб" появилась из-за сложностей рисования в Libre Office Draw .. конечно же ни одной Иконы самого ДРАКОН имзенять не планируется, как и его правила. Все мои нововведения онтосятся только к процессу интегрирования визуального представления и определения данных в алгоритмах на ДРАКОН. Ну .. чтобы из языка алгоритмирования его можно было бы превратить в полноценный язык программирования.

Самостоятельно или + какой-нибудь "ФЛОКС" как язык определения данных. Но использовать данные - все одно приходится в самих ДРАКОН-схемах .. вот, пока смотрю как можно расширить и стандартизовать эту часть. И вот в этом направлении, считаю вашу критику и даже просто замечания - исключительно полезной как автора ДРАКОН.

P.S.
На приведенной рисунке есть такой момент: у каждой "иконы объекта" есть целочисленный параметр "порт". В Ардублоке - это номер ноги, куда подключается устройство в электрической схеме .. подумалось:
1. Можно сделать "автоконтроль", что к микроконтроллеру не будут подключены "лишние" устройства или использованы у него "лишние ноги";
2. Можно вынести в часть DDL описание привязки конкретного объекта к ногам плат и соответственно, не тащить параметр "порт" на каждую икону. Вместо него можно размещать "Идентификатор" объекта, что ближе к ЯВУ. С другой стороны, так нагляднее для схем управления .. мне кажется. С третьей стороны .. убрав порт в описание - можно легко изменять привязку объектов к ногам, также как и добавлять "прочие" настройки объектов..

В общем, опять требуется совет: что оставлять на иконе объекта данных, а что убрать в часть определений языка DDL (типа ФЛОКС) ..

поправил Икону Выбор.

А также предлагаю такое вот "определение" класса для части языка DDL. Пока только простое определение без зависимостей и фактически единственным методом _get(), который вызывается неявно, присоединением иконы объекта к выражению своей левой боковиной (использование в правой части выражений).

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

==================
Мелкое замечание по определению класса: Вместо true и false лучше писать Да и Нет.

Хотелось бы услышать мнение остальных участников, в т.ч. и разработчиков редакторов, а также активных пользователей системы ГРАФИТ-ФЛОКС, насколько этот подход перспективен в части развития языка ДРАКОН от языка схем и алгоритмов, до языка программирования?

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

| .. | -- void "неизвестный" или "любой, никакой" тип данных. Присоединение запрещено.
( .. ) -- boolean, bool, bit, овал для логического типа boolean, bool, bit
<.. > -- short int, знаковое целое 1 байт .. ?как отображать беззнаковые целые?
<< .. >> -- int, знаковое целое 2 байта
<<< .. >>> -- long int, знаковое целое 3 байта. Средняя скобка - пунктиром. И для 4 байт - 2 средних скобки пунктиром.
$ .. $ -- float, double, волнистые боковины для типа float, с аналогичным удвоением для двойной точности.
{ .. } -- decimal, плавные края с выступом посередине высоты. Фиксированная точность: ?как отображать точность?
[ .. ] -- char, символ .. и тут тоже вопрос кодировки. Как, чем и надо ли?

Мультипликаторы или как их там по науке зовут:


Предлагаю из вышеприведенной кракозябры оставить только нижнюю границу, что-то в виде двойной линии: ====

Составной объект - ??? пока не знаю как.

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

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

Желательно показывать примеры, то есть скриншоты и рисунки в форматах jpg и png. Примеры и еще раз примеры. Много примеров.

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

Да, с картинками - лучше. Порисовал, посмотрел .. предлагаю второй вариант стыковочных узлов (боковин) для базовых типов данных большинства ЯВУ, в формате С/С++ (для микроконтроллеров).

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

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

У иконы типа decimal обрисовал красным пунктиром зону отрисовки названий или значений. Хотел показать что от краев должно оставаться какое-то место. Также сделана попытка показать массивы и в данном случае string - как массив символов. Для типа double попробовал показать, что массив - двумерный, но этот вариант мне кажется неудачен.

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

P.S. В очередной раз "обсуждения" как-то не намечается .. не понятно: то ли я изобретаю велосипед, то ли это никому непонятно, то ли никому не интересно ..

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

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

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

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

P.S. Для начала хотя бы часть задач поставьте. Что и для чего. Проблема, источник и способ решения.
А в том виде, как оно есть сейчас ("хочу прикрутить DDL к Дракону") - это кустарщина.

Спасибо за критику, она безусловна верна - это кустарщина. Но .. я потому и пришел сюда, к Вам - профессионалам по языкам и когнитивному восприятию! .. за помощью, и надеюсь её тут получить в дополнение к здоровой и верной критике. В частности, хотелось бы (и не только от Вас, Алексей) получить развернутые пояснения, ещё лучше если по-пунктно:

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

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

Я это к тому, что визуальное программирование - наглядно, и конечно же делается для детишек в первую голову. Они тоже достаточно быстро вырастут, не переживайте. Но, что-то мне подсказывает, что Вы не переводите вручную операторы ЯВУ в Ассемблер, а затем не кодируете в коды команд и тем более не перводите их в двоичный код побитно .. так ведь? За вас это делает компьютер. Я даже сильно уверен, что как кодируются и что означают те или иные биты той или иной команды вашего любимого процессора - вам даже и неизвестны от слова "вовсе".
Вот и тут то же самое ..
.. или я не прав? Можете развернуто пояснить это предложение? Ну .. в смысле что вы имели ввиду под "поколение Макдоналдс"..

3. "По сравнению с любым текстовым языком здесь эргономика просто отрицательная..."
Упс .. а вот тут ну просто прошу "на коленях" развернуть детально ответ. Очень интересное утверждение. То есть, Вы считаете, что эргономика в т.ч. и ДРАКОН - хуже чем текстового представления программы на ЯВУ? Если честно, то как-то не верится судя по вашим постам тут и на Обероне.. сильно жду развернутого разъяснения. Заранее благодарен.

4. "Для повышения эффективности разработки софта, как говорит мой тридцатилетний опыт, на данном этапе нужно не только визуальное представление развивать, но комплексную организацию всего цикла разработки."
Это как раз понятно, и полностью согласен с таким подходом. Но, всему свое время. Сделать сразу и изменение к ДРАКОН И компилятор под новое представление И систему разработки И сопровождения, отладки кода .. извините, но я ТАК не умею.

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

6. "Думаю, о том, что все усилия направлены не туда."
Ок. Согласен .. а КУДА надо направить усилия по Вашему мнению? Очень интересен развернутый ответ .. тоже жду.

P.S.
"Для начала хотя бы часть задач поставьте. Что и для чего. Проблема, источник и способ решения."
Так ставил уже несколько раз! Да, кустарщина. Ну так и пришел к Вам за помощью и советами и подсказками, чтобы не городить велосипед. Подключайтесь!