Я же правильно понимаю, что это просто поддержка запуска других языков из этой же IDE? Или там какое-то есть еще хитрое взаимодействие с КуМировской экосистемой?
Не только. Программа-максимум заключалась не только универсальной учебной IDE, но и в том, чтобы сделать доступными графические исполнители (Робот, Чертежник и др.) доступными из Pascal и Python. Плюс (для Python'а) - поддержка запуска скрытых тестов, которые можно создавать в учительском режиме.
Архитектурно Кумир 2.х - это набор модулей, реализующих определенные интерфейсы. И заменив два модуля (синтаксический анализатор и выполнитель) можно было получить IDE для другого языка программирования.
Для Pascal в качестве синтаксического анализатора использовался обычный fpc, запускаемый как дочерний процесс, а для того, чтобы вытаскивать таблицу символов (для подсветски синтаксиса и автодополнения), ему скармливался фейковый "ассемблер". До реализации исполнения дело не дошло, но предполагалось использовать обычный gdb.
А вот с Python интереснее, - интерпретатор был прикручен через PyObject API, интеграция выполнения был более тесной. Это позволяло вытворять разные фокусы, например, скрытно менять значения переменных во время тестирования ученических программ.
Спасибо за пост, я был приятно удивлён, что Кумир жив-здоров, а не ушёл в самый дальний ящик стола.
Оставлю пару комментариев глазами бывшего ведущего разраба.
Про тормоза компилятора, интегрированного в IDE. Концепция Кумира подразумевала, что это этот программный продукт - помощник школьного учителя, который за 40 минут должен обойти всех учеников в классе, которые допускают типовые глупые ошибки, и ответить на их вопросы.
В помощь учителю мы сделали распознавание различных типовых ошибок на уровне множества грамматик языка. В ранних бета-версиях Кумира учителя даже могли сами добавлять описания ошибок в грамматики (правда этот процесс был наукоёмким, и я знаю только одного учителя, который этой возможностью пользовался). Затем множество грамматик захардкодили, что заметно ускорило производительность, но осталась экспоненциальная алгоритмическая сложность алгоритма (экспериментально ограниченная сверху сообщением "Слишком много ошибок").
Такой способ прекрасно себя показал на небольших программах, но если у Вас программа на сотни строк, то всего лишь небольшое изменение в середине программы приводило к заметному лагу даже на топовом железе в конце нулевых.
LLVM. А вот тут совсем всё грустно, и его в современном КуМире быть просто не может. Прототип LLVM-backend действительно был сделан и показал прекрасные результаты на олимпиадных задачах, но API LLVM очень не стабильный даже сейчас, а 10 лет назад менялся каждую минорную версию. Я честно обвешал всё #ifdef'ами под разные версии от 3.4 до 3.7 в различных актуальных дистрибутивах Linux, но так вечно продолжаться не могло. Всё-таки нас в команде разработки было 2 человека (не на full-time при этом) и один тестер (тоже на подработке).
По этой причине направление LLVM было свёрнуто из-за нехватки ресурсов (как и другие направления, например поддержка языков Pascal и Python в модульной платформе IDE Кумир).
А сейчас, судя по знакомым до боли скриншотам, Вы пользуетесь той самой версией с обычным стековым выполнителем байткода.
Сейчас меня заминусуют, но напомню про Кумир, который очень далек от передовых концепций и паттернов :)
Язык программирования - это просто инструмент. Учить нужно алгоритмическому мышлению и навыкам решения задач.
Не только. Программа-максимум заключалась не только универсальной учебной IDE, но и в том, чтобы сделать доступными графические исполнители (Робот, Чертежник и др.) доступными из Pascal и Python. Плюс (для Python'а) - поддержка запуска скрытых тестов, которые можно создавать в учительском режиме.
Архитектурно Кумир 2.х - это набор модулей, реализующих определенные интерфейсы. И заменив два модуля (синтаксический анализатор и выполнитель) можно было получить IDE для другого языка программирования.
Для Pascal в качестве синтаксического анализатора использовался обычный fpc, запускаемый как дочерний процесс, а для того, чтобы вытаскивать таблицу символов (для подсветски синтаксиса и автодополнения), ему скармливался фейковый "ассемблер". До реализации исполнения дело не дошло, но предполагалось использовать обычный gdb.
А вот с Python интереснее, - интерпретатор был прикручен через PyObject API, интеграция выполнения был более тесной. Это позволяло вытворять разные фокусы, например, скрытно менять значения переменных во время тестирования ученических программ.
Уфф...
Спасибо за пост, я был приятно удивлён, что Кумир жив-здоров, а не ушёл в самый дальний ящик стола.
Оставлю пару комментариев глазами бывшего ведущего разраба.
Про тормоза компилятора, интегрированного в IDE.
Концепция Кумира подразумевала, что это этот программный продукт - помощник школьного учителя, который за 40 минут должен обойти всех учеников в классе, которые допускают типовые глупые ошибки, и ответить на их вопросы.
В помощь учителю мы сделали распознавание различных типовых ошибок на уровне множества грамматик языка. В ранних бета-версиях Кумира учителя даже могли сами добавлять описания ошибок в грамматики (правда этот процесс был наукоёмким, и я знаю только одного учителя, который этой возможностью пользовался). Затем множество грамматик захардкодили, что заметно ускорило производительность, но осталась экспоненциальная алгоритмическая сложность алгоритма (экспериментально ограниченная сверху сообщением "Слишком много ошибок").
Такой способ прекрасно себя показал на небольших программах, но если у Вас программа на сотни строк, то всего лишь небольшое изменение в середине программы приводило к заметному лагу даже на топовом железе в конце нулевых.
LLVM.
А вот тут совсем всё грустно, и его в современном КуМире быть просто не может. Прототип LLVM-backend действительно был сделан и показал прекрасные результаты на олимпиадных задачах, но API LLVM очень не стабильный даже сейчас, а 10 лет назад менялся каждую минорную версию. Я честно обвешал всё #ifdef'ами под разные версии от 3.4 до 3.7 в различных актуальных дистрибутивах Linux, но так вечно продолжаться не могло. Всё-таки нас в команде разработки было 2 человека (не на full-time при этом) и один тестер (тоже на подработке).
По этой причине направление LLVM было свёрнуто из-за нехватки ресурсов (как и другие направления, например поддержка языков Pascal и Python в модульной платформе IDE Кумир).
А сейчас, судя по знакомым до боли скриншотам, Вы пользуетесь той самой версией с обычным стековым выполнителем байткода.
Простите, а что вы будете делать, когда толпа студентов начнут пинговать вас в личку в ночь перед дедлайном?