DRAKON.SU

Язык ДРАКОН.
Алгоритм и программа в одном флаконе

Вот пример по принципу Числитель – Знаменатель.
В каждой иконе действует правило:

Спасибо Геннадию Николаевичу Тышову.

Создано совместно с Сергеем Ефановым.



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

Прошу критиковать и предлагать другие варианты

Это похоже на тавтологию и трату места впустую.
Просто паузы с цифрой 50мс должно быть достаточно.

Тут пояснение не имеет смысла. Ладно бы операция сложная была. А тут операция простейшая, так её ещё и пояснением длиннющим снабжать. Снова трата места впустую, и лишняя когнитивная нагрузка.

Тут практически ошибка goto fail. Наверняка точка с запятой после строки IF лишняя. Если она не лишняя, то зачем вообще нужна строка про if?
Да, среда тов. Тышова просто блестяще справилась с задачей и таки позволила написать ахинею.


Если вариант "отображать программу в знаменателе" настраивается галочкой, то, возможно, это шаг в правильном направлении.
Что-нибудь в духе "формат отображения: только описание, описание+программа, только программа"

Поясняю идею.

1. Разрабатываем алгоритм
2. Разрабатываем программу по принципу "Числитель-Знаменатель"
3. С помощью маршрутного транслятора (автор Тышов) автоматически получаем исходный код на языке Си.
4. При необходимости вручную дописываем несколько операторов языка Си.

Выкладываю две дракон-схемы:
— алгоритм
— программу

Алгоритм


Программа


Таким образом, алгоритм превращается в комментарии, расположенные в числителе в иконах программы.


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

Мне кажется, принцип "Числитель-Знаменатель" надо соблюдать во всех иконах, а не выборочно.

Идея понравилась, но все таки надо иметь возможность переключаться между режимами:
только описание (числитель), описание+программа (числитель/знаменатель), только программа (знаменатель)". Или хотя бы между первыми двумя.

Полностью с вами согласен.
Нужны все три указанные вами режима.

Первые два режима (алгоритм и программа) я уже выложил.
Третий ваш режим: будет обязательно выложен.

Переключение между режимами, которое вы предлагаете, мне нравится. Желательно услышать мнение Геннадия Тышова и Степана Митькина
.

Пребываю в состоянии смешанных чувств. Не могу сформировать себе мнение.

С одной стороны, схема сильно растёт в высоту. Многие схемы не поместятся на экране по вертикали.
(Тут как бы возникает призрак Олега Гарипова и говорит: а ты купи себе монитор побольше. Денег не жалко, так как это вложение быстро и однозначно поможет тебе в работе.)

С другой стороны, когда комментарий сидит в той же иконе, это прекрасно!
1. По-русски часто можно гораздо чётче выразить намерение, чем самым красивым кодом. Понятнее в 10 раз.
2. Ясно, к чему именно относится комментарий. К какому именно блоку кода.
3. Визуально приятно. Комментарий запакован вместе с кодом в одну коробочку. Словами объяснить трудно. Ладненько и миленько. Кушели, как говорят норвежцы.

С третьей стороны, это намёк на то, что всё-таки надо вести борьбу за читаемость кода.
1. Одна мысль в одной иконе. Не перегибаем с вложенностью выражений.
2. Понятные и относящиеся к делу имена переменных, методов и прочая.
3. Изобретаем языки программирования, где слова имеют значение. Покамест это имеет только SQL (не к ночи будь помянут). Пока имена являются тупыми идентификаторами, поезд эргономики программирования стоит на платформе.

Тут нет ошибки, точка с запятой - не лишняя. Эта инструкция компилируется в команду чтения GPIO. Полезный результат в данном случае - сброс бита изменения порта.
С.Д. Ефанов.

Если так, то в той строке обязательно нужен поясняющий комментарий. Ещё лучше фигурные скобки вместо точки с запятой. Ну либо #define.

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

Это обязательно надо исправить.

Насчёт фигурных скобок - полностью согласен. А насчёт комментария - это уже к Паронджанову...
Ефанов.

Тут еще подумал:
1) если сделать обязательным для заполнения и "числитель" и "знаменатель", то по сути получится "самодокументируемый" код, о чём так долго "мечтали большевики".
2) надо как-то отделить алгоритм от программы, чтобы можно было программу заполнить на любом языке программирования. Таким образом, можно будет использовать алгоритм для построения программ на любом языке.

Вы правы. Цель именно такая.

Простите, я не понял. Что значит "отделить"?
Выше я показал ОТДЕЛЬНО
— дракон-схему алгоритма,
— дракон-схему программы на языке Си.

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

Так что они уже отделены.
Вопрос. Что еще нужно отделить?
Просьба пояснить.

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

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

Я придаю большое значение этой теме.

Здесь описана важная новая идея.

Прошу критиковать и высказывать предложения

viewtopic.php?p=100931#p100931

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

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

Дмитрий, спасибо. Что такое ТС?

Уточненная программа Сергея Ефанова, формирующая паузу 50 миллисекунд.



Для удобства сравнения тут же выкладываю исправленную дракон-программу
"Лазерный тренажер стрельбы"

ТС - топикстартер, инициатор темы.

viewtopic.php?p=100968#p100968

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

Уже 50 лет назад придумали метод пошагового уточнения (stepwise refinement), который является составной частью структурного программирования.