roboforum.ru

[Angel71]

...
Переносимость - не ахти какая.

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

[=DeaD=]

Переменные делать глобальными кроме случая создания своего "кубика" (aka своей функции).

Все кубики делать с 0..N входами и 0..1 выходом - типичные функции.

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

Вопрос только в том, давать явно загонять формулы или нет? По идее можно разрешить кубики типа "+", "-" и т.п. с 2 входами и 1 выходом, а можно разрешить кубик f(x) в котором вбивается текст и получается 1 выход.

А переменные стыковать в эти входы и выходы.

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

Кстати, язык Си у нас на информатике не изучается и не планируется. Только Паскаль.

Паскали под МК куцые какие-то

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

А если сделать локальные переменные одним цветом, а глобальные - другим?

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

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

Где же с этим проблем то нету? У Java и то куча граблей в этом месте. Каждая железяка норовит новые фишки подсунуть.

А вы задавались вопросом: программированию на каком-либо языке или созданию и управлению роботами собираетесь учить детей? Это - две совершенно разные задачи.

ИМХО учить надо программированию в первую очередь, а во вторую - управлять роботами.

[Sergey Filippov]

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

- Это у NXTG крупноваты. В Robolab кубики идеальны. Много влезает в окно.

Я, конечно, писал не про дизайн и размер на экране, а про функциональную насыщенность...

Ох уж эта насыщенность. Отказываемся мы от нее, стараемся все алгоритмы писать на нижнем доступном уровне. В NXTG есть оба варианта: можно скомандовать "МоторАвперед, моторВвперед, жди1000градусовНаВ, стопМоторы" четырьмя блоками, а можно тоже самое одним. Эффект, правда, будет другой: в первом случае все выполнится втупую и робот слегка пролетит дальше (или продолжит движение), а во втором включится встроенный ПИД, который долго будет останавливать моторы в строго определенной позиции.
В нашей версии стоит использовать и то, и другое. Причем можно еще сильнее разделить уровни детализации, привязав к размерам конструкции. Например, у стандартного робота будет известно расстояние между колесами, масса и передаточное отношение. Тогда команда "Поверни90ГрадусовНаправо" сможет выполняться с высокой степенью точности. А если еще гироскоп трехосевой поставить, то вообще можно чудеса творить .

[Michael_K]

В Robolab многозадачность и подпрограммы вполне обходятся без локальных переменных.

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

С и графическая надстройка?... Одумайтесь...

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

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

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

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

[=DeaD=]

Так как насчет явного разделения локальных и глобальных переменных?

[Sergey Filippov]

В роболаб, насколько я понял, есть "веревки с данными" - их область видимости явно указана связями.

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

А он-то при чем? Если ему надо одну и ту же функцию использовать в двух ветках у него что, выбор есть? А если он эту функцию готовую взял из библиотеки? Ему что в каждую из библиотечных функций залазить и проверять, не пересекаются ли имена?

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

[Michael_K]

Так как насчет явного разделения локальных и глобальных переменных?

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

Такими объектами могут быть периферийные устройства,
Например объект Мотор с членами (свойствами, методами - неважно)
Мотор.Стой, Мотор.Скорость или Мотор.Угол и т.д.
Точно так же - Дисплей.Очистить Дисплей.точка, Дисплей.Картинка
Такие объекты - глобальные по определению, то есть доступны отовсюду.
В число объектов можно включить и специальный объект - кластер глобальных переменных.
Например, ГлобальнаяПеременная.X = 77; или ГлобальнаяПеременная.Счетчик++;
Все остальные переменные - локальные.

Единственное, что тут возможно придется полуавтоматизировать - это инициализацию
(читай объявление). По мере написания программы, если ученик пишет
ГлобальнаяПеременная.Привет++; то система должна спросить у него
(в какой-то момент), как ее инициализировать (и возможно ее тип).

Я по-прежнему против веревок с данными.

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

]
Веревками данных с блоками команд соединяются либо константы, либо объекты (контейнеры-переменные, порты и пр.), либо их значения.

И что же это в терминах нормального языка, если не локальные переменные?

[=DeaD=]

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

[Sergey Filippov]

Так как насчет явного разделения локальных и глобальных переменных?

Можно сделать так. Каждая область видимости подсвечивается своим цветом. И все переменные, относящиеся к ней, тоже. Идеология интересная. Главное, защитить от нее начинающих. Представьте себе, встречаются синий count и зеленый count, и один другому говорит...

[=DeaD=]

Выбирай, Нео - красную или синюю переменную ты будешь использовать?

[SMT]

Предлагаю еще раз посмотреть на то, что у меня получилось год назад - просто для обсуждения и критики. Это была упрощенная калька с MS VPL. Данные и сигналы передаются "сквозь" блоки, модифицируясь при необходимости. Переменные типа var - строковые складываются как строки, числовые - математически (автоматический парсинг). Бинарные интерпретируются из Y, N, true, false, да, нет.

Добавлено спустя 1 минуту 2 секунды:
Моторы, дисплеи, бамперы и леды - все это объекты (сервисы), которые потребляют или предоставляют данные.

[=DeaD=]

2SMT: Ну то есть событийно ориентированная система получалась?

[SMT]

да - на это ориентировался.
Есть кнопка старт, но ее позже добавил - посылать команды/данные в сервисы.

[Michael_K]

Веревки - зло, плохо к ним приучать,

То есть мы приходим к стандартным блок-схемам.
Пути выполнения программы прорисованы, распространение данных через именованные переменные:

если мы не в концепции событийно-ориентированного программирования.

Про событийное - что-то не догнал...
А если в концепции, то веревки данных каким боком?

Предлагаю еще раз посмотреть на то, что у меня получилось
год назад - просто для обсуждения и критики.

Вы - странный, честное слово....
Ну напишите хотя бы инструкцию, а лучше демо-версию выложите,
Как можно обсуждать и критиковать непонятные картинки?

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

[SMT]

Репозиторий с демо бинарником (видео в посте - лучше наверное не проинструктировать)
http://code.google.com/p/rvslite/downloads/list
сам код http://rvslite.googlecode.com/svn

Добавлено спустя 6 минут 47 секунд:
А здесь можно посмотреть на последнюю версию и форму с чартами для отладки ПИД алгоритма.