Scratch: The Program Becomes Something to Share

A beginner’s first programming problem can arrive before the program does anything interesting. A misplaced punctuation mark stops execution, and the message explaining it may assume knowledge the beginner hasn’t acquired. The machine has an exacting complaint about a language the person is still trying to enter.

Scratch offered a different starting surface. In May 2007, MIT described software that let children assemble graphical blocks to create interactive stories, games and animations, then share them online. The downloadable editor ran on PCs and Macs.¹

The milestone combined a programming environment with a social destination for its output. A project could be made, tried, shown to somebody else and modified. The executable work, rather than only a finished video of it, became something people could exchange.

Mitchel Resnick headed the development team. MIT credited the Lifelong Kindergarten group, UCLA educational researchers and feedback from children and teenagers during development.¹ It was a designed learning environment informed by users, rather than simply a conventional programming language with larger buttons.

Instructions acquire visible shapes

The Scratch team’s 2008 paper describes movable sprites on a stage, with scripts and media belonging to project objects. Commands were assembled into stacks, and event blocks could start those stacks.²

A stack supplies an order the learner can inspect spatially. Put one operation below another, and the arrangement has a visible relationship to the resulting behavior. A loop supplies a place for instructions that should repeat.

Shape can reduce some kinds of invalid assembly. It doesn’t make all assembled programs meaningful. A syntactically acceptable script can move in the wrong direction, repeat too often or respond to an event the user never triggers.

That distinction is useful for learning. The beginner can spend more attention comparing intended behavior with observed behavior, while still encountering the need to reason precisely about instructions.

Our examples use textual outlines of invented block programs. They don’t reproduce an editor screen, exact block artwork or every historical menu label. Modern Python executes the underlying arithmetic, rather than running a 2007 Scratch interpreter.

A loop is a description of repeated change

Give an invented sprite a horizontal coordinate of zero. Each repetition adds ten to its x-coordinate. After six repetitions, the coordinate is sixty.

set x to 0
repeat 6 times:
    change x by 10

The formula is simple: final x equals initial x plus repetitions multiplied by change per repetition. Here it is 0 + 6 × 10 = 60.

Our check records every intermediate coordinate: 10, 20, 30, 40, 50 and 60. That list makes the process visible. The formula explains the total; the sequence explains how the total was reached.

Now place set x to 0 inside the loop before the change. Every repetition resets the coordinate and then adds ten. The final value is ten, and the intermediate list contains six tens.

The commands are almost the same, but their containment changes the program. A learner can diagnose the difference by asking which operation is repeated, rather than by assuming the movement block is broken.

Original CC0 diagram, 2026. Invented coordinate model and textual block outline; not a Scratch screenshot or measured animation.

This is an original worked example with a checked result. It doesn’t assume a particular frame rate, stage boundary or visible travel time. Those would require additional rules and a stated runtime.

The distinction between starting state and repeated state is substantial. It appears in animation, counters and many other programs. A small moving object makes it tangible without making it trivial.

Add a condition and the result changes again

Suppose the goal is to move until x is at least 55, still in ten-unit steps from zero. The sprite visits 10 through 60 and stops at 60. It doesn’t stop at 55 because none of the permitted steps lands there.

That introduces the relationship between a condition and the available changes. “Stop when x is at least 55” is different from “set x to 55.” The first asks the program to keep testing; the second directly supplies a value.

Change the step to seven. The model reaches 56 after eight steps. Again it satisfies the threshold without landing exactly on it.

Our arithmetic check verifies both sequences. It also makes clear that a condition can be satisfied by crossing a boundary. No claim about a real Scratch project’s collision geometry follows from this one-dimensional model.

If the condition were “x equals 55” while the step remained ten, the model would never reach it. A stopping condition has to be reachable under the program’s actions, or the repetition may continue indefinitely.

This is where visible programming still demands precise thinking. Blocks spare the learner some punctuation, but they don’t decide whether the chosen condition and movement can ever agree.

A message connects separate scripts

The 2008 team paper describes named broadcasts, including a variant that waits for triggered scripts to finish. One message can trigger several listeners.²

Invent a scene with three objects: a traveller, a caption and a lamp. The traveller reaches its destination and sends the message arrived. The caption listens for that message and displays a greeting. The lamp listens and changes its appearance.

The traveller doesn’t need to contain both other objects’ full instructions. It announces an event; the other scripts define their own reactions. The relationship is expressed through an agreed message name.

Our demonstration represents the listeners as two small functions. Dispatching arrived sets caption to Welcome and lamp to lit. Dispatching an unmatched name changes nothing in this model.

Original CC0 illustration, 2026. General event/listener model; no exact Scratch scheduler or script timing asserted.

The spelling is part of the relationship. If a listener expects arrival and the sender uses arrived, the intentions can look compatible to a person while the names fail to match.

This is an approachable form of coordination. Separate scripts can respond to the same event while remaining associated with different objects. It also creates a new debugging question: did the event occur, and was there a matching listener?

Our functions run sequentially for a deterministic check. That doesn’t establish the order in which historical Scratch scheduled multiple scripts. A message’s purpose and the runtime’s scheduling policy are different levels of explanation.

Feedback makes an experiment legible

A programming environment that shows behavior alongside editable instructions lets the learner make a small change and inspect its consequence. The movement example can be altered without first producing an elaborate application.

Try changing six repetitions to three. Predict thirty, then compare the result. Move initialization inside the loop and predict ten. The prediction is as useful as the observed behavior because it exposes the learner’s current model.

A surprising result is then a starting point for inquiry. Which instruction changed state? Which part repeated? Was the event sent? The questions refer to visible parts of a program that can be rearranged and tried again.

This doesn’t establish that every learner acquires the same skill from every project. The team paper reports research in a particular Computer Clubhouse setting. This article reads its mechanism description and introduction, rather than converting the study into a universal educational guarantee.

The distinction protects both the history and the learner. A thoughtfully designed environment creates opportunities. What people do with them depends on interests, help, time and the projects they choose.

Sharing changes the object of attention

MIT’s 2007 account described children modifying and extending one another’s projects online.¹ That makes the community part of the programming environment’s practical reach.

A finished animation shows an outcome. An inspectable project can also show how the outcome was constructed. Another person can change a repetition count, substitute an image or add a response and compare the result.

For our invented scene, a second author could make the lamp respond to departed as well as arrived. The new behavior builds on the original relationship while adding another event and listener.

That is more informative than merely receiving a compliment about the finished scene. The modification demonstrates a possible extension of the mechanism. It can lead to questions about how the original works.

Sharing has obligations too. A project may contain images, sounds and ideas from several people. Being technically able to copy a media file doesn’t settle its reuse rights or remove the need to credit contributors.

No children’s project or personal information was collected for this article. The scene is invented, and the diagrams contain no third-party media. The community mechanism is described without appropriating somebody’s shared work as an unrestricted illustration.

The 2007 environment isn’t today’s browser editor

The contemporary MIT account identifies a downloaded PC/Mac application. Later Scratch versions changed the editor, runtime and online experience. Present browser behavior and current extensions shouldn’t be assigned to the public emergence in 2007.

The 2008 paper also discusses earlier use during development. That doesn’t contradict a 2007 public milestone: a prototype used in a research setting and a broadly available product are different events.

This article doesn’t force an exact first-release day from conflicting later version histories. Its year is established by the contemporary May account. That source boundary is more useful than false precision.

Scratch’s consequential combination was visible computation, expressive media and exchangeable projects. A beginner could make something worth looking at while encountering loops, state and events that mattered to its behavior.

The loop still has to repeat the correct instructions. The message still has to match. That is programming, made approachable enough that the first interesting question can be what the traveller does next.

Sources

Footnotes

1. Stephanie Schorow, MIT News, Creating from Scratch, May 14, 2007. Contemporary availability, platforms, team and sharing description; full article body read. ↩ ↩² ↩³

2. John Maloney, Kylie Peppler, Yasmin B. Kafai, Mitchel Resnick and Natalie Rusk, Programming by Choice: Urban Youth Learning Programming with Scratch, SIGCSE 2008, pp. 367–368 selected introduction/system description. Primary team paper; study not presented as a universal learning guarantee. ↩ ↩²