Scratch 3 глазами программиста

Как-то на одном из форумов проскочила фраза касательно написания руководства по Scratch 3 с точки зрения «взрослого» программиста. Не берусь реализовать столь амбициозную задачу, но поделюсь своим впечатлением и некоторыми находками.

Scrtach – это надолго или попробовал и забыл?

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

Сразу уточню. Речь шла не о текстовом программировании, а об использовании текста в блоках, например, для выбора объектов, методов, свойств и действий, что позволило бы устранить целый ряд ограничений. Но этого ни в одной блочной среде нет. Есть платформы, где есть блоки, позволяющие что-то из перечисленного выше задавать строкой, но не более того. В результате везде видна одна и та же картина, которую можно обозначить так: Упрощаем усложняя Парадокс какой-то. Scrtach специально делали таким, чтобы упростить процесс программирования для детей.

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

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

Теоретически, можно создать свою библиотеку блоков для работы со строками, списками, CSV, JSON и т.д., но будет ли это практичным в рамках ограниченных по времени занятий и для детей?

Предполагается, что на Scratch написано столько проектов, что можно просто взять готовую функциональность из этих проектов. Можно. Но сначала нужно найти такие проекты, затем разобраться с тем, какие блоки тз этих проектов нужно взять, поместить их в рюкзак и затем не запутаться, что из рюкзака достать в стой проект. Это в текстовом программировании достаточно задать вопрос, зайти на форум, скопировать отмеченный качеством код и вставить в свой проект. С блоками всё намного сложнее.

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

Если говорить в целом, то Scratch 3 мне чем-то напомнил QBasic. Возможно тем, что нет ощущения полнофункциональной среды разработки. Да, она позволяет познакомить детей со многими аспектами логики и программирования, но не позволяет реализовать бесшовный переход к текстовому программированию. После Scratch нужно ещё что-то. Roblox? Возможно. Но адаптироваться придётся. Scratch 3 достаточно сильно отличается от того, с чем придётся столкнуться на практике дальше.

• Взаимодействие между объектами — сценой и спрайтами — здесь происходит при помощи сообщений, а не ссылок на объекты.
• Нет понятия функций.
• То, что создаётся при помощи пользовательских блоков даже процедурой сложно назвать. Внешне они не выглядят контейнером, как это сделано в других блочных средах. Это, скорее, подпрограммы.
• Нет возможности использовать символ перевода строки в блоках
• Отсутствие ссылок также делает невозможным создавать глобальные пользовательские блоки. Дополнительные блоки являются локальными для объектов и нет возможности их вызвать напрямую из других объектов. Только посредством сообщений.
• Объекты, свойства, операции и т.п. в блоках можно только выбрать из выпадающих списков, но не вести в виде текста. Можно выбрать из списка спрайт «Кот» для клонирования или выбрать блок «Сказать». Но нет блока из трех полей, в котором можно было бы написать Имя спрайта, Название действия, Значение.
• Блоки нельзя сворачивать для освобождения занимаемого ими места
• Блоки нельзя преобразовывать к виду с внешним присоединением блоков, что позволяет длинные блоки, с которыми неудобно работать, делать короче за счёт увеличения их высоты

Кругом говорится о том, что нужно стремиться делать код проще и понятнее, не дублировать его, а смотришь на блоки и видишь, что это невозможно реализовать по определению!

Разработчик могут сказать, реализация всего этого усложнит систему для понимания детей. Это не так. Проблема не в том, что дети в начальной школе не способны понять переменные, ссылки и т.п., а в том, что многие понятия из программирования и информатики объясняется на пальцах, по картинкам и в экране компьютера, когда как есть возможность показать их в реальном мире и дать пощупать.

Если не хочется усложнять базовые блоки, то многофункциональные блоки можно поместить в расширение. Изучили базовые блоки? Теперь посмотрим, как можно оптимизировать их при помощи расширенных. Логичен такой подход? Да, но он доступен только в неофициальных модах Scratch 3, которые позволяют писать свои расширения.

Сказанное выше серьезно ограничивает функциональность рассматриваемой платформы, по причине чего создаются моды в виде Pictoblox с возможностью программирования на Python, Sheeptester — с возможностью создания расширений с собственными блоками, трансляторы блоков в код разных языков программирования, для Android и др. Это говорит о том, что «взрослые» программисты хотели бы увидеть на базе Scrtach более удобную и функциональную среду для разработки приложений для разных операционных систем, что позволило бы им показать детям больше возможностей в рамках одной среды разработки.

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

В этом плане Scratch 3 мне напоминает робототехнические конструкторы Лего. Функциональность не сказать, что впечатляющая за свою цену, зато есть некоторый стандарт, на основе которого можно проводить массовое обучение и соревнования.

В ходе общения с разработчиками блочных сред я понял то, что у них достаточно консервативный взгляд на блоки. И это удивляет. Разработчики блоков сами являются программистами, и, казалось бы, заинтересованы в том, чтобы использование блоков было более эффективным. Но на практике выходит так, что можно сколько угодно давать им предложения, а подавляющее большинство из них не будет реализовано и через многие годы. Что же делать? Не зацикливаться на блоках. Изначально Scrtach 3 позиционируется для детей 8 — 16 лет. На мой взгляд это слишком большой интервал. 12-13 лет? Возможно. Хотя кто-то начал гораздо раньше и к этому возрасту заинтересовался уже чем-то другим.

Обмен сообщениями вместо ссылок

Данная концепция имеет право на существование, но не кажется ли вам, что боязнь ссылок крайне преувеличена, а попытка огородить детей от этого понятия значительно уменьшает функциональность и весьма существенно усложняет проекты?

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

Именование переменных

В Scratch 3 нет ни сворачивания блоков (collapse), ни преобразования блоков в вид с внешним подключением блоков (external inputs) . По этой причине желательно делать блоки как можно короче в длину, на что влияет длина строк.

Для уменьшения размеров блоков имеет смысл использовать англоязычные слова (если пользователи им владеют), понятные сокращения и символы Юникода, например:

• Username вместо Имя пользователя
• Ср вместо символ № вместо номер 👚 вместо Костюм
• 🚀 вместо ракета Col вместо Колонка
• №👬 вместо Номер клона
• ↔ вместо Ширина
• ↕ вместо Высота
• 👞 вместо Длина шага
• ∠ вместо Угол поворота
• 👁 вместо Видимость
• Ц — вместо Цвет
• Р — вместо Размер

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

Можно в комментарии сделать справочник по используемым в блоках символов.

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

Желательно, чтобы постоянные значения — числа, строки, символы, передавались блокам через переменные (кроме значения для счетчиков цикла и т.п.), а не в виде литералов (постоянных значений). Переменные легко переименовать и присвоить им новое значение. А при изменении литерала придётся вспоминать, в каких блоках оно используется и изменять его вручную. Недостатком переменных является то, что очень быстро увеличивается их количество. При этом блоки локальных переменных ничем не отличаются визуально от глобальных.

Для исключения путаницы имена локальных переменных можно дополнять префиксом, например, так: _size. Тогда будет проще отличить глобальную переменную размер от локальной _size.

Список переменных

Для уменьшения количества блоков глобальных и локальных переменных можно использовать список переменных, в котором элементы с нечетными индексами являются именами переменных, а с четными — их значения:

Координата X
100
Координата Y
200
Шаг
50
Размер
40

На базе такого списка можно реализовать ассоциативный массив, словарь, список свойств клонов, например, так:

Кот1
X
100
Кот1
Y
200
Кот2
Ц
180
Бабочка1
Р
80
Y
0

Здесь Ц — цвет, Р — размер, но можно и английскими буквами кодировать.

Элементы списка сгруппированы по 3 и можно сделать цикл для быстрого изменения свойств многих объектов. Обычно для каждого вида элементов используются разные списки — списки переменных, списки клонов, списки разделителей полей, сопоставления букв и чисел и т.д. Из-за невозможности в Scrtach 3 выбирать список путём ввода в поле ввода его имени, имеет смысл подумать о том, чтобы в несложном проекте был один общий список.

Блоки для работы со списками длинные и может получится так, что уже три блока выйдут за границы области редактирования. У меня так получилось при попытке на экране сцены заменить глобальные переменные переменными из списка. Пришлось пойти на хитрость. Чтобы избавиться от глобальных переменных нужно создавать списки в спрайте, что позволит использовать локальные переменные вместо длинных и сложных операций с переменными из списка.

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

Блоки списков подойдут и для работы с данными в CSV формате. Тогда можно будет данные составить так:

Кот1,X,100,Y,200;
Кот2,Ц,180;
Бабочка1,Р,80,Y,0;

, где «,» - разделитель полей, а «;» - разделитель строк

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

• Объединить список1 и список2 - создаст строку со всеми элементами из списков 1 и 2
• Список1 Содержит Список2 - вернёт true, если в строке Список1 есть строка из Списка2. Учтите, что элементы списка при преобразовании в строку будут объеденены через пробел

Комментарии к блокам

Обычно в комментариях пишут какие-то пояснения к блокам. Но комментарии являются отличным местом для хранения данных и программного кода. В официальном Scratch 3 нет возможности использовать текстовой код, но в моде и на других платформах есть такая возможность. Поля ввода в блоках являются однострочными и работать с длинной строкой очень неудобно. Поля комментария многострочные и можно использовать их для хранения данных в удобном отформатированном виде. А затем копировать их в поля ввода и далее помещать в список.

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

Переменная: Значение
Имя спрайта: X,Y,Шаг,Размер

Координата X,
1,
100,
Кот 1,
4,
100,
200,
50,
40,

После этого мы можем скопировать всё от слова Координата X и ниже в текстовое поле и вставить это в список.

После вставки комментария в однострочное поле ввода блока символы перевода строки преобразуются в пробелы и при использовании имен, содержащих пробелы, не получится правильно разбить данные на элементы списка. Поэтому введен символ разделителя — запятая. Данные в списки можно вводить вручную, импортировать или вставлять из комментария. В последнем случае алгоритм будет таким:

1. Создать необходимую структуру данных в комментарии
2. Скопировать и вставить эту структуру в поле ввода блока.
3. Далее нужно создать цикл, в котором будет происходить посимвольное чтение строки из поля блока в переменную, накапливающую по символам строку. Если текущий символ равен запятой, то нужно добавить накопленную строку в список и очистить её.

Комментарии можно использовать для создания игрового поля. Предположим, у нас используется не более 10 блоков поверхности игрового поля. Тогда для его кодирования можно использовать цифры. Такое поле, например, лабиринт, можно задать в текстовом виде так:

01110
01011
01110
00010
00000

После этого копируем данные в блок. Строки можно разбить по пробелам, а дальше номер символа связываем с номером костюма клона, а координаты клона — с порядковым номером символа в строке данных.

Работа с клонами и их идентификация

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

В индексной системе ID клонов совпадают с индексами списка. Для этого перед созданием клона нужно получить индекс последнего элемента списка + 1. Если в списке 5 клонов, то следующий клон будет иметь идентификатор 6.

В именованной системе id клона задаётся в виде имени, а в смешанной Имя + индекс. Предположим, нам нужно создать 100 котов. Устанавливаем Индекс = 1. Берём блок цикла по 100 и в нём задаём глобальную переменную Имя при помощи блока объединения Кот с Индексом, затем создаём клон в котором происходит его присвоение локальной переменной _Имя = Имя. После увеличиваем индекс на единицу. Получатся имена Кот1, Кот2, Кот3 и т.д. Чтобы было понятно, где какой кот находится на сцене, то можно в блок «Когда я начинаю как клон» добавить блок «Сказать» ID.

Для изменения значения выбранного свойства у нужного клона можно использовать список из трёх полей: ID объекта, Имя свойства и Значение свойства.

1. На сцене происходит заполнение этого списка и затем отправляется сообщение.
2. В спрайте сообщение принимается и затем нужные поля просто выбираются из этого глобального списка.

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

Отладка в Scratch 3

наиболее функциональной частью является раздел блоков для работы со списками. По этой причине имеет смысл как можно больше использовать именно их.

Списки позволяют увидеть на сцене сразу несколько значений, что намного удобнее

постоянного включения и выключения отображения большого числа переменных.

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

Сцена или сценический спрайт?

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

Преимущество Scrtach 3 состоит в возможности взаимодействия нескольких пользователей посредством облачных переменных. Это можно использовать для вовлечения детей в общий процесс, где они могут поделиться своими успехами с другими, показать свою часть проекта, рассказать то, в чем они разобрались и т.д.

В рамках такой кооперативной работы можно что-то строить, совместно решать задачи, обмениваться сообщениями и др.

Обучение часто происходит так, что «каждый сам за себя». Но это работает, когда есть интерес и навык самостоятельной работы. А когда этого нет, то произойдёт быстрая потеря интереса. Но обратите внимание на то, как дети взаимодействуют друг с другом в процессе игры. Нужно ли их постоянно чему-то учить или достаточно в каких-то случаях организовать и поддерживать процесс?

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