As a university lecturer in a computer related subject I as invited last year to run a CPD workshop for computing teachers from local schools, introducing them to some technologies that they might use on STEM projects. I hope they learnt something from the sessions, but what I learnt from them was that they were very excited, but also apprehensive about the new computing curriculum.
There seemed to be a pretty good consensus that at KS2 the go-to tool was Scratch. Both teachers and pupils loved it and were keen to show off any number of fun projects they’d produced. They loved the immediate feedback, and being able to build programs from simple blocks.
However this relaxed confidence disappeared abruptly somewhere around KS3. At this point there was a vague notion that they should move on from Scratch to something more serious, but there was no clear plan as to what that might be. There were mumblings that Raspberry Pi was supposed to help, but no real idea what it was good for. Python seemed to emerge as a grudging consensus, but not with any enthusiasm – rather that people had heard that other people were using it and they probably should be.
Both staff and children appear to be getting lost in the transition from Scratch to “real” programming. To address this we need to consider why and when we transition from Scratch, and subsequently why children who were happy and enthusiastic working with Scratch fail to successfully transition to (for example) Python.
Why Stop Using Scratch?
The first question “Why stop using Scratch?” is actually quite tricky. Why isn’t Scratch suitable for KS3, KS4 and beyond? The obvious answers: “Because its just for beginners”, or “its not powerful enough”, are quite simply wrong. While its true that Scratch has limitations, most seriously with respect to data structures, children in KS3 are almost certainly not scratching the surface (sorry!) of what it can do. It’s possible to implement many degree level algorithms in Scratch. In fact Scratch’s model of parallelism is far in advance of most other common programming languages.
It may be that Scratch’s worst enemy is it’s logo – the same cat that made programming friendly in KS2 looks childish to the cynical minds of KS3. Scratch simply looks like a KS2 program. It would be interesting to compare how older children would approach a version of Scratch with more age-appropriate art work.
However artwork alone isn’t enough to keep Scratch viable for more experienced users, regardless of age. The real reason to move on from Scratch is that graphical programming is tedious. Like a menu in a restaurant it provides helpful suggestions as to what you might choose, but if you already know what you’d like, then looking for it in the list of available meals is tedious. New Scratch users can browse the tools palettes until they see something they think might help, but experienced programmers become frustrated looking for the block they’ve already decided they need.
Why Not Python?
At a certain point programmers become sufficiently experienced that they’re ready to write code rather than choose it. So why might they fail to transition to Python? It would be easy to pick on Python here, and note that it has a number of problems. It also doesn’t help that Python has attracts the type of programmers who love to show off all its quirks and features. All the strange features you can do that Python advocates love are best kept away from children. (If you Google “python hello world” the current top result is a post asking why the exact code recommended in the second search result doesn’t work.)
However the real problem isn’t Python’s fault. The real issue is that any mainstream programming language would be big leap. We’re asking novice programmers to go from “choosing from the menu” to “invent your own meal”. While they should be ready to do that (if not stick with Scratch), they’ve been training to “pick their own Pizza toppings”, and suddenly they find themselves in an Indian Restaurant. Not only are they asked to create a meal by themselves, but the whole meal structure is completely different to what they’ve seen before. Scratch programmers ready to move on from choosing to writing are ready to write Scratch. It’s a big leap to go from choosing in Scratch to writing in Python.
Writing Scratch
If Scratch is more powerful than we give it credit for, and the only obstacle to writing more complex programs in Scratch is the graphical programming paradigm, then the obvious next question was “what is it like to write Scratch?”. What would Scratch look like if you took the blocks and GUI away, and just kept the bare, text based language? The short answer is surprisingly powerful and nice to work with!
I implemented a compiler which would handle text files containing almost exactly the same words found on the Scratch blocks. The new programming language “Sniff” implements all of the blocks from Scratch 1.4, with the exception of those relating to sprites, as these of course don’t exist without the GUI. The only significant change is that variables are now declared as being either numbers or strings (or lists of number/string) as this allows the code to run efficiently and effectively on low powered machines.
Programs like the above are essentially identical in Scratch and Sniff, which means pupils bring their Scratch experience with them, and can immediately start creating in Sniff. In fact the transition can happen gradually, and at the students own pace. Long before Sniff is formally introduced teachers or children are likely write something similar to Sniff on the board, without suggesting its anything other than Scratch. It’s perfectly reasonable to support both languages in parallel: either moving stronger children to Sniff, while others retain the support of Scratch, or even allowing children to build code fragments in Scratch before typing them into Sniff.
Being Engaging in a Screen Based World
When I got my first computer the first program I wrote printed my name on the family TV set. Its impossible to overstate how big a thing that was. Televisions were the only screens we had, and TV was something that was sent to us by “the powers that be”. To have your name on television was totally subversive, and was in a very real way the first steps to the screen based environment we have today. While broadcast television is still important, developments from those first home computers (and first home computer users) have democratised our screens to the point they’re ubiquitous. Unfortunately this also means the appearance of a screen is no longer exciting in the way it was when home computers were new.
Sniff can be run on a desktop computer, but it most of the work is targeted at Raspberry Pi and Arduino. To flash an LED on an Arduino the Sniff code is:
make LED digital output 13
when start
.forever
..set LED to on
..wait 1 secs
..set LED to off
..wait 1 secs
which takes us effortlessly from the GUI based Scratch into physical computing. Being able to engage with the real world beyond the screen creates real opportunities to integrate computing into the wider curriculum, controlling robots, controlling stage lighting, displaying a heart beat logging weather, and measuring the speed of toy cars have all been implemented in Sniff with only a few lines of code, and provide a jumping off point to explore other issues. Writing code to “actually do things” rather than just display things on screen is perhaps the most important tool for promoting computing engagement.
Getting Involved
Sniff is free to download, and currently runs on Mac, Linux, and Raspberry Pi. Compiled programs can be run on the host platform, or on an Arduino board. While Arduino is ideal for physical computing, you can also use the Pi’s GPIO ports. Writing code to handle Pi boards such as the PiBrella, and 7Seg is often easier in Sniff than using the provided Python library.
I’m in the early stages of taking the system out into schools, so if you’d like to get involved, download an install the code from www.sniff.org.uk. There’s demo code there, including a bunch of physics experiments just waiting to be turned into lesson plans.
ABOUT THE AUTHOR
Ian Stephenson is a lecturer at the National Centre for Computer Graphics at Bournemouth University where he teaches computing within an art based framework. Through the University’s Centre for Excellence in Media Practice, and STEM outreach programs he is also lead developer on the Sniff, post-Scratch programming language.
