You can do a lot of amazing, creative and cool stuff with a Raspberry Pi. But for our purposes here, we’re going to discuss how you can use it in a middle school computer science context. And while that’s not strictly limited to code, that’s our emphasis.
So for beginners, RP comes with two standalone versions of Scratch: 1.4 and 2.0. What, no web-based Scratch with all the social and sharing features? Afraid not, but what we can do on the RP is pretty awesome. We can code using the GPIO pins using Scratch, which opens up a whole new world of physical computing, electronics, and digital making. Don’t get me wrong, I love online Scratch and its community. But RP Scratch allows your students to go beyond code-in-a-window and get it to interface with lights, buzzers, cameras, and anything else you can connect to your GPIO pins. Because it’s still block-based Scratch, it’s an excellent jumping off point to learning how to code physical things, like LED’s. And there are many resources available that allow you to create the same program in Python. So then your students can make that jump to text-based coding with the same setup. For instance, they can attach an LED and a resistor to a breadboard, get that LED blinking with Scratch, then when they’re ready, they can accomplish the same feat in Python. Doing the same thing in two languages increases the understanding, especially when you do them side by side. And that eases that sometimes tricky on-ramp to text-based coding.
Scratch 2.0 looks and acts a lot more like online Scratch. So why would you use 1.4? At this point, 2.0 is still a bit slow in executing code, and we all know how patient most middle schoolers are! For that reason, I’m still using 1.4. But I’m ready to switch up when a future version is zippier!
Once your students are comfortable with Scratch and block-based coding and ready to make the leap to text-based code, RP has Python 2 and 3 built in. Both run IDLE as the IDE, and while it’s pretty bare bones, sometimes that’s a good thing. Especially when students are learning not only a whole new language, but a whole new paradigm. Thonny, which is a great Python editor with many more bells and whistles, is also included in the install, but I’ve found it’s overkill for beginning Python students and creates unnecessary complexity.
I would highly recommend using Scratch, a breadboard, an LED, and a resistor to do your first “blinky lights”, which is the physical computing version of Hello World. It takes some patience and a serious attention to detail. If you’re also looking for a good way to introduce some electronics concepts (which are useful in understanding computers), such as voltage, resistance, ground, positive and negative… this is a great entry way. Once you get everything hooked up correctly, then you write the code in Scratch to use a particular pin as your output/input pin, and use those Scratch concepts that are so familiar: forever loops, waits, and broadcasts. And voila! Lights are blinking! From there, add something else — perhaps a different color LED or two, make some traffic lights… add a buzzer that sounds when your character reaches a certain score. Suddenly you’ve got code that works in two “dimensions” — on-screen and in the real world. Now it’s starting to get exciting!
Another plus with Python and the RP is the abundance of support material available. The RP website alone has hundreds of sample projects, code samples, and ideas, as well as Python tutorials. And there is a whole awesome Python code library for controlling the GPIO pins (gpiozero), which has built-in functions in the API that support many of the most popular hardware add-ons (called HATs in RP lingo — Hardware Attached to Top). I’ve found that segueing over from Scratch to Python using gpiozero code is a relatively painless transition.
Of course, no matter what you choose as your first foray into text-based coding, there is still a hurdle to overcome. Here are some strategies that I’ve found helpful for students.
The first one is reminding them that 1. computers are dumb and 2. you have to speak to them ONLY in the way they understand. Error messages are Python’s way of training you how it wants you to speak to it. I find that putting it this way, while it doesn’t eliminate frustration, does help the students to understand that it’s the computer that’s dumb, not them. A small shift in thinking, but powerful.
The second thing I do is to demo “live coding”. I pick a sample easy intro bit and code where they can see it, and I talk through it as I code. I say out loud what I’m thinking as I code. And inevitably I make mistakes. Then I look at the error message and talk through reading it and trying to figure out what it’s saying. You would be amazed how effective this is, for several reasons. First, I’m modelling the thought process of coding. That removes some of the mystique (and gypsy magic) of coding. And perhaps more importantly, I model that I, the supposedly know-it-all teacher, make boneheaded mistakes. Many times. And I have to fix them. Which includes reading the error messages, trying to puzzle it out, changing the code, trying again, getting another error perhaps, puzzling through that one, changing the code again, etc. It’s a process that EVERY coder must go through. Students who are not used to failure and fear it as a plague will learn that it’s all part of the process. Even Mr Irving fails all the time. That’s just normal.
On a more Python-specific note, I usually talk or demo the importance of indents. Python does not have much in the way of squiggly brackets, semi-colons, etc., that other languages do. What it does have is indents. And they really matter.