When personal computers were first introduced in the late 1970s and 1980s, there was initial enthusiasm for teaching all children how to program. Thousands of schools taught millions of students to write simple programs in Logo or Basic. Seymour Papert’s 1980 book Mindstorms presented Logo as a cornerstone for rethinking approaches to education and learning. Though some children and teachers were energized and transformed by these new possibilities, most schools soon shifted to other uses of computers. Since that time, computers have become pervasive in children’s lives, but few learn to program. Today, most people view computer programming as a narrow, technical activity, appropriate for only 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 diffcult to use, and many children simply couldn’t master the syntax of progra-mming;
Programming was often introduced with activities (such as generating lists of prime numbers and making simple line drawings) that were not connected to young people’s interests of experiences;
Programming was often introduced 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 foor” (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 low-foor/high ceiling /wide-walls hasn’t been easy.
In recent years, new attempts have sought to introduce programming to children and teens. Some use professional programming languages like Flash/ActionScript; others use new languages (such as Alice7 and Squeak Etoys5) developed specifcally for younger programmers. They have inspired and informed our work on Scratch. But we weren’t fully satisfed with the existing options . In particular, we felt it was important to make the foor even lower and the walls even wider while still supporting development of computational thinking. 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 robotics kits. 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 and stories.
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 foor 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) 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 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 rapid prototyping and iterative design. Before we launched Scratch in 2007, we continually field-tested prototypes in real-world settings, revising over and over based on feedback and suggestions from the field.
Scratch这个名字强调了拼贴这个想法，这个名字来自于hip-hop DJ, 他们用手把唱片拨来拨去，用一个有创意的方法把不同的音乐片段拼在一起。在Scratch里，这个创意是相同的 ，我们把图片、动画、照片、音乐和声音拼在一起。
Scratch的开发过程中一直采用迭代式增量模式， 我们选择Squeak作为实现语言，因为它非常适合快速原型设计和迭代设计。 在我们于2007年推出Scratch之前，我们不断在现实环境中对经过精心设计的原型进行测试，并根据来自全球的反馈意见和反馈进行反复修改。