When we come right down to it, the barrier is that students have to type and read code — tasks that exceedingly few of our current literacy programs address appropriately.

Let’s imagine what it takes for even simple programming exercises. How about a number guesser? I’ll write it in the two most popular teaching languages OUTSIDE of AP Computer Science.

This number guesser will generate a random number, ask the user for their guess, and display the result. We won’t muck around with loops or number of guesses. A single-run guess is enough to prove the point here.

Python

import random # Generate random number

num = random.randint(1,10) # Get user's guess

guess = input("Guess a number between 1 and 10: ") # Compare and show result

if guess < num:

print("Too Low!")

elif guess > num:

print("Too High!")

else:

print("Got it!")

JavaScript

// Generate random number

const num = Math.floor(Math.random() * 10 + 1); // Get user's guess

const guess = prompt("Guess a number between 1 and 10:"); if(guess < num) {

alert("Too Low!");

} else if(guess > num) {

alert("Too high!");

} else {

alert("You got it!");

}

Contrived? You betcha. But here are some things I hear from students as we begin exploring these respective languages.

Python

“How do you remember all the functions [ randint , input ]?" “I keep forgetting the colons. And then the indents.” “Mine’s not working [Almost always forgotten quotes around strings].”

JavaScript

“WHAT is that random number line doing?!” “I keep forgetting semicolons/curly braces.” “Mine’s not working [Almost always forgotten quotes around strings].”

Notice that absolutely none of these issues concern programming concepts; they’re all about syntax. If we break down the source of the frustrations outlined above, they almost all stem from pattern recognition and reproduction. At some level, that’s really what literacy of any kind is: recognizing the accepted patterns of symbols (visual and aural) and then reproducing them in intelligible ways. It just so happens that the computer has very exacting patterns and basically zero tolerance for errors.

This part is very difficult, even though it’s not particularly high-level. Even today when I’m learning a new programming language, getting syntax into muscle memory is a vital part of the learning process. Still, I wonder if there’s any way to lower the barrier to entry in another way.

What if typing practice were commensurate with the expectation of fluency demanded by these activities? Actually, let’s go bigger. In order for students to use most of the technology we deploy, we have to prepare them better for the user interface. As long as the keyboard still exists, it should be a considerable portion of what we teach young children. I know we’re scared about screen time (maybe for no reason), but seriously: how much time do you spend using a keyboard in your adult life? How much, compared to the amount of time you spend using a pen?

Thought so. This isn’t preparation for the future; it’s preparation for the present.

We’re not there yet, sadly.

If we truly want to smooth the transition from block-based programming to text-based, no magic application or hybrid programming language is gonna do the job. Instead, we have to build appropriate tech literacy scaffolding in the years leading up to the big jump. That way, when students encounter the blinking cursor with infinite possibilities, they’ll be ready.

Teach keyboarding. Teach it well. The rest will fall in place.

After the Jump

Once you’ve crossed the chasm to text-based programming, there’s another challenge to overcome: abstract reasoning.

We’re introducing programming earlier than students have developed all the requisite cognitive abilities for traditional intro computer science exercises. This is why, for example, students might struggle with the concept of arrays, or with recursion. These abstractions require something developmentally that, depending on the age group you’re teaching, isn’t yet present. We can work around this limitation with careful planning of lessons — specifically, keeping exercises rooted in the visual space, despite using text programming, will provide context and feedback for student exploration.

How friggin’ cool is this?!

My recommendation would be a graphical library like p5js or Processing.py. Heck, even good ol’ Turtle can be a powerful tool.

Using these libraries, not only can text-based programming still have visual context, but also, a new creative aspect arises: code can become art.

There are so many possibilities here, on the other side of the text-based programming divide. Prepare your students to make the jump, then come on over.