roboforum.ru

Виктор Казаринов писал(а):...
Переносимость - не ахти какая.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Michael_K писал(а):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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