roboforum.ru

[=DeaD=]

А как потом школьников переводить на обычный язык?

Добавлено спустя 1 минуту 3 секунды:
Да и тогда, если связываться с событийно ориентированным языком - не ясно почему не лучше взять готовый VPL? и продублировать с упрощением?

Добавлено спустя 14 секунд:
Но сохранив визуальный интерфейс полностью.

[SMT]

ну я почти так и сделал, не затрудняясь пока UI-ными красивостями. Первые CTP с прями углами связей между блоками были жуткого вида - сейчас я еще хуже бы нарисовал. По этому сейчас так, как у Lego, и даже проще. Хотел чтобы заработало.

[Michael_K]

...там очень часто переменные используются ровно 1 раз...

Эмм... можно примерчик?

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

Гхм... Это про какую реальную программу? Не каком языке - на форте?
В си, бэйсике, паскале обычно пишут что-то вроде:
SetMotorCurrent(12)... Это неделимая конструкция -
само по себе SetMotorCurrent - не имеет смысла в общем случае,
так же как и отдельно 12.

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


Зачем же монолитные сущности разделять? Какой смысл в ОТДЕЛЬНОМ кубике "Данные 7"?
или в отдельном кубике "Информер"?

Я могу понять, например, "так проще делать виртуальную машину",
только школьнику-то от этого не легче.

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

Согласен.

Или при переводе в обычный язык всё-таки делать невидимый главный цикл и всё такое?

Эмм... Имхо, этим должна заниматься операционная среда внутри МК, зачем же одно и то же компилять и перезаписывать по сотне раз?

[=DeaD=]

2Michael_K: Ну вот примерчик

[SMT]

Гхм... Это про какую реальную программу? Не каком языке - на форте?
В си, бэйсике, паскале обычно пишут что-то вроде:
SetMotorCurrent(12)... Это неделимая конструкция -
само по себе SetMotorCurrent - не имеет смысла в общем случае,
так же как и отдельно 12.

SetMotorCurrent(12) - это если использовать концепцию передачи сообщений внутри системы. Если говорить о сервис-ориентированной среде (типа приведенной DeaD'ом на скриншоте выше), то сервисам пересылаются уведомления о событии и необходимые данные - так "ортогональнее" получается. Когда я смотрю на программу в Lego редакторе, меня сбивают с толку несколько кубиков "мотор", подразумевающих лишь сообщение мотору с определенными параметрами.
Программируя МК мы присваеваем значения регистрам или портам.

[Michael_K]

2Michael_K: Ну вот примерчик

Что-то не показательно... имхо.
Как бы в данном случае помогли веревки с данными?

Разработчики тупо сделали одно событие "ButtonPressed" на разные физически действия...
Завели бы нормально "Up.ButtonPressed", "Left.ButtonReleased", или "Enter.DoubleClick" и проблемы бы не было...
Или я не понял, к чему вы привели эту картинку...

[=DeaD=]

Или при переводе в обычный язык всё-таки делать невидимый главный цикл и всё такое?

Эмм... Имхо, этим должна заниматься операционная среда внутри МК, зачем же одно и то же компилять и перезаписывать по сотне раз?

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

Добавлено спустя 2 минуты 7 секунд:

2Michael_K: Ну вот примерчик

Что-то не показательно... имхо.
Как бы в данном случае помогли веревки с данными?

Ну как кроме веревок данных еще можно сделать конструкцию аналогичную

Код: Выделить всё • Развернуть

setMaxMotorPower(getIrRangerValue())

?

[Michael_K]

Программируя МК мы присваеваем значения регистрам или портам.

Да! Но присвоение - это неделимое действие!

Если мы напишем в ассемблере просто
"ldi r16" или просто "0x33", то компилятор ругнется
- это бессмысленно одно без другого.
А вот "ldi r16,0x33" - имеет смысл и скомпиляется.

А вы его разбили на два кубика,
которые ученик может поставить неправильно, а значит и поставит неправильно.
И ваш "компилятор" не ругается - с его точки зрения все ОК...

Добавлено спустя 12 минут 12 секунд:

Ну как кроме веревок данных еще можно сделать конструкцию аналогичную setMaxMotorPower(getIrRangerValue()) ?

Прямо так и написать. Словами.
setMotorPower(IrRanger.Value)
Где setMotorPower - это "кубик", а IrRanger.Value
с точки зрения программы - глобальная переменная, например.

Вот вы представляете блок-схему алгоритма? Я бы прямо так и реализовал. Вообще ничего не меняя.

Добавлено спустя 1 минуту 56 секунд:
Типа такого:

[=DeaD=]

2Michael_K: В том то и дело, что в блок-схемах по определению невозможно такое построить, как я указал, там всё через переменные только IrRanger.Value плохо переменной считать - это значит что постоянно питание должно быть включено, а если у нас сонар? А если нам надо его 10 раз в секунду включать, а при постоянной работе он весь аккум выжрет?

Добавлено спустя 1 минуту 3 секунды:

Типа такого:

У меня вынос мозга от этой картинки, особенно от того, что внизу ветки "нет" и "да" переходят в друг друга

Добавлено спустя 1 минуту 51 секунду:
И это всё-таки не событийно-ориентированная система, а я говорил про веревки данных в событийно-ориентированной системе.

[Sergey Filippov]

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

Нам нужно считаться с тем, как учат школьников.
1. В 5 классе они узнают, что алгоритм - это последовательность действий (команд) для конкретного исполнителя. (Только в 8-9 у алгоритма появляются исходные данные и ожидаемый результат.) Таким образом, алгоритм должен быть понятен исполнителю (и, конечно, ребенку).
2. Постепенно, с большими паузами и повторениями осваиваются базовые алгоритмические структуры: следование, ветвление, цикл, подпрограмма.
3. Сообщается, что алгоритмы могут быть параллельными, даже в Логомирах несколько черепашек трудятся на экране одновременно (это 6-7 класс, но мы Лого не проходим).
4. Объектно-ориентированный подход поначалу рассматривается в рамках игры (у нас это CeeBot, 7 класс), затем - как прикладной аспект визуального программирования (Delphi, 10 класс). События рассматриваются там же.
Исходя из этого плана, имеет смысл строить обучение управлению роботом. Сперва - следование, затем ветвление, цикл и т.д. Событийность и объекты перемещать не на первый этап. Кстати, в Robolab есть довольно приличные обработчики событий, но с моей точки зрения они вносят сумятицу в программу, как и безусловные переходы. Использовать можно, вещь могучая. Но мы пока обходимся.

[Michael_K]

И это фактически даже проще в освоении, чем такое:

Тут еще и переменные надо рисовать, и формулы.

А в варианте выше ты ставишь кубик и аргументы появляются сами заполненными
по умолчанию - остается только вписать нужное значение или формулу...

Добавлено спустя 8 минут 29 секунд:

У меня вынос мозга от этой картинки, особенно от того, что внизу ветки "нет" и "да" переходят в друг друга

Ну это я дорисовать поленился, надо, чтобы они сливались и упирались в нижнюю границу цикла

Суть в том, что когда ты создаешь управляющую конструкцию ("if" например), то ты сразу получаешь
ее целиком (скобки всегда правильно закрыты), Точно так же ты говоришь цикл и сразу получаешь
оформленные начало и конец цикла. Таким образом структура всегда семантически верная...

[=DeaD=]

Ну то есть все согласны, что событийно-ориентированные системы - это не то, что нужно на первом этапе?

[Michael_K]

И это всё-таки не событийно-ориентированная система, а я говорил про веревки данных в событийно-ориентированной системе.

Не-а... Вы спрашивали:

как можно сделать конструкцию setMaxMotorPower(getIrRangerValue())?

А в чем проблема-то с событийной ориентированностью? Просто рисуешь две (три, десять) таких блок схем и все!

Ну то есть все согласны, что событийно-ориентированные системы - это не то, что нужно на первом этапе?

Эмм...

[Виктор Казаринов]

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

[=DeaD=]

Вопрос в том, чему (а уж потом - на чем) учить детей в 5 классе, а не в том, насколько круты ПЛИСы, событийная ориентированность и распределенные вычисления.