Category Archives: programming

The arts are a powerful entrance into computer science. In fact, there’s a whole lot of creativity that can be done with CS. One of my absolute favorites is Sonic Pi. Sonic Pi is a free program that enables anyone to code music. It’s the brainchild of Sam Aaron from Cambridge, who teaches CS there. In his off-hours, however, he’s a massive electronic music fan and DJ. Naturally, the thought occurred to him of combining these two passions and giving young people the tools to create their own awesome music while learning how to code. Brilliant!

Sonic Pi is written in the Ruby programming language, but that’s pretty much transparent once you start coding. It’s a free program, available on all platforms and is currently included in the latest release of Raspian. It’s a wonderfully integrated IDE, with 10 “buffers” (coding windows), an extensive built-in help system with examples, a window where you can watch the code as it executes, as well as an internal musical graph, so you can visualize your sounds in terms of volume, length, etc.

You can run the whole thing from the RP, but you’ve got to provide your own speaker, since the Pi doesn’t have one (trying to keep the cost and size down, remember?). But there are plenty low-cost options. And headphones are another option; most students have a set of earbuds if you’re cash-strapped. Using speakers or headphones requires one more extra step. Be sure to left-click on the sound icon in the upper right of the main Pi window. Bump the volume all the way up. Then right-click on the same icon and change the output from digital to analog. You’re good to go.

Most people start with writing a simple tune. You can do this by using the “play” command followed by a number. The numbers correspond to the MIDI numbers, so middle C is 60, like so: play 60. That command plays one note of middle C for one beat. A beat is roughly a second, since the default bpm(beats per minute) is 60. It also plays that note with the “beep” synth. A synth is sound that the notes play their notes with. The default synth is a beep, but as we’ll see, there are dozens more available.

If you are familiar with musical notation, you may instead say “play :C4”. Watch that colon! It’s required for the name of the note, but not the number. The easiest way to set up your code is to put each command on a separate line, like so:

play 60
play 64
play 66

You then click the Run button at the top, and your music plays. Or not. If you’ve made an error, it won’t play, but the output window right beneath the code will tell you, in more or less intelligible English, where and what your error is. I find the Sonic Pi/Ruby error messages generally make more sense than the Python ones to most students. In the case of the above sample code, it will play, but the results will not be what we expect, because it will play all of the notes at the same time. In other words, it plays a chord. It’s all very well if that’s what we wanted, but it isn’t. We wanted three distinct notes in sequence. Why didn’t Sonic Pi know that? Well, as we’ve said before, computers are dumb. They also execute commands ridiculously fast, depending on the computer itself, what else it’s doing at the moment, and a host of other factors. So running that code essentially plays them all at once.

How do we avoid that? Simple, we’ve got to tell the music to pause after each note. Musical notation does this, of course, so we just have to know how to make Sonic Pi do it. The command we want is “sleep”, as in “sleep 1”. What if we want pause a half beat? sleep 0.5 (and yes, the 0 is necessary). So if we want to play those three notes, and vary the timing, we could do something like this:

play 60
sleep 1
play 64
sleep 0.5
play 66

Try it! Then experiment with the timing between the notes, then the notes themselves. Take on Twinkle, Twinkle or Mary Had a Little Lamb. I get bored with those; my personal favorite is Seven Nation Army! Just a bit funkier than Twinkle Twinkle.

Of course, the whole point of using a computer is to get it to do the boring, repetitive work. Why should I waste my time and energy typing the same code in twice? I do realize there is copy and paste available, but even with that, it clutters up the buffer and makes me crazy by forcing me to scroll up and down to look at the code. One simple command solves that:

2.times do

Here’s the tricky part. Just as with using indents in Python, we have to have a way to tell the computer exactly what it is we want it to repeat, we have to do the same with Sonic Pi. We do this be placing an “end” after the material we want repeated. Like so:

2.times do
play 60
sleep 1
play 64
sleep 0.5
play 66
end

Sonic Pi will usually indent the code for you, but it will still run even if not properly indented, unlike Python. I tell students that it’s like a pair of sneakers: they always come in pairs. Every “do” requires an “end”. Make sure you follow that rule, or you’ll get some unexpected results, or no results and an error message. And also note that can specify exactly how many times you want the code to repeat by just changing the number in front of .times: 33.times do.

Next question, of course, is…. how do I get it to play forever? Now we’re getting computer science tricky. In Scratch, it’s “forever”, and in Python it’s “while True”. In Sonic Pi, it’s called a live loop. And you set it up like this:

live_loop :twinkle do

Several things to observe here. First, don’t forget the underscore character between live and loop. Secondly, don’t forget that colon before the name of the live loop. Third, you can call the loop whatever you’d like, though it makes sense to call it what is, since you’ll have multiple loops, and if you call one “fuzzybunnies” and another “fattedfrogs”, after a while you probably won’t remember what exactly each one does. Fourth, don’t repeat the loop name in the same buffer, or Sonic Pi will just play one of them. And lastly, don’t forget that “do” at the end of the line! And you know what that means — yep, you’ve got to end the code with an “end”.

Seems like a lot to remember, but not really. After a little while it will become automatic, like all other coding conventions.

So we’ve learned how to pick out a simple tune, play it a few times or forever. But you have to admit that the excitement of that wears off pretty quickly. Partly because those beep notes aren’t too exciting, once you get over the initial excitement at coding a tune. How about we change the sound of the notes? We do that with what are called “synths”.

A synth is not the note itself, but the way the note sounds. For instance, you can play the same not on a clarinet, a piano, and a distorted electric guitar, and you’ll get three very different sounds, though the notes are all the same. Sonic Pi has many built-in synths, so we can create all kinds of moods and sonic layers with some simple code. The relevant code is “use_synth”, and it must be situated BEFORE the notes that you want to modify. The easiest way to experiment is to type the command on its own line and then hit the space bar. That will open up a dialogue box of all the synths that are available on your version of Sonic Pi. The list is alphabetical, and you can simply scroll through the list till you find one that sounds interesting and it will insert that on the line in correct Sonic Pi format. Find something that intrigues you and try it out! As Sam Aaron always says, there are no mistakes! If you don’t like it, cursor up to the line, hit backspace to erase the name of the current synth. Stop your backspacking just before you hit the h in use_synth, and then hit your space bar again. You’ll get that alphabetical list of available synths again. And if you get tired of arrowing down through the list, or you know that you want to use tb303, for example, hitting the “t” will jump you down to the synths that start with t.

Now, admittedly some of them don’t sound particularly musical, in fact some of them sound like noise! Which is, in fact, what they are. But there’s a place for noise in certain pieces, so maybe save those synths for when you need them.

The other magical thing about Sonic Pi is that it enables you to do LIVE music coding. Some students, especially if they have some musical background, want to recreate their favorite song and so want guitars, piano, bass, etc. My experience is that Sonic Pi can certainly do that, but that misses out on the fun. LIVE music coding means that you can change the sounds AS your piece plays, adding or subtracting synths, beats, and samples as you go. So it becomes a live performance piece, something like a DJ will do. By mixing in and out pieces of sound, the DJ creates something new on the fly, so it’s a performance. Fun!

There are so many amazing and truly advanced things that you can with Sonic Pi, that it goes beyond the scope of this book. There are a host of amazing resources out there and I’ve listed several of my personal faves at the end of this chapter. But I would be remiss if I didn’t at least touch on three other amazing tools in the Sonic Pi toolkit: samples and opts and effects.

A sample is simple a piece of sound. They’re used all the time in music. Hip hop artists routinely sample other songs or sounds and build their own songs out of them. Sonic Pi comes with a host of built-in samples. Some are musical (drums, for instance), and some are random sounds (like the ever-popular burp). They are used by the simple code “sample”. As with the synths, if you hit the space bar after you type e in sample, a dialogue box with a list of all the samples pops up, and you can scroll through till you find something you like. It plays like a note, for whatever duration you specify. So it’s a timed unit of sound, like a note.

The other cool thing that’s available in Sonic Pi is what we call an “opt”. That’s short for “option”. An opt is a device that lets you change the sound of the note or sample in some way. For instance, you have access to the entire ADSR filter range (Attack, Decay, Sustain, Release), by which you can shape the length of a note, how long it takes to trail off, etc. You also have access to a range of other options like panning, and volume. You use these by putting them on the line of the sound you want to effect. So if you want to add more volume to a note, you would code
play 60, amp: 4

That would make that note 4 times louder than the normal volume (which is 1).

And finally, there are multiple effects you can add, like reverb and delay. If you’re familiar with effects pedals for the guitar, this will make you feel right at home. Except instead of stepping on the pedal, you slap it into your code where you want the effect to start. And each effect us fully customizable, so you can code different types of reverb for instance (room, hall, plate, etc.).

with_fx :reverb do
play 60
sleep 1
play 64
sleep 0.5
play 66
end

Don’t forget the do at the end of the effect line, and of course, you need to tell Sonic Pi when to stop using it, so you’ll need an end for that.

It’s truly amazing what students can create with a few simple tools! And for those who will tell you “I’m not a musician”, I always give Sam Aaron’s answer: “Not yet!”

In the last few years, we’ve seen a slew of single board computers (SBC’s): Arduino, Beagle Board, Raspberry Pi…. They all have their place, and we’ll speak a bit later about what those places are. But I’m here to tell you that for all-around computer science use and mega bang-for-the-buck, you just can’t beat the Raspberry Pi.

By now, most people know about its back story, springing out of Cambridge University and a desire of their CS profs to acquaint their students with what a computer actually IS. There’s no doubt that computers are easy to use today, but that very ease of use has taken away some of the fun and excitement of learning how a computer works and how to get it to do what you want it to do. I’m totally dating myself here, but I do remember getting a Commodore 64 (cue the “backintheday” music as Grandpa regales the young’ns with tales of yesteryear). When the 64 first came out, there was a dearth of software available. But it did come with a thick spiral bound book called “Commodore Basic”. The expectation was that anyone who bought a computer would certainly want to program her own software, not just buy stuff off the shelf. And there were several magazines on the newstands that had “type-in” programs that ran several pages. I think some of it was even in assembly language! But the thinking was that computers helped you get stuff done, play games, etc., but also were things that you could use to make your own stuff.

Today, computers are a black-box technology, like a car. How does a computer work? I love asking that question and seeing the blank faces of my students! It’s easy, Mr I, you push the button! My personal favorite answer is “gypsy magic”; top points for creativity. But that doesn’t get us any closer to understanding what a computer actually is! Though it’s a wonderful fulfilment of Arthur C Clarke’s saying that any technology that we don’t understand is the same as magic. So if we can start to figure out how it works and get it to do stuff that we want it to do, then I guess we’re wizards! All right!

So this little credit-card sized, $35 computer is getting us closer to being magicians, and probably better than anything else available today. So how does it do this, exactly?

First of all, it’s not in a box. You can see the motherboard, the CPU, the traces on the board… You can plug sensors and wires into its 40 GPIO pins, which provide voltage and “channels” you can use to code attachments. And the attachments are plentiful and not too expensive, running the gamut from sensors to lights to buzzers to cameras to audio devices to… whatever! You can see both sides of the USB ports, so the mystery of the inside of the computer is laid bare.

The Raspberry Pi Foundation provides an updated OS, as well, called Raspian. It’s an offshoot of Linux (but so is the Apple OS, so don’t be scared). This OS has a modern looking GUI (graphical user interface) and comes with a host of programs that you can run right away. So it’s not too scary looking to students familiar with Windows and Apple: desktop, menus, icons, left and right clicks, etc. Pretty intuitive, we’d say. However, some tasks require digging into the terminal, a CLI (command line interface), which goes way back. And while that’s new and different to many students, it’s not impossible. Though, as I often remind them, spelling counts!

And it comes with an ever-changing assortment of free, open-source software (and that can actually be an interesting discussion. Why is this software free? Who writes and maintains it? I love seeing the students eyes widen as the catch a glimpse of an economic model that’s an alternative to individualized capitalism…). The current version as of this writing (Stretch, and yes, all of the versions of RP are named after characters in the Toy Story series. So if you had any doubts about how cool this all is….) includes the Libre Office productivity suite, Mathematica, a browser, some games, and most importantly for our purposes, a host of programming tools and environments. Scratch 1.4 and 2.0, Python 2 and 3, Java, Greenfoot. An older version of Minecraft is included FREE, and though it’s not the latest and greatest, it’s perfect for learning coding. Check out my chapter on that. And there’s even a live music coding application called Sonic Pi. While I wouldn’t use it for my everyday computer, it can do a lot that an everyday computer can’t do, like physical computing and attaching to other machines.

One thing that the Pi doesn’t have is a hard drive. In order to keep the form factor small and the cost down, they work by loading the OS (Raspian) from an SD card, which autoboots when the Pi is powered. Programs are saved to the SD card as well. So it’s a little bit of a throwback to DOS.

So what do you need to get started with RP in your classroom? Well, that $35 computer thing isn’t entirely accurate. You’ll need a few other things, but the RP people rightly figure that everybody already has a keyboard, mouse and monitor. All of these are plug and play. Latest version of the Pi has 4 USB ports and an HDMI port. You’ll also need some sort of power source, and the wall wart variety are available and usually come in a RP kit. In my classroom, I power them from power bars that have USB slots, which I’ve found preferable to having 25 wall warts to take care of. I use the power bar to power the monitor and the other computers I have in my room, which all run Windows 10.

How do you get Raspian on an SD card? Fortunately, www.raspberrypi.org has download links for the latest version, as well as instructions for how to download it and install it on an SD card. Once you put Raspian on the SD card, put the card in the Pi, and power it up, the installation software takes over, prompting you from time to time for your preferences. Don’t worry, all of the preferences can be changed from the settings menu on the Pi.

Because it’s based on Linux, which is based on Unix, which is a user-based system, the Pi requires a login. The initial default username is pi, and the password is raspberry. You should change that as soon as you can. One advantage to this is that if you have multiple students using the same Pi and the same SD card, you can set up different users so they don’t all save to the same folder. It’s not necessary but you might save yourself and your students some serious grief. I’m not sure why, but students sometimes all use the same filename when they save their Scratch game (“game” is a favorite). And if that happens, Johnny will overwrite Suzie’s Scratch “game”. Ouch.

There’s not much that can compare with the joy students get when they build and program a robot. I’m currently using 2 platforms — the Dash robot from Wonder Workshop, and NXT LEGO Mindstorms. I use the Dash in 5th grade, and the NXT in 7th grade.

What’s the attraction with robots? Well, they can move, make noises, and respond to their environment. What’s cooler than that? Not only that, but we can make them do what we want them to do, so they can become our own little minions!

The secret sauce of robotics is that we can actually watch the results of our code manifest right in front of us! We know right away if the code is right or wrong, so there’s immediate feedback. I always tell students that it’s not like other classes, where they take a quiz or test and have to wait for their teacher to grade them and get them back to you. You know right away! Not only that, but then you can modify your code and run it again. And you can do it as many times as you like in order to get it right. Yes, there’s frustration along the way when your robot doesn’t do what you want, but oh the joy when it does! Happy dance time!

Along the way, students learn something really important about robots — they’re kind of dumb. They can only do exactly what we tell them. They can’t figure out what we mean. We humans can “fill in the blanks” when others try to communicate something with us. We can infer meaning. Robots can’t, at least not yet! So that means we have to be super careful about all the instructions we give them. Welcome to computer science! As a side note, what a great training ground for middle schoolers who have organizational challenges and need to pay attention to detail! And I always tell them when they complain about how their robot is “dumb”, they’re only as smart as the instructions we give them! Ouch.

What about how many students per robot? I realize there is a range of opinion on this, and I get the importance of collaboration. However, I’m a big believer in each student having her own technology, if at all possible. There’s something to be gained from knowing that the success or failure of your robot rests entirely on you! But that may not be feasible in your situation. So work with whatever you have, but be sure that all members of the teams take ownership of the robot’s success and share the challenges as equally as possible.

So how to structure a robotics unit? My approach is to have the robots simulate a real-world series of tasks. In 5th grade, with the Dash robots, we are currently doing the “Robot Olympics”. Most of these challenges mirror Olympic events, but I’ve also taken the liberty to make up my own events. I made a 3X3 grid on the floor with duct tape or gaffer tape, which is where the events take place. Right now I’ve got Olympic tic-tac-toe, diagonal racing, curling (well, kind of), and whatever else inspires me. Teams compete and I keep a scoreboard on my whiteboard to let teams know how they’re doing. Because the Dash robots come pre-built, it’s really a matter of coding. Wonder Workshop provides 3 different platforms for coding Dash (and Dot, his less useful sidekick), and I use Blockly in 5th grade. It’s Scratch-like and fairly easy to do the dragging and dropping, making the coding the harder work. Students generally are fully engaged and love the competition. Since this is my first year of using Dash, I fully expect to build this out further. Wonder Workshop has all kinds of challenges on their site which I have yet to explore, so I anticipate continued success with this platform.

In 7th grade, I use the NXT LEGO Mindstorms platform. I realize that the EV3 has replaced the NXT, but I honestly have not seen enough compelling change in the new platform to convince me to do a wholesale switch. At some point it will happen, as the NXT bricks get harder and harder to find, but for now we’re good.

I have each student build the basic Tribot model, then add sensors as needed. I use the ultrasonic sensor first, then mix in challenges with the touch and light sensors. The sound sensor is less useful for my purposes, possibly because of the volume level of my classes (did I mention that it can get loud?). So I hardly ever use the sound sensor.

In my current iteration of challenges, I model them all after a real-life robot used in hospitals around the world called the TUG robot (built by Atheon). This robot can navigate through the hospital autonomously, avoiding obstacles and making deliveries. It can even call an elevator and choose which floor to exit at! My challenges model some of these functions. I chose the medical robot for a variety of reasons, not least of which is that it’s involved in helping people in a real way.

Some students find the building of the robot challenging, though I give them official LEGO building instructions printed out in official LEGO language (all pictures). Some students have spent much of their childhood playing with LEGO’s and are already “master builders”. Some have never connected any LEGO’s at all. Again, attention to detail is paramount. I tell them to make sure they double and triple check each part of the build, hold their robot up to the paper and be sure everything is correct. Why? In robot building, attention to detail is crucial, and if you find on step 22 that something’s wrong, you’ll have to “unbuild” your robot back to the point where you made the mistake, even if that’s on step 5! Ouch. Hard fun again.

So what does this look like in class? To be honest, sometimes it looks like complete pandemonium. Learning is messy. In one corner of the room, there are students moving a trash can in front of their robot, simulating a moving obstacle in a hospital hallway and trying to get their robot around it. In another corner, one student is helping another rebuild their robot so it works(though they have to follow my rule: don’t touch the other person’s bot!). In another corner, students are getting a mini-lesson from me on how to navigate the software and download it to the robot. On the board, I have my Help List, which determines in what order I answer questions. When students have tested their robot and know they have it working right on a particular challenge, they put their names on the Help List and excitedly demonstrate their bot meeting the challenge (or not. Sometimes it still doesn’t work, and they are back to coding and running the robot again, with some modifications on either the code or the bot). At another workstation, one student is helping another student with the code (again, following Mr I’s rule — don’t touch their keyboard or mouse), pointing to the screen and showing where their mistake is. 2 people are going through the bins in one corner of the room to find that special LEGO piece they’re missing, holding it up against the printout to make sure that axle’s the right size…

You get the picture.

What am I doing all this time? Trying to keep one eye on the Help List on the board, letting kids know they’re next for my help, circulating through the room, fending off questioners who want to skip the HelpList, listening and watching for frustration (not always a bad thing!), nabbing the odd student who isn’t focusing and getting him refocused, checking the clock so I don’t forget to give the 5-minute warning (time to clean up! LEGO sweep at your feet! turn off your robot and put it in the closet! hang up your programming cable and restart your computer!)… every class is a trip.

For my first foray into text-based coding, I recently moved to coding Minecraft with Python. Or “Mython”, as I affectionately call it. I’ve tried other things, like Small Basic and GameMaker (GML, their text language) and, while students can learn from any platform, I felt Minecraft offered more bang for the buck.

The engagement factor is off the charts for Minecraft. I’d be crazy not to try to tap into that. So I launched a year-long exploration of various coding environments for Minecraft(you can see my now somewhat-dated presentation from CSTA 2015 here). My conclusion was that Python offered the best entry-point, and the amount of support available tipped the scales for me. Here’s why:

It’s fairly easy to install and available on Mac, PC, Linux, and Raspberry Pi. For the first three, you’ll need Minecraft, Python, and an implementation of a Bukkit server so that each student can run her own instance of Minecraft. She will also need a Minecraft license (which does cost $27US, but many kids have one already). The beauty of Mython on the Raspberry Pi is twofold — no need to purchase a Minecraft license, since Mojang donated an early version of Minecraft to the Raspberry Pi Foundation. And the Bukkit server is not needed. So there are two big steps you can skip, if you’ve got a set of Raspberry Pi’s (see my chapter on RPi for many reasons why you should consider this).

So why Minecraft?

Engagement level is super high.

Most kids have some familiarity with the game.

The ability to “mod” Minecraft is enticing (though this isn’t modding in the strict sense of the word).

Support is good. I highly recommend getting a copy of the Mython “bible”: Adventures in Minecraft by David Whaley and Martin O’Hanlon. These two gents from Great Britain literally wrote the book on coding Minecraft with Python, and it’s all laid out in an attractive, logical, and clear way, with lots of cool challenges to extend your learning. The authors host an awesome website (www.stuffaboutcode.com) which has a forum for those thorny questions. They are more than willing to help out, and I’ve found these two to be always helpful. In addition, they are on Twitter and have always responded quickly, kindly, and accurately to my questions. And version 2 of Adventures in Minecraft now has support for the Microbit board!

Check out the appendix of the book for more resources.

Here’s how I “teach” Mython. As you might gather from my pedagogy, there’s a reason I put “teaching” in quotes. I stole the idea of the “hackpack” from Chris Penn in Great Britain, as well as some of his excellent code ideas and challenges. I print out “hackpacks” for each student. These include anywhere from 4-7 programs on a particular topic (the first covers basics and building, the second covers triggers, etc.). The code is liberally commented with explanations of what the code does, how it works, analogues to Scratch, gotchas, and whatever I think will help the students understand the code.

And yes, I give them a printed paper copy of the code. That’s by design. I know that copy/paste works great for getting code, and I use it all the time. However, I believe when a student is learning a new language, the muscle memory that she uses by actually hitting the keys and looking at the screen is invaluable in making it stick. It also gives the student a fabulous opportunity to become personally acquainted with error messages! I tell them that error messages are their friends. They don’t believe me, of course, but it’s true, because Python is training them to speak in a way that it understands!

That, of course, is the big difference when we take the training wheels off! It’s now possible to make syntax mistakes! Spelling! Punctuation! Capitalization! Indents! All of it matters. And Python doesn’t know “what you meant”; it only knows “what you said”. Sorry! But welcome to the wonderful world of code.

The good news is that students want to make their code work, and they’re willing to keep at it, fixing errors, until it works. Aha, the magic of Minecraft! Much preferable to doing coding exercises that sort lists or do math or any of the other introductory exercises I’ve seen. I have to confess that my reaction to all of those is a great big “meh”. Who cares? I already know what 8 + 7 equals. Doing it in Python doesn’t make it much more palatable. But if I can figure out how to teleport myself 80 blocks up in the air and 40 blocks to the east, well, that’s cool! And incidentally it’s also teaching a 3-dimensional coordinate system, but shhh…. stealth teaching, remember?

So they get their hackpack, and they type in the code, and it works! Fiero! The dance of joy! But they don’t actually earn any credit for that. I tell them, “Congratulations, that means you can type.” To earn points, they must code what I call a “reverse”. That is, they have to take that code and do something different with it. For instance, one of the hackpacks has code that updates my position every second and displays it in the chat window with the relevant x, y, and z position. The “reverse” is to display it every 4 seconds. Hmm… how to do that? Well, where in the code do you say to display it every second? We look at the loop (while True:) and find the code that says to get my position and post it to the chat. Do you see anything that says to do it every second? Oh… time.sleep(1)! The light goes on, and they swap out the 1 for a 4! Easy peasy! But they’ve learned about a loop, they’ve learned how to get and update my position continually, they’ve learned how to print that to the user (Hello World!), and they’ve learned about delays as well (and that you have to import the time library in Python for it to work).

And I didn’t have to stand at the front of the class and say, “Today, class, we are going to learn about… now follow me as I type on the screen and type that exactly, all together now…” Yawn. Students do it at their own speed and find their own “aha moments”! And they get to see it actually happen in Minecraft, on their screen, caused by the code that they just typed in! Woohoo!

So you can see why I’m excited about using Minecraft for teaching coding!

Another carryover, I’m hoping, is that when they go from my class in 8th grade to our 9th grade CS class, where they will code their own original games using the Pygame library, that at least some of this will be burned into their brains. At the very least, they’ll remember they have to be careful with what they type, since they learned firsthand how picky “the Python” can be!

So if I had a standards-based curriculum, what CS standards and concepts have I “covered”? By the time we’ve finished the unit, we can check off: conditionals, events, triggers, 3D coordinate systems, for loops, variables… in Python, they’ve learned about importing libraries, proper indents, colons and why they’re essential, and how to read Python error messages. But again, shh…. let’s not spoil the fun.

Most teachers agree that it’s better to start with block-based programming, and I heartily agree. I don’t introduce text-based coding till 8th grade and that’s only after my students have had a thorough exposure to a few different styles of BBP. There are so many possibilities that it’s just a matter of choosing what works for you and your students. Here’s what I’m using currently:

I think Microsoft really hit it out of the park with the MakeCode environment for several reasons:

it’s free.

it’s web-based, so accessible from a variety of devices.

it works on several different hardware and software platforms and more will be rolled out as we go. As of this writing, it supports Microbits, Circuit Playground Express, the Chibi Chip, Wonder Workshop’s Cue robot, and the queen of them all, Minecraft(only Education Edition, however)! That’s important to me because I use the Microbits in 5th grade, the CPX and Minecraft in 6th, so students can become familiar with the environment and make an easier transition from one to another.

also, did I mention that it’s free?

And of course, there is Scratch, just getting ready to release version 3.0 as of this writing. With their web-based environment as well as old-school standalone Scratch, it’s the perfect introduction to block-based coding. I use it for game creation in 7th grade. It’s a wonderful vehicle for learning some advanced CS principles in a relatively painless way: loops, conditionals, events, and variables. I say RELATIVELY painless because students still have to wrap their heads around the concepts. But they don’t also have to deal with syntax errors, and the results of their own misspellings and mispunctuations.

There are lots of other platforms that can work for you and your students. My advice is to pick one or two and stick with them. The important thing is for students to start to understand the CS concepts, so that when you introduce text-based coding, they understand what they’re doing.

A matter of debate is what should the first text-based coding language be, and when should it be introduced? I prefer Python. It’s more accessible, I think, than other languages, because it’s more like natural language than say, Javascript. So it has a pretty easy on-ramp, and lots of ceiling. It’s a language that students can grow with, with its thousands of libraries for everything from Raspberry Pi input/output to gaming to scientific algorithms. There are jobs out there that require Python. And the Computing At School curriculum in Great Britain uses it as the first text-based language. That’s a pretty powerful endorsement.

Downsides of Python? There are a couple. Perhaps the biggest is its sensitivity to incorrect tabbing. If you use IDLE, the built-in editor, it will automatically tab lines correctly in if statements and for loops, but I’ve seen students reach maximum frustration when the code just wouldn’t work, and it turned out to be a misplaced tab. Ouch.

Other languages? I’d suggest 2 other possibilities: Small Basic and Javascript, in that order. Small Basic is Microsoft’s technology for entry into text-based coding. It has auto-complete (usually useful), and introduces dot notation, an important feature that they’ll run into in many languages. It’s also very natural language-like, more so than Python. I’ve found that students find that it just makes sense. Plus it’s got a great built-in turtle graphics system, which is a fabulous way for students to SEE the results of their code.

Problems with it? No jobs out there that use it. And where do you go next? I suppose you could argue for Visual Basic, but that’s not a path that most schools go down in high school. So it’s a bit of a dead end.

Javascript was chosen by Microsoft to be the language that MakeCode translates to. I have to say that I really wish they had chosen Python for this. However, it is used widely everywhere, on the web and elsewhere. And it’s certainly more accessible to most students than C#, C++, or (God help us) Java.

Whatever language you choose, that initial experience of what I call “taking off the training wheels” can be challenging to most students. I try to liberally comment my Python sample code with references to what they know in Scratch. For instance, I will do this

while True: #same as “forever” in Scratch

But there is inevitably going to be that time of discomfort as students try to make that leap to Python syntax. This might be an argument for using Javascript in the MakeCode environment, since you can switch from blocks to text with the click of a button. I haven’t tried this, so I can’t recommend it. Truthfully, I think I’d rather not have those training wheels so convenient, since students might be tempted to not take them off, and thus never truly learn how to ride that bicycle (to strangle the metaphor).

I was thrilled to attend Minefaire 2016 near Philadelphia, PA this weekend, where a Guiness world record of attendees met their favorite YouTubers, played games, did build battles, sampled VR wares, and even experienced how Minecraft can be used in education. I presented on using Python in Minecraft as an intro to text-based coding, based on the book Adventures in Minecraft by David Whale and Martin O’Hanlon.

Finally met Joel Levin, @MinecraftTeachr, one of my heroes.

It was also a personal thrill to meet so many of my online friends and heroes for the first time! Hard to believe that six or seven years ago, this amazing game was just in its infancy in all its 8-bit blocky splendor, causing people to scratch their heads and predict that this would never take off!

Every once in a while I read or hear something that literally makes me sit up and take notice. Hal’s keynote was one of those events. In a few brief moments, he sketched the development of the relationship between children and the computer. He was a participant and eyewitness from the late 60’s, a colleague of Seymour Papert’s, and a creator of some of the early incarnations of the Logo programming language.

Those of us in this field of computer science, especially those who teach it to children, owe a huge debt of gratitude to these pioneers. I also got to meet another giant in this field, Cynthia Solomon, another colleague of Papert and Marvin Minsky. What Hal did in 15 minutes was to trace the development of the connection between children and computers from the earliest days to the present. But it was no mere historical journey. He highlighted recent innovations, like the Internet of Things and physical computing, as well as mobile computing. Now the tools for creation in these areas are in the hands of young people, App Inventor being a very accessible drag and drop programming interface for mobile apps.

Young people of all ages now have in their pockets tools which they can use to shape the world in which they live. We saw one fabulous example of young girls in Moldova tracking water quality and then crowdsourcing the results. Present at the Summit were many young creators. I was particularly impressed with a group of 6 12-year-olds who created an app for autistic children, their parents, and their teachers. It was astonishing in its design and usability.

Hal not only traced the past, but laid out the present landscape of computing and children, and he pointed the way forward. We have truly entered into the next phase. It was such a thrill to be at MIT where so much of this started. I feel truly honored to be a part of this!

I’m here in Boston at the MIT Media Lab. First, how cool is that? I’ve read about this place for years, and to actually be here is a privilege.

Secondly, it’s ground zero for App Inventor folks: teachers, students, professors, developers, parents and kids…. the wide spectrum of attendees speaks to the almost universal appeal of App Inventor. If you’re not familiar with AI, well, it’s time to get started! It’s a drag and drop interface that enables anyone from coding newbies to accomplished devs to create mobile apps. It runs only on the Android platform right now, but there is a product in the works called Thunkable (no, I don’t know why) which will work with iOS.

The great thing is that it is a wonderful tool for teaching coding. And in spite of what some might say, it’s real coding. True, it’s not text, but it has a wide selection of components and tools that will allow you do to some very cool things. And then you can perhaps sell it on the Play Store.

But what really resonated with me was the keynote by Hal Abelson. And that deserves its own post!

There’s a lot of stuff on the web and in print on how to code mods in Minecraft, most of which requires a fairly hefty investment of time in learning Java. And that right at the outset eliminates a lot of beginning coders. What we need are some entry points for beginning to intermediate coders, which most people who are hooked on Minecraft are. I’ve found Minecraft appeals to all ages, but particularly to the 8-12 age group.

Enter Jim Christian’s excellent book: How to Code in Minecraft. In 146 colorful, jam-packed with coding and Minecraft goodness pages, Jim has given the beginning and intermediate coder a multitude of entry points into doing more than just playing Minecraft, but actually coding it. He lays out a steady progression of skills, starting with everyone’s favorite intro coding language, Scratch. He then moves to text-based coding with Python, which I’ve found in classes is a logical progression. From there, he introduces the popular ComputerCraft mod, which uses the Lua language. Along the way, he shows the reader how to set up a free Minecraft server, how to set up and use various development environments, and points the reader where to go after mastering the skills in this book.

Jim doesn’t leave out teaching basic programming principles, like variables, functions, loops, and events. But it’s so much fun along the way that it’s an excellent example of what I call “stealth learning”. Sure, you could give kids lessons on those topics, but they’ll be way more engaged if they’re setting traps, setting off fireworks, and creating their own in-game games! Instructions are clear with an abundance of colorful illustrations. Jim also leaves blank pages for notes at the end of each chapter, as well as suggestions for expanding the student’s knowledge with fun challenges and projects.

If you’re looking for a solid, comprehensive introduction to coding in Minecraft for your class, club, after-school program, or for that Minecraftaholic in your family, you’d be hard pressed to do better than this book. My only complaint is that it’s not yet available on Amazon in the US!

As promised, here’s the skinny on my current Mython approach. I can’t really claim credit for most of it, as I’m using the Adventures in Minecraft book by Whaley and O’Hanlon, as well as some great starter code by Ben Davies, @ncscomputing, and others in GB.

I have three “hackpacks”, which are packets of sample programs that I print and distribute to students. They basically copy the code and run it. After they complete all those successfully, they then use a “reverse hackpack”, which consists of coding challenges based on the programs they just finished. Most have some minor changes required, but all are extensions and applications of the code they did. When they can successfully do that, I sign off on each challenge. I usually ask them to explain something in the code to be sure that there is understanding of what the code is doing.

There are a few spots that I actually “teach” to the whole class, though I try to limit it to 10 minutes maximum. One of those spots is the while True loop in Python, and the other is for loops. Everything else is addressed individually or in small groups as needed (“just in time” learning).

So far I’ve been very pleased with the level of engagement, effort, and learning. It’s the first iteration, so I’m fine-tuning as I go, of course!