Scratch: Programming for All

Mitchel Resnick, John Maloney, Andrés Monroy Hernández, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, Yasmin Kafai, Scratch: Programming for All, Communications of the ACM, vol. 52, no. 11, November 2009.

When Moshe Vardi, Editor-in-Chief of CACM, invited us to submit an article about
Scratch, he shared the story of how he learned about Scratch:

A couple of days ago, a colleague of mine (CS faculty) told me how she tried to
get her 10-year-old daughter interested in programming, and the only thing that
appealed to her daughter (hugely) was Scratch.

That’s what we were hoping for when we set out to develop Scratch six years ago. We
wanted to develop an approach to programming that would appeal to people who hadn’t
previously imagined themselves as programmers. We wanted to make it easy for
everyone, of all ages, backgrounds, and interests, to program their own interactive stories,
games, animations, and simulations – and to share their creations with one another.

Scratch is the cover story of the November 2009 issue of CACM. The goal of Scratch is to get kids programming so that they become more fluent in information technology, and develop "computational thinking" skills. Scratch is a graphical language based on a collection of “programming blocks” that children snap together like Lego blocks to create programs. The programs themselves appear to be imperative in nature (at least based on the samples in the CACM article). Programs can be made concurrent by creating multiple stacks of blocks, and the authors claim that their goal is to make concurrent execution as intuitive as parallel execution.

Scratch was previously mentioned on LtU here.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Congratulations to the Scratch team

This is great publicity for them.

The Logo-esque idea of communicating programming ideas using visual and spatial metaphors is great, particularly when combined with the "programs as Lego-like assemblies". Scratch is deliberately messy, combining both a turtle-like metaphor for its "sprites", and Cartesian descriptions of position using coordinates. There's an intuitive notion of unbuffered, message-passing concurrency that works well enough.

The code has lots of aural bells and graphical whistles that certainly gave the program some interest to my eldest when she was 4: she tolerated having the block programs being explained to her between making the sprites do silly things, although she wasn't interested in making anything of her own. I might see if she is more interested in that, a year on.

Coincidentally, yesterday I noticed in the bookstore...

Scratch Programming for Teens

Scratchâ„¢ Programming for Teens (some public library memberships give Safari access)

Related languages

I've always liked John Pane's "Hands" system. His thesis points out many other similar languages and environments such as ToonTalk, StageCast and Squeak:

Above all do no harm

It would be good to check on the effect that learning Scratch and its programming model has on a young person's subsequent ability to learn and use other languages and models. In my experience, starting with too narrow or limited a model can significantly harm later ability.

For example, in the initial computing course required for most incoming UCSD undergraduates in the late 1970s we observed that the students who had learned programming in High School, typically Basic, had much more trouble than students with no previous programming experience. They had trouble learning and using abstraction, especially black-box thinking.

Later I observed new graduate students with a procedural programming background struggling with declarative programming. Insert similar story. Dijkstra emphasized the harm that a poor choice of initial language (really, model) was likely to have in "How do we tell truths that might hurt?".

Ideally in one's first year of learning programming a student would learn and do significant work with at least two languages oriented towards significantly different computational models, e.g. a procedural language and a declarative language. They need not be terribly complex languages, but neither should be a toy language lacking good facilities for building abstractions.

How do you grade Scratch programs?

Visual environments like Maple and Mathematica are very easy to grade students on their understanding; I have the experience of 3 years being a teacher's assistant in college. Most of my students were Child Study majors with a concentration in mathematics; they were not mechanical/electrical/software engineers or aspiring to be computer scientists, actuaries, etc. Yet, it was really easy to grade, and also teach them why I gave them the grade and explain what their weaknesses are. In essence, these visual environments had sufficient code review mechanisms.

Systems like Alice, on the other hand, seem impossible to measure quality of.

How does MIT propose Scratch be graded?

[Edit: The point being, students want to know WHY they scored so low. How do you do that with Alice? I've never been able to figure it out, but is Scratch any better? You can't simply give everyone high scores, because that makes students think the class is a joke and they instantly react to grade inflation promises in a way that conditions them not to learn. Just speaking from experience observing how other TA's ran their labs.]

Measuring harm

If you agree with Dehnadi and Bornat (cf. LtU story, Testing first year programming students), then the magic key to programming is a mindset of interpreting computer code in a consistent and inflexible manner.

It seems to follow that the consequence of poor choice of initial language will not be to injure the students ability, though maybe there may be some injury to the language preferences in the child. Your anecdotal experience is, I think, open to rival interpretations.

I'd like Scratch to have some sort of abstraction facility, but the most important thing for me is the idea of being a fairly painless environment for exploring the idea of programmatically exerting some kind of rewarding control of a machine. Once the programs start to get bigger, then maybe it's best to peel back the covers and look at the Squeak underneath.

More anecdotal experience

Well, I started programming (in a very unsophisticated way) at the age of 3 or so in BASIC. Moving to Pascal was quite painful at first, part of me didn't want to do it, I think the first failed attempts came around the age of 9-ish, but by the age of 12, I had made the transition and I saw that Pascal was a much superior language, which was a valuable lesson. And my interest in BASIC waned as my abilities with Pascal grew. Interestingly, I never understood why GOSUB was a good idea until after I started to get comfortable with Pascal.

But within a year or two of completing my transition, there were a number of things I disliked about Pascal. The thing that annoyed me most was the restrictions on the return type of a function, and I couldn't find a way of writing a library to work with rational numbers and matrices that satisfied me. Object Pascal appeased me for a few more years, for what I later understood to be the wrong reasons.

And then came C++, which precipitated a crisis in which I found it deeply unsatisfying to work in any language I currently knew. The subsequent search for a better language eventually lead me to ML and Haskell. These languages instantly "clicked" in the sense that I knew I liked them a lot, but of course actually learning to use them was quite a challenge. It took a good year and a half before I became approximately competent, and another year before I was comfortable enough to no longer need imperative programming.

So I guess my point is that BASIC does not necessarily lead to "bad outcomes", but my story is probably rather unusual. The real question is one of statistics: what choices lead to better outcomes on the whole?

It seems to follow that the

It seems to follow that the consequence of poor choice of initial language will not be to injure the students ability, though maybe there may be some injury to the language preferences in the child. Your anecdotal experience is, I think, open to rival interpretations.

What rival interpretations? He is effectively saying that when students encounter an idea for the first time, they may struggle to learn it, especially if the idea is totally counter to the habits they've been encouraged to pursue.

Bertrand Meyer took this hypothesis to its fundamental limit, with good results in his classes. The end result is the book A Touch of Class.

Bertrand has been jetsetting ACM SIGCSE conferences the past few years with his approach. Yet it has received very little attention from rivals, from what I can see. e.g. DrScheme.

Learning environments are complex systems. A linear progression in one direction (pouring all emphasis into one technique for improving learning) will not yeild linear gains in improvement. The trick is to design things extraordinarily well. I can't find the paper at the moment, but Boustedt et al did a study that shows there are certain core concepts in calculus that once students truly show understanding of, their understanding and grasp of future material is irreversibly changed and made easier. I believe the example they gave was use of limits.

Also, Nicole Mcneil, a psychologist at Notre Dame, has done various studies on how children interpret symbols based on how the meaning of the symbol is first presented (eg. the problem context). Fascinating stuff that shows how much teachers can take for granted. What it revealed is that if you gave children problems like 3 + _ = 4, students would often answer 7, because they interpreted '=' as 'add up all the numbers' aka 'calculate the total'. I've seen similar problems in college calculus courses. For example, once a student learned u-substitution, it became a deathgrip, such that they found integration by parts difficult. This is very unfortunate. (Obviously, you do not need to teach integration techniques in that order.) This basically boils down to being good at manipulating symbols and forming abstractions.

Another possibility

I think the risk to students is that, having learnt a way to solve a problem in a particular way, they will be slow to see the advantages of learning another, but when provided adequate motivation to learn, they will learn all the better for it. The alternate seems to suppose that the mind is somehow polluted by conceiving of ugly code, and does not naturally rid itself of this toxicity. I'm guessing the failure to be convincing when presenting the problems of unstructured programming is more likely to be at fault.

If you want to teach the dangers of unstructured programming, I'd guess that a code maintenance problem would be a good start.


I think you are conflating bad habits with new ideas.

The idea that code can be made maintainable through analysis is a "new idea" in the ocntext of spaghetti programming. In the software industry, this "new idea" was not even discussed much until the '70s. And the idea of updating analysis -- refactoring -- was not discussed much until the late '90s.

In spaghetti programming, the "new idea" is being able to program a machine to do things like add numbers faster than humans, and know exactly how the machine does this. Structured does not matter.

It is possible for a "new idea" to be presented in such a way as to form a "bad habit", which is what you want to say: For 3 + _ = 4, the answer apparently is _ = 7, because the "new idea" of algebraic manipulation of an equation mixed with constants and variables was simply presented too naively.

Honestly, it is pretty hard to get statistics on how badly brains are damaged. Only one state in the US enforces standardized textbooks for K-12, and that is Texas. So it is very hard to map out how well students are doing and how well teachers are picking out the right materials e.g. how well they are managing a classroom budget. I tried to get these numbers, but it was impossible, and my requests from publishers were never replied to. -- they wouldn't even tell me what their demographics were.


Don't underestimate the flexibility of the brain :) We can always adapt if we choose to adapt. Not adapting is not as big a problem as well. For example, it seems to be a fashion in the "new music interfaces" groups to consider the piano-ish keyboards to be "very bad" interfaces to making notes and melodies. There are some great pianists nevertheless. Likewise, great software is independent of the greatness of the language in which it is written.


Along the same lines as scratch, I found Kodu ( to just the kind of "very simple programming" introduction I had been looking for. I've been frustrated with the simplicity of Kodu (no more than one conditional at a time, for example), but if anything "Scratch" seems overly-complicated when compared. Perhaps there's a middle-ground, but for now I think I'd tend towards the less-complicated end when introducing programming.

Hurray for Scratch

I'm really amazed by Scratch. I love the way they focus on fun, creativity, and community. I also love the way they are succeeding based in large part on a really polished implementation that must have taken a tremendous effort. Hurray for them and their success!

Comes with spots too

Scratch is quite

Scratch is quite interesting; my main reservation, playing with scratch so far, is that it doesn't provide an obvious way to express abstractions like subroutines or otherwise share code.


But you do get message passing and concurrency. What I miss is recursion.

Scratch and LOP

Scratch is something both my 8 years old son and I find interesting. For my son it is a way to program computer games without having to know how to program (or even without knowing English, as it is translated to practically any language there is). I find it interesting since I'm a language-oriented-programming (LOP) enthusiast, and like Scratch, most modern LOP platforms use textual/model languages. While Scratch is ad-hoc and does not allow creation of new languages (and not even abstractions in the existing language, as mentioned earlier), but on the other hand - it has very advanced user interaction features, such as drag-and-drop, and the use of shapes to denote "parts of speech". I wonder if these features can be useful in LOP environments, because if my 8-years-old son got the hang of Scratch within a day, a domain matter expert will get the hang on any Scratch-like DSL within about the same time.