
Many people are familiar with Scratch - a children's programming environment, in which learning usually comes down to creating creative projects on a “from simple to complex” basis. At the same time, the "classical approach" to learning programming (variables → branches → loops → functions → structures → objects → ...) in Scratch is difficult.
However, changing the sequence of studying the concepts (let's call them concepts) of structured, object-oriented and event-oriented programming, hiding them behind bright sprites and interactive animation, does not mean that the concepts should not be emphasized. Especially if the goal is not so much the development of creative abilities as learning to program. I tried to reflect this idea in my .
The first thing a beginner scratcher encounters are sprites. While there is no object-oriented programming per se in Scratch, sprites can be thought of as objects. At this stage, the student sees that the program can have many objects whose behavior is controlled by scripts external to them. Sprites receive commands or transmit information about their state on demand, that is, programming is reduced to managing objects.
The second thing that immediately falls on the head of a young programmer in Scratch is the concept of multithreading. Each sprite can have multiple scripts running at the same time. Multiple sprites can also run their programs at the same time as each other. Moreover, it turns out to be more difficult to organize sequential execution.


Already in the first lesson, we cannot avoid getting acquainted with cycles. Otherwise, the cat will not particularly run away. At this stage, acquaintance has to be left intuitive and superficial. We restrict it to "repeat always" and "repeat ... once" loops, which are easier to understand. The conditional loop is covered in the lesson dedicated to loops. This lesson assumes knowledge of Boolean expressions and variables.
Because Scratch is an event-driven environment, conditional statement blocks are more convenient to learn before variables. The condition may be certain events.

In my opinion, such a sequence is better, since for each lesson we introduce a minimum of concepts. And not abstract ones, but we immediately see their practical benefits.
If you first study variables, then their purpose and usefulness is difficult to demonstrate, since the conditional operator, data entry and random number generation have not been studied before.
In Scratch, apart from lists, the programmer is faced with three data types: numbers, strings, and booleans. In this case, the type is bound to the value, not the variable. There is no need to convert strings to numbers and vice versa. Strings are not enclosed in quotes.
A block that returns a boolean value and has its characteristic angular shape can be inserted into rounded fields. The converse is not true: where a boolean expression is expected, you cannot insert an ordinary variable.

Scratch is implemented in such a way that critical errors do not occur during execution. Apparently, therefore, if you try to use a string in an arithmetic operation, it is replaced by zero (see the first screen).
The programmer should be aware that the possibilities of programming languages are extended by libraries. While working in Scratch, the student can connect add-ons that lead to the appearance of new commands in the environment.

Functions in Scratch are implemented in the "Other blocks" section, where on the one hand you create your own block that can be inserted into other scripts. On the other hand, they must collect the functionality of this block, that is, what it will do.

There is no return value from the scratch function.
Thus, the study of programming concepts in an event-driven environment leaves its mark. In fact, we first study more complex and abstract concepts and, only delving into the process, we move on to the elements of structured programming. Plus or minus for the first acquaintance is a moot point.
Source: habr.com
