a small segment of the population.
What happened to the initial enthusiasm for introducing programming to
children? Why did Logo and other initiatives not live up to their early promise? There were several factors:
Early programming languages ˲
were too difficult to use, and many children simply couldn’t master the syntax
Programming was often intro- ˲
duced with activities (such as generating lists of prime numbers and making
simple line drawings) that were not
connected to young people’s interests
or experiences; and
Programming was often intro- ˲
duced in contexts where no one could
provide guidance when things went
wrong—or encourage deeper explorations when things went right.
Papert argued that programming
languages should have a “low floor”
(easy to get started) and a “high ceiling” (opportunities to create increasingly complex projects over time). In
addition, languages need “wide walls”
(supporting many different types of
projects so people with many different
interests and learning styles can all become engaged). Satisfying the triplet of
In recent years, new attempts have
sought to introduce programming to
children and teens.
7 Some use professional programming languages like
Flash/ActionScript; others use new
languages (such as Alice7 and Squeak
Etoys5) developed specifically for younger programmers. They have inspired
and informed our work on Scratch. But
we weren’t fully satisfied with the existing options. In particular, we felt it was
important to make the floor even lower
and the walls even wider while still supporting development of computational
To achieve these goals, we established three core design principles for
Scratch: Make it more tinkerable, more
meaningful, and more social than
other programming environments. In
the following sections, we discuss how
each of these principles guided our design of Scratch.
Our Lifelong Kindergarten research
group at the MIT Media Lab (http://
llk.media.mit.edu) has worked closely
with the Lego Company (http://www.
lego.com/) for many years, helping
develop Lego Mindstorms and other
17 We have always been
intrigued and inspired by the way children play and build with Lego bricks.
Given a box full of them, they immediately start tinkering, snapping together
a few bricks, and the emerging structure then gives them new ideas. As they
play and build, plans and goals evolve
organically, along with the structures
We wanted the process of programming in Scratch to have a similar feel.
The Scratch grammar is based on a
collection of graphical “programming
blocks” children snap together to create programs (see Figure 2). As with
Lego bricks, connectors on the blocks
suggest how they should be put together. Children can start by simply tinkering with the bricks, snapping them
together in different sequences and
combinations to see what happens.
There is none of the obscure syntax or
punctuation of traditional programming languages. The floor is low and
the experience playful.
Scratch blocks are shaped to fit together only in ways that make syntactic
sense. Control structures (like forever and repeat) are C-shaped to
suggest that blocks should be placed
inside them. Blocks that output values
are shaped according to the types of
values they return: ovals for numbers
and hexagons for Booleans. Conditional blocks (like if and repeat-until)
figure 3. scratch user interface.
have hexagon-shaped voids, indicating
a Boolean is required.
The name “Scratch” itself highlights the idea of tinkering, as it comes
from the scratching technique used by
hip-hop disc jockeys, who tinker with
music by spinning vinyl records back
and forth with their hands, mixing music clips together in creative ways. In
Scratch programming, the activity is
similar, mixing graphics, animations,
photos, music, and sound.
Scratch is designed to be highly interactive. Just click on a stack of blocks
and it starts to execute its code immediately. You can even make changes to a
stack as it is running, so it is easy to experiment with new ideas incrementally
and iteratively. Want to create parallel
threads? Simply create multiple stacks
of blocks. Our goal is to make parallel
execution as intuitive as sequential execution.
The scripting area in the Scratch
interface is intended to be used like a
physical desktop (see Figure 3). You
can even leave extra blocks or stacks
lying around in case you need them
later. The implied message is that it’s
OK to be a little messy and experimental. Most programming languages (and
computer science courses) privilege
top-down planning over bottom-up tinkering. With Scratch, we want tinkerers
to feel just as comfortable as planners.
The emphasis on iterative, incremental design is aligned with our own
development style in creating Scratch.
We selected Squeak as an implementation language since it is well-suited for