The Blog

Learn To Code

« Sherlocked

Annotating Recipes »

Much of the discussion about Apple's new Swift Playgrounds has confused the platform with the early sample content.

The platform is wonderful. It is full of potential and has the chance to provide a rich environment for classroom material. I'd love to see a Mac app that can be used for the same playgrounds. I'd love to have authoring tools. I'd love to be able to build on material to enable the user to create complex apps from modules.

That said, I love what Apple has given me. If they continue to evolve Swift playgrounds as they have Xcode playgrounds, this will be a wonderful tool for teaching and learning. (See my article Playing Safely in Swift Playgrounds on

On the other hand, I don't like the "Learn to Code" sample content at all.

I have no idea what went on inside Apple, but I imagine it went something like this. Last year when they hosted "Hour of Code" in some of the stores, someone said "This is great, but we should have them using our tools and they should be learning Swift."

I say that because the "Learn to Code" content looks as if it derived from much of the "Hour of Code" content. We've seen many of these ideas before in Scratch, Karel the Robot, and Logo over the past fifty years.

Yes. Fifty.

The "Learn to Code" interface is beautiful. Instead of the simple interface of environments that have come before it, "Learn to Code" has paths and grass and waterfalls with mist at the bottom. You can zoom in and spin the 3D world.

All of this reinforces that students are playing a game. None of it reinforces that they are learning to code.

All of this is a reminder that they are playing in someone else's world. No student looks at this and thinks they will be able to build it. Forget the programming, the quality of the visual assets is beyond almost anyone using "Learn to Code".

All of this motion and activity is distracting to many of the students who will be using "Learn to Code". These visual stimuli and interactive abilities entice students away from the task at hand.

Some speculation:

(1) I would guess that most kids who try "Learn to Code" on their own do not get very far into the curriculum before abandoning it.

(2) I would guess that those who complete "Learn to Code" do not move on to other coding tasks but look for other puzzle games.

(3) No one who interacts with "Learn to Code" thinks "I can build this."

(4) The participants are not learning to code. They are not even learning the logic of coding.

With Scratch or Karel the Robot or Logo the environment does what you tell it to do.

In the first lesson of "Learn to Code" students can choose from the commands moveForward() and collectGem(). I think the addition of collectGem() adds unnecessary complexity to the activity but I have more of an issue with the 3D-ness.

I tell the beast to moveForward(). Now it encounters stairs. There is no climbStairs() method. I would think if I told it to moveForward() it would get stuck on the stairs because it doesn't know how to go up or down. Conceptually, why do I need to tell it to move forward, back, left, and right and even jump to collect a gem but not to move up and down stairs?

Suppose I figure out that moveForward() allows the little dude to climb stairs too. I go forward five times even though I only need to go forward three times. The little dude gets to the edge of the cliff and looks over but doesn't move forward.

This thing is in 3D. Shouldn't the little dude move forward again and fall off the edge of the cliff and plummet to its death?

Kids would love this.

More importantly, if the student's instructions lead to the little dude falling off the edge of the world, the student would learn that they've done something wrong that they need to fix. Programming is all about learning what went wrong and fixing it. If we don't let them do anything wrong then what are we teaching them? At this point they are playing a game not programming.

That's ok if your goal is to have kids play a game.

As I said, we have many years experience with these environments and many examples of really good curriculum to draw from.

A year ago I created a version of turtle Logo in an Xcode Playground and some curriculum and began teaching workshops to kids around the world. I took advantage of years of experience of teaching using Logo in the '80s and later with AgentSheets, Squeak, and Scratch.

In addition, I got a great deal of help from feedback from the workshops I ran and from parents who downloaded the playground from Git Hub.

One parent suggested that initially, the turtle should have a target to aim for. Once kids had mastered navigating the turtle to various targets they would be ready for more free form tasks. This turned out to be a great suggestion that I implemented right away.

In the year before I wrote the turtle playground, I spent a lot of time thinking about it. I led discussions about teaching kids and about pedagogy. I told the story of a Japanese math workshop I attended where the instructor explained that they teach 1 * multiplication a year before they teach * 1. In the US we think of multiplication as being commutative so 1 * 5 is the same as 5 * 1. But conceptually, 1 * 5 and 1 * 6 are "one five" and "one six". There isn't really multiplication going on there. On the other hand, 5 * 1 and 6 * 1 are "five of something" and "six of something". They are multiplications.

After testing the curriculum at workshops I realized that I was introducing for loops too early and function parameters too late. I swapped the order and students did much better. What's wonderful about the looping and parameter lessons is that students are working in a playground so they can try things, change parameters and looping coefficients and try different things. Just like real programmers.

My experience creating the turtle playground is similar to their experience interacting with it. As programmers, we spend a lot of time getting things wrong, puzzling about what needs to change, and then fixing it.

My turtle was initially just the greater than symbol ">" like the original Logo turtle. Several parents asked that it look more turtle-like so my designer created a turtle icon that the students steer around the playground.

The final lesson in my curriculum is that I show the students my code. They've been learning to code, so the last thing I do is open up the Source files and show them that my code isn't much more complicated than the code they've written. If I'm teaching them to code, I want to make sure they understand that what they've been doing is the same thing real coders do.

I think that "Learn to Code" demos great. It needs to do more than that.

I was told that "Learn to Code" is "teacher-proof". That kids with bad or non-technical teachers can use this to learn to code. I've always found the phrase "teacher-proof" offensive. You cannot replace good instruction. With a good instructor, "Learn to Code" can be awesome.

But with a good instructor, pretty much anything can be awesome.

Blog Index and Subscription Information