Comments 9
и если да, то что Вы об этом думаете?
Примеры таких проектов с Github:
ikforth is an idiomatic Forth implementation written from scratch.
MOBLuSE_FORTH — a Forth (programming language) in Scratch 2 for Scratch.MIT.Edu
Классно наверное на скретче с нуля программирование давать.
Взрослым он уже не серьезный, приходится на какой-нибудь джаве текст в консоль разными способами писать. Задания в итоге выглядят слегка оторванными от реальности.
Вот если бы было что-нибудь вроде скретча, но например с башенным краном или моделью станка вместо кота, было бы намного проще объяснять те же циклы.
Хотя в Scratch как такового объектно-ориентированного программирования нет, спрайты можно считать объектами.
Думаю тут лучше подойдёт термин "формальный исполнитель" вместо "объект".
Объекты из ООП это все таки уже про абстрактные типы данных: упаковка множества значений в одну переменную, скрытие состояния, операции над скрытым состоянием.
Формальный исполнитель имеет особенность по сравнению с объектами — он может "если касается края, оттолкнуться". То есть он может получать информацию о внешнем мире. В ООП обычно наоборот — объект знает только о себе, а мир — о себе. При этом объекту давать знания о мире нельзя — нарушит SRP. Придется заводить менеджер передвижения и отталкивания.
Причем оказывается сложнее организовать последовательное выполнение.
Эта мысль как то не развернута. Сложнее по сравнению с чем? В чем именно сложность?
Многопоточность сложная не сама по себе, а когда нужно организовать синхронизацию состояния. Тогда начинаются всякие мьютексы, семафоры и т.п.
Судя по вашей статье, вы синхронизацию организовываете до объяснения условий и переменных. В скретче какие то особые механизмы предусмотрены?
Условием могут выступать те или иные события.
На мой взгляд тут путаница в терминах. События это ведь что то такое, с чего начинается выполнение подпрограммы. В вашем примере в условии было "мышь нажата". Это не столько событие, сколько состояние внешнего мира.
Вот если бы было что-нибудь вроде скретча, но например с башенным краном или моделью станка вместо кота, было бы намного проще объяснять те же циклы.
App Inventor ( ru.wikipedia.org/wiki/App_Inventor ) хотя тоже позиционируется как продукт для подростков, но насколько знаю там некоторые взрослые реальные приложения под андроид запиливают.
Многопоточность сложная не сама по себе, а когда нужно организовать синхронизацию состояния. Тогда начинаются всякие мьютексы, семафоры и т.п.
Судя по вашей статье, вы синхронизацию организовываете до объяснения условий и переменных. В скретче какие то особые механизмы предусмотрены?
Согласна, что просто понятие многопоточности не сложное. В скретч она как бы по умолчанию, как данность. Возможно по внутренней реализации к настоящей многопоточности отношения не имеет. Но обратить на нее внимание ученика следует, так как в реальном программировании — это важная тема. А в Scratch он сразу видит, что два скрипта выполняются одновременно.
В вашем примере в условии было «мышь нажата». Это не столько событие, сколько состояние внешнего мира.
Формально «мышь нажата» — логическое выражение. Либо правда, либо ложь. Неформально — вопрос: «Мышь нажата?».
Не взлетело.
Из развиваемых сообществами HiAsm и FlProg но это не совсем классическое понимание программирования.
Для контроллеров AVR кто то ещё использует Algorithm Builder Здесь форумная тема его применения — это уже улучшенный вариант ассемблера в блок-схемном исполнении.
P.S. В качестве блок-схемного отображения может быть использован «язык» Дракон :)
Так смысл не в том, чтобы блоки расставлять мышкой, а в API для формального исполнителя.
Хочется с анимацией этого исполнителя и простым синтаксисом, но реальность иная. В ней студенты хотят промышленный язык и не готовы платить за курсы по "специальному" языку для изучения программирования.
Есть ведь еще всякие игры в кодинг, но это опять же "не серьезно" и платным курсам методически не подходит.
Концепции программирования в Scratch