Monthly Archives: September 2012

The tedium of Scratch can’t be good for kids

I recently had the pleasure of playing around with MIT’s Scratch as part of a team building exercise. In case you are not familiar with Scratch: it is a simple graphical and mouse-driven environment designed for beginners of whatever age. The aim is presumably to gently introduce novices to programming, without exposing them to oh-so-frightening programming language syntax. If you were a six-year old, you’d probably much rather look at Scratch than at Eclipse, and you’d certainly prefer looking at colored code blocks, as you can see below, instead of, say, snippets of Perl. The latter might not just be true for kids, though.

The Scratch user interface

The Scratch user interface

My team had the task of building a simple video game in Scratch, and it quickly dawned on me why this was a rather ingenious idea. It was certainly not because Scratch provides such a great interface, but because the limitations are so severe that you are forced to communicate with your team. Sharing code literally meant communicating by either turning your screen to the other guys or reading the “code blocks” to them.

Being forced to engage in teamwork due to the limitations of Scratch is a nifty idea. Yet, I later on thought about whether I would have wanted to be introduced to programming that way. Granted, it presents an ingenious way to familiarize people with computational thinking. Loops can easily be created by putting conditions together like Lego blocks. This may be fun for a while.

Quite possibly the most abused cat in history

Quite possibly the most abused cat in history

However, where Scratch falls short is in showing how powerful programming can be. For instance, when learning a high-level language, it doesn’t take long until a beginner is able to generate the Fibonacci sequence, or prime numbers, and if this is too pedestrian, then maybe looking at an output showing the first eight Mersenne primes will do the trick. The computer can uncover those within seconds, while it took mathematicians about 2,2000 years to achieve the same. If this isn’t fascinating, then I wouldn’t know what is.

Kids are probably more into graphics than number theory, though. But regarding 2D graphics I could see no advantage of Scratch either. In a high-level language, loops will help you to achieve a lot with very little code. If you wanted to fill the screen with 100 space invaders, then picking the position of the first one and placing the others relative to it is a fairly basic procedure. Unlike staring at Mersenne primes, this may actually be appealing to a slightly larger fraction of kids.

Scratch, on the other hand, feels a lot like work. Instead of letting the computer take care of repetitive steps, you will find yourself copying scripts and assigning it to different sprites. It reminded me of my frustrations with painting as a kid, because if I wanted to change something, I’d normally have to redraw the entire image. Likewise, even thought Scratch does offer a glimpse at the power of programming, you will find yourself doing a lot of manual work, and sometimes you have to literally rebuild something instead of easily changing it.

Just imagine you want to modify the script that governs the behavior of your sprites. If there are eight sprites, then there are eight copies of the script to modify. This means that you’ll first incorporate the changes, and then spend some time clicking and copying and dragging. Making a cat bump into a wall may be fun for a seven-year old, but having to do roughly four times the work to do the same with four cats certainly isn’t.

How would a smart kid react once he found out that in order to move four cats around, he’d have to put together a script each for every single sprite? Or if you told him that he can only place objects with the mouse, but if he wants their placement to be pixel-perfect, he’d have to assign values individually? Again, in a high-level language a loop would take care of this and you’d be done.

I have a hard time not seeing a bright kid getting bored to tears once they go beyond the very limited scope of, say, the basic tutorials. Letting a ball bounce around on the canvas just isn’t so much fun, and snapping code blocks together becomes tedious very quickly. To do anything remotely complicated, you end up clicking and dragging and snapping and duplicating so many steps that you’ll get frustrated as the work required increases exponentially. Scratch thus manages to successfully transfer a lot of the tedium and repetition when interacting with physical objects into the digital domain, but hardly any of the advantages.

Wasn’t the point of learning how to program to remove at least some of the tedium that comes with repetitive tasks? I remembered a statement one of my friends, a guy with a background in bioinformatics, once made. Paraphrased, it was something like:

I feel sorry for PhD students repeating their experiments over and over, but it makes me appreciate even more how great it is to utilize computers, especially when there is a task that has to be done repeatedly. It’s just a matter of executing the same script again.

You don’t even have to look at bioinformatics to come to this conclusion. Some people use scripts to take care of repetitive tasks in Excel, others spend literally hours a day copying and pasting data from one file or application to another. Probably the best thing about Scratch is that it prepares kids for that kind of toxic working culture. However, it’s probably a better idea to keep Scratch out of their sight and instead introduce them to Khan Academy’s computer science section. I haven’t had an in-depth look at it yet, but my first impression of their Processing.js powered platform was quite positive. It even makes me want to play around with it as an adult.