Computational Thinking & Visual Programming

Two ways into the same idea

Before You Start

The Core Idea: Computational Thinking

Computational Thinking isn't about computers themselves, it's a way of analyzing any complex problem so it becomes solvable in precise, unambiguous steps. The real problem this method solves isn't "how do I write the code" but "how do I think before writing any code at all", the human brain doesn't handle one big, tangled problem confidently all at once, but it handles several small, well-defined problems easily. Four pillars keep resurfacing in roughly this order in every later project in this guide, and each genuinely builds on the one before it:

1Decomposition

Breaking a big problem (like "a maze game") into smaller pieces solvable independently (player movement, collision detection, score counting). The benefit isn't just organizational, each decomposed piece becomes independently testable: you can confirm player movement works correctly before adding collision logic on top of it, so if a bug appears later you know exactly which piece of logic it lives in, instead of searching through one tangled program with no obvious place to start.

2Pattern Recognition

Noticing that two differently-shaped problems solve with the same idea, e.g. "repeating movement" in a jumping game resembles "repeated counting" in a for loop. This pillar logically follows decomposition: once you've split the problem into small pieces, you ask "have I solved something that looks like this before?", collision checking between a cat and a mouse is the exact same logic as checking a ball hitting a goalkeeper in a football game; only the visible artwork differs, not the comparison between the two objects' coordinates. Spotting this similarity saves enormous time, because you reuse an already-tested solution instead of reinventing it from scratch every time.

3Abstraction

Ignoring unimportant details and focusing on what actually matters for solving the problem, you don't need to know how pixels are drawn to move a Scratch sprite. Abstraction is what lets your mind operate on only one level of detail at a time: when you move a character, you're thinking at the level of "position (x, y) changes," not "thousands of pixels get redrawn on screen sixty times a second", that detail is handled entirely behind the scenes by Scratch's own engine. Without this abstraction, you'd drown in implementation details that don't directly serve your problem, and you'd never actually make progress on the real logic.

4Algorithm Design

Writing a precise, ordered sequence of steps that reaches the solution, exactly what you do when stacking Scratch blocks on top of each other. This pillar is the final output of the previous three: after decomposing, recognizing patterns, and abstracting away noise, you now write a sequence that admits no double meaning, "move the cat roughly toward the mouse" isn't executable because "roughly" is ambiguous; but "if the mouse's x-position is greater than the cat's, move the cat one step right, otherwise move it one step left" is literally executable with zero extra judgment left for the computer to make on its own.

The important thing to notice is that these four pillars aren't a one-time checklist you run once and forget, they're a lens you reuse in every project ahead in this guide, from shell files in Part Three to binary search trees in Part Nine. Whenever you find yourself staring at a big problem with no idea where to start, the practical order is always the same: decompose first, then look for a pattern you've seen before, then ignore every detail that doesn't directly serve the solution, and finally phrase the steps precisely enough to admit only one interpretation.

Scratch's Core Blocks and Their Text Equivalent

Figure 1, Every visual Scratch block has an exact text equivalent, what you learn here isn't "lost" when moving to text, only its shape changes.

Worked Example: Decomposing "Cat Chases Mouse" Game

Let's apply the four computational-thinking pillars to one problem before any implementation:

Deep Dive: From Idea to Pseudocode and the Trace Table

This part taught you that solving a problem starts with thinking, not typing. Here we detail the bridge between idea and code: pseudocode, then tracing the execution by hand in a table, then the flowchart, and finally event-driven programming, the idea behind the Scratch projects.

1. Pseudocode is a language between humans and machines

Pseudocode is structured text that looks like programming but obeys no compiler. Its goal is to focus on the logic without worrying about semicolons or type names. But it is not free-form: it rests on only three patterns from which any algorithm can be built, sequence (step after step), selection (if a condition holds do this, otherwise that), and iteration (repeat while a condition is true). The stricter your wording (one variable name per meaning, a fixed indentation inside each block), the easier the move to C, because C itself is strict.

2. An original pseudocode example

Let us describe an algorithm that counts how many notes are needed to pay an amount using the fewest notes of two denominations (5 and 1). It is a teaching example different from the project exercises, written the way strict pseudocode is written:

SET amount TO 17
SET fives TO 0
WHILE amount >= 5 DO
    SET amount TO amount - 5
    SET fives TO fives + 1
END WHILE
SET ones TO amount
PRINT fives, ones

3. The trace table is your mental machine

The only reliable way to know what an algorithm does is to execute it by hand, line by line, recording each variable’s value after every step. This is what a tool such as Python Tutor does later in Part 5, but here you do it with a pen. Build a table with a column per variable and a row per iteration:

When the loop stops, amount equals 2 and the result is printed: three notes of 5 and two of 1. Notice that the table revealed something important: the loop guaranteed that amount decreases every iteration, so it must end. That question, does the loop terminate?, is the first thing to check in any algorithm.

4. The flowchart

A flowchart draws the algorithm so that someone who knows no language can follow it. The symbols are few: an oval for start and end, a rectangle for a step, a diamond for a decision with at least two exits, and arrows for flow. Any arrow that goes back means a loop.

Figure 2, The flowchart of the example: the arrow returning from the rectangle to the diamond is the loop.

5. Event-driven programming in Scratch

In C you will write a program that starts at main and runs in order. In Scratch the model is different: there is no single main sequence but many scripts waiting for events. An event may be the green flag, a key press, one object touching another, or a message. The broadcast and when I receive blocks form a communication channel: any object broadcasts a message name and every script subscribed to that name reacts. It is the same principle as user interfaces and web applications, where the sender does not know the receiver and only the event name must be agreed on.

Figure 3, One broadcast wakes several receivers at the same time.

6. The game loop

Games, from a simple number-guessing game to huge ones, rest on a loop that runs without stopping: read the input, update the state, then show the result. In a guess-the-number game the state becomes variables (the secret number, the number of attempts), the input becomes asking the user, and leaving the loop becomes the win or lose condition. Recognizing that every interactive program spins on this loop is what makes the move from Scratch to C smooth.

Figure 4, The generic game loop: input, update, display, then the decision to continue.

Try it yourself

Quick Review Flashcards

Check Your Understanding