Learning to program

When I posted about “What To Teach The Kids“, I desired to write this side-bar on learning how to program.

You see, the trouble with getting started in programming is it’s difficult. Usually you want to learn to program because you want to do something, but there’s a lot of things you have to get straight before you can do something. It’s frustrating. You have to learn programming concepts, like loops, if-decisions, storage, subroutines and the like. You’ll have to learn higher concepts like factoring and organization. If you’re doing object-oriented programming you have to learn that whole paradigm and perhaps start to understand design patterns. Then you have to learn some language and all the quirks that come with it. You’ll have to learn some sort of library or framework. Depending what you want to do, there may be other specialty frameworks or concepts you have to pick up on, like for games work. I mean, it’s hard to get started because there’s so much you must have in order to just get started.

So how can you get started?

It so happens some other folks are presently discussing this, here and here. I think they’re headed in the right direction but haven’t quite gotten there. But the direction really is nothing new.

Karel

Back in undergrad I took this “abstract” computer programming class that used something called Karel the Robot. I remember in grade school learning to program in LOGO, which was kinda neat but looking back I see it was poorly taught and taught without direction… what’s the point of making this turtle draw a star on screen? But that started the ball rolling. BASIC was cool and very functional. But Karel was different.

Karel wasn’t out to teach you a programming language or other hard skills. Karel was out to teach you the basic theory of programming. Karel’s a robot that lives in a grid world. He can do a few simple things like advance, turn left, detect a beeper, pick up a beeper and put it in his beeper bag (I always thought “beeper bag” was a cute concept), detect walls. Very simple things, but from those simple building blocks you were able to learn concepts. For instance, you learned about the notion of subroutines when you wrote the “turn right” routine implemented as 3 turn left commands. And so it would grow from there. Karel was deliberately simplified so you didn’t have to worry about all the gory details that programming truly involves, so all you had to focus on was concepts of programming that apply anywhere regardless of programming paradigm.

Karel’s been around for 30 years, and truly I think this is the way to start programming because once you understand the concepts — and can do so free of all the other complex dreck — you’ll “get it” and be able to progress a lot faster. Karel’s been ported to numerous environments and languages, with an attempt to keep the essence of Karel but also give a gentle introduction to the language. I’m of mixed feeling about that because it removes a basic tenet of Karel: the simplicity of worrying about other stuff. But for those eager to get going, it may not be so bad.

Still, the trouble with the Karel is you can’t do anything useful, but that’s the tradeoff: ease of learning vs. usefulness. Again, when people get interested in programming it’s typically because they want to do something. So how can we get them to do something?

Useful

I’ve looked around for ways to teach kids to program, that honors the real tenants of programming — perhaps simplifying but not dumbing down nor misrepresenting — but still lets them do something useful.

I found this product called Stagecast. I’ve only evaluated it, but it looks pretty neat. It’s visual programming. It’s very simplified, a lot of click and drag and so on, but it still is true to real programming. The real bonus is the feedback and results are immediate. The kids can see what’s happening and how it all works. There’s no need to edit 500 lines of code across 20 files, wait for it to build, fix compiler errors, build again, then try to debug it. It’s like my “fishing vs. catching” analogy: there’s fishing, then there’s catching… you can fish all day, catch nothing, and it’s still a good day fishing. But if you’re trying to introduce a kid to fishing, they want to catch and catch soon else they will lose interest. So for kids, you have to start out with “catching” and as they start to enjoy “catching”, inevitably they’ll discover what “fishing” is. So I feel the same can happen here with Stagecast… let them “catch” and immediately create things in a simplified way. If they truly love programming then they’ll start to see the restrictions and limitations of Stagecast and want to explore further (“I want to write an iPhone game!”) and so, then you can start to introduce them along the path to other languages and other things.

If I picked a more generic path, I’d say the next step might be to teach them HTML. No it’s not a programming language, but it’s still simple, teaches formal constructs and organization, how to look things up in references, and again you get results but still have to debug those results. If they want to do more, JavaScript could be a simpler language to learn. I’d also say a modern scripting language like Python or Ruby would make a good “next step”. But exactly where to go from here really all depends upon their interest and direction.

Of course, something like LEGO Mindstorms would be wicked cool too, if you can afford it.

Make it Fun

Getting started with programming is a daunting task because you have to lay so much foundation before you can do anything useful. I believe laying the core foundation of principles, through something like Karel the Robot, is a good approach to take. Then moving to simplified but immediately productive environments such as Stagecast makes for a good transition. After that, you just have to determine your goals and where you want to go. There are ways to get there in steps, you just have to be patient.