Как стать автором
Обновить

Комментарии 9

Знакомы ли Вам проекты языка программирования Форт (Forth) на базисе языка Scratch
и если да, то что Вы об этом думаете?
Примеры таких проектов с 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 он сразу видит, что два скрипта выполняются одновременно.

В вашем примере в условии было «мышь нажата». Это не столько событие, сколько состояние внешнего мира.

Формально «мышь нажата» — логическое выражение. Либо правда, либо ложь. Неформально — вопрос: «Мышь нажата?».
LabView используется в промышленности, не говоря о графических языках для ПЛК.

Из развиваемых сообществами HiAsm и FlProg но это не совсем классическое понимание программирования.
Для контроллеров AVR кто то ещё использует Algorithm Builder Здесь форумная тема его применения — это уже улучшенный вариант ассемблера в блок-схемном исполнении.

P.S. В качестве блок-схемного отображения может быть использован «язык» Дракон :)

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

С «Драконом» всё непросто. Он, с одной стороны, очень строгий и поэтому уменьшает шанс на ошибку в алгоритме; а с другой стороны — он, как мне показалось, заточен под написание простых программ. Мне совершенно не понятно, как на нём сделать что-то реально сложное; как там работать со структурами и объектами; видимо, в этом направлении Дракон требует доработки. Я уж не говорю о попытке автоматического превращения схем Дракона в код…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории