OberonCore

Угу, нам уже написали, что кое-кто кириллицу не переваривает

Мы принимаем участие в Астраханской интернет премии.
Если хотите поддержать наш проект, пожалуйста, проголосуйте по этим ссылкам:
(там можно каждый день голосовать)

http://www.arip.pro/clauses/business-and-innovation/
http://www.arip.pro/clauses/science-and-education/
http://www.arip.pro/clauses/start-up-of-the-year/

Спасибо всем за Вашу поддержку в голосовании на arip.pro! Мы прошли в финал в двух номинациях http://www.arip.pro/press-center/the-fi ... -stage-of/.

А еще у нас проходил региональный этап Imagine Cup, где мы заняли 2-е место .

Вот тут можно посмотреть видео, которое мы презентовали на конкурсе .

Наша команда одержала победу на конкурсе IT-start 2013, http://www.it-start.pro/node/30.

Кстати, мы ищем разработчиков на C# в Visual Studio под .NET и Silverlight, а также преподавателей-консультантов по обучающим курсам.
Если Вам (или, мб, Вашим выпускникам) интересно принять участие в нашем проекте, напишите в ЛС или на почту: dagrachev@list.ru.

Сегодня к нам Сколково приезжало. Пекка Вильякайнен даже свою книжку с автографом подарил. А ребята с РВК сказали, что у нас хороший проект и коллекцию дисков подарили

Если кому-то интересно, тут можно скачать нашу презентацию.

А вот тут небольшой набор слайдов, показывающих, что Semantic IDE дает при обучении программированию.

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

Среде и не требуется специально "узнавать" об окончании.
Для каждого задания готовятся тестовые данные. Автоматом или нет - мы тут еще работать будем.
Тесты проходят - задача закончена.
Можно оценивать все другие показатели.

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

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

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

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

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

В то же время, как правило, комбинаторика вариантов техпроцесса из техопераций какая-то будет оставаться. Формализуемая, например, моделью по Расторгуеву: viewtopic.php?p=77336#p77336. И вот тут в развитие идея такая. Для конкретной задачи определять прежде всего, как обучаемый строит те или иные имена. Например, если к обычной технологии обратиться - то есть справочники техопераций, технологий, тарифно-квалификационные... И технолог делает что-то своё тогда, когда в них решений не находит.
Если спроецировать это на ИТ - то имя-процедуру заданного назначения можно целиком "сочинить", можно взять целиком библиотечную... а можно сконструировать из либ и оригинальных элементов...
И вот среда может проверять, как поступил пользователь. Он сначала полез в справочники, а потом начал сочинять, или наоборот?.. Заметим, что в конкретной ситуации обучения то и то м.б. правильным... это, ессно, составитель заданий решает...

Кстати, ещё в копилку обоснований институционального подхода. Тут рассказывали про Як-130, так вот среди прочего там реализована операция автоматического "приведения в горизонт" по команде пилота. Противники, пожалуй, воскликнут: "- Как можно! В практике же этого, скорее всего не будет! Зачем?"... Но, видимо, разработчики какую-то цель этим преследуют... может, потому, что владеют той самой теорией деятельности на современном уровне?..

Это - не проблема с технической точки зрения.
Вопрос в формализации постановки задачи: выполнение действий в определенном порядке и оценивание именно порядка действий, а не количества.

Именно... Отсюда и обсуждение модели деятельности как средства для педагогических целей и методов. Конкретно - формализуем решение задачи, например, в виде структуры работ, назначаемых исполнителям. Т.к. Вы рассматриваете многоагентный подход - то пусть исполнитель и будет многоагентной средой. Вот её воспроизводим в искусственной среде (той же СемИДЕ). А используем неоднократно, как и положено в ИТ - сначала для описания работы персонажей над системой (в фазе построения полного ЖЦ), потом и для описания работы персонажей с системой (в фазе применения). В любой задаче структуру решения проверяем - для учебных целей м.б. по одним критериям, для практических по другим, для исследовательских по третьим (которые, разумеется, могут и пересекаться). Вот так как-то...

Сложность - это свойство задачи.
Трудность - это свойство относится к ученику.
Насколько трудно ему выполнить данную задачу. Это - в зависимости от знаний и умений.

Да, там и уточнил смысл выбора таких слов. Кстати, "повторно используем", ессно, формализацию задачи как структуры работ... а то предложение нечётко построено... среду исполнения же просто используем одну и ту же... для чего она должна включать все роли, необходимые в полном ЖЦ системы (для начала - самой СемИДЕ как предмета разработки в ней же ). Так и получается использование решения сначала в задаче разработки среды, затем в задаче разработки других систем в среде... и аналогично с применением...

Основное достоинство, которое я вижу в ActiveOberon и GO это следование функциональным уровням программы. Вот например как уровни современной OS Android сопоставимы с функциональными уровнями:

1. The object. - View
2. Upgrade to the states. Finite State Machine. - Activity
3. To implement the switching functions / equalization / branching. - BroadcastReceiver
4. To implement the function parser (parsing) / compilation. - Intent
5. By field of memory and the physical devices. - NDK
6. By time intervals. - NDK
7. On the search function / insert data into the repository. - ContentProvider
8. Along the route objectives. Target way. - Service
9. By the user and planned processes. The sensitivity analysis.

1 уровень ООП, тут многое ясно.
2 уровень конечные автоматы или активные классы в ActiveOberone.
3 уровень MPI - параллельное программирование. Уровень пересылок (такой был в Графит-Флоксе кажется, когда этот оператор := значил физическую пересылку данных между вычислителями?)
4 уровень с натяжкой можно отнести к регулярным выражениям (которые впрочем не исполняются параллельно на современных системах)

Остальные уровни пока IMHO явно не реализованы в компиляторах.

Дополнительные уровни:
8 уровень это скрипты в ОС, которые запускаются например через демон cron или через например Prolog-подобный интерфейс.
9 уровень предсказаний по сенсорам OS Android для постановки приложений на запуск.

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

Есть тенденция к реализации кода в FPGA.

Вот тут люди реализуют софт из библиотек Linux на FPGA

Так как мы относим Дракон к языкам проектирования. Примеры языков проектирования VHDL, Verilog-AMS. В котором есть возможность задания параллельных процессов и даже их размещения в пространстве памяти или, буквально, в плоскости интегральной схемы (ИС).



P.S. AtH наш общий знакомый

А, понял мысль.
Вы про генерацию напрямую в схемную топологию.. Это, конечно, интересно.

А, так это то, что как раз Закревский разрабатывал: viewtopic.php?p=77233#p77233.

Ну, это было и до того... ещё в 1980-е в Мин[пром]связи, когда делали интегрированную платформу для связистов на базе ДВК/Электроники, реализовали даже "обобщённые переходы" между вычислителями, включая условные... через специальные адаптеры, насколько помню популярную книжку об этой разработке... Был и язык с соответствующими операторами. Смысл - реконфигурируемая для распределения нагрузки система (там прежде всего в целях поддержки резервирования, но также и с предопределённым назначением вычислителей на задачи). Чё-то похожее сделали и в СЧПУ Электроника НЦ-31 (тоже на нашем клоне дековской архитектуры сделан)...