Teaching Programming Skills to Children?

KlaatuVN asks: "My younger siblings are asking for ways to learn to program. If I remember correctly, when I was younger I started programming by writing games like 'Lemonade Stand' in BASIC for the Commodore 64. Short of finding a Commodore 64 emulator and digging up some old BASIC programming books somewhere, what do you think is a good way of teaching children to program? I'm not trying to start a 'language war', but that does enter into it. Should I start with a scripting language? What, O Wise Slashdot Readers, are your opinions?" When I was just starting out in computers, I remember LOGO being a big help in teaching me the logic skills I would eventually use as a programmer. I know LOGO is still around, but it would be interesting to note if there are other similar projects like it. What tools, and programs would you use to teach programming skills to interested youngsters?

Comments

Older kids learn Python easily enough

[flockofseagulls]

I've been teaching Python to older kids and teens (10+) and have had good success. A few younger kids started in the classes but had trouble with typing and general computer skills. Most of the kids caught on to programming and were writing their own variations on assignments.

Very young kids have problems with attention span, reading, typing, etc. so you may want to use something like Lego Mindstorms instead of text-based programming.

See www.geekschool.org for one approach.

Assembly

[inflexion]

I would vote for assembly (no this isn't a joke). Assembly is really simple when it comes down to it and would be good for instruction for several reasons:

1) fewer operators than pretty much any other language (unless you're talking about x86 asm)
2) teaches how computers *really* work inside. I never became an effective C programmer until I learned assembly and what was going on behind the scenes. Your kids will learn the basics of booleans, memory layout, branches, etc much more thoroughly than if they started with C. After they've mastered asm then they can move on to C and will appreciate it that much more.

Criteria

[Piquan]

I'd look at it from some criteria. The weights that you give these criteria would vary depending on your target audience. For most audiences, I've listed them in descending order.

I refer to the Lego Mindstorm's RCX here. There are two forms for this. One is the graphical program builder that comes with it. The other is traditional languages like NQC. Generally, NQC etc have all the disadvantages of C.

• Interactivity. It is important for a student to be able to examine the state of the program. Being able to enter single commands, and later form them into subroutines, is very helpful. Good: Logo, Lisp, Python, Smalltalk. Bad: C, Perl, Java.
• Feedback. The program should be able to easily effect things outside of the command processor. Turtles or robots are good vehicles for this. Graphical displays are okay. Very good: Logo, RCX. Kinda good: Smalltalk (under Squeak), Lisp (under something like Lispworks). Not too bad: Java, CGI Perl. Bad: C. (Note: Any language can give output, but there's an extra spark of interest when you can easily produce "cool" effects.)
• Growth potential. As the student begins to learn about more advanced data structures and algorithms, the language should grow with the student. Good: Lisp, Python, Smalltalk. Bad: BASIC, Perl (it gets too bogged down in syntax).
• Easy to use. The language should not require a lot of low-level work like memory allocation. It also should not have an overly cumbersome syntax. Good: Python, Logo, Lisp, Perl. Bad: C.
• Flexibility. The language should allow you to teach different styles of programming, such as functional, imperative, and object-oriented. Good: Lisp. Bad: Almost anything else.
• Real-world applicability. The language should be usable in the real world. Good: Python, Perl. Bad: Logo.

Overall, either Logo or Python would be a good choice, depending on your target audience. I'd say that Logo would be a good choice for 12 and under, and that Python would be good for after that. Note that Logo knowledge easily translates to Lisp, so one possible track would be to start with Logo, and later transitition to Lisp.

PostScript

[iankerickson]

Consider using PostScript as a teaching language for kids.

I know, I know. Calm down, breath in and out, and put the flame-throwers away. Yes, PostScript is obscure. Yes, it's not a prepositional language (i.e. modifier before object, as in English), like Pascal or Basic. It's not even remotely "English-like". Yes, it's not a functional language, like C or nearly everything else. Yes, it's not object-oriented. Yes, it's not a fasionable language or one that will prepare kids for "the real world". There isn't even a bleeping "For Dummies" book for PostScript. Et cetera, and so on and so forth. Blah blah blah.

But PostScript does have a lot going for it, due in part to its wierdness:

• It's freely available and portable. Download Ghostscript and a viewer, and you're done. You can even use Adobe Distiller, if you already have it. (It's simple: type out an ASCII EPS in any editor, save the file as .eps or .ps, and drag-and-drop the text file onto Distiller. The interpretation will scroll by in the Distiller window and you'll get a PDF if your code is correct.)
• You can download COMPLETE documentation that is well-written and loaded with code examples from Adobe and a few other places on the web. The Adobe books are named by color: the Red book, the Blue book, the Green book. Google for "Thinking in PostScript".
• Postscript creates output kids can understand: pictures. You can do numeric results if you want, but basically the can program the computer to generate really cool pictures extremely easily.
• They can print the results. Send the completed EPS or PS to the printer, and your kids get a hard copy of the results. It difficult to convey how satisfying this really is until you've done it. Even on a crappy printer, PostScript output looks really, really good compared to the image on a monitor. You can put the output on your fridge.
• It's extensible. Add fonts, TIFF files, EPS files, or JPEG photos to a directory the interpreter can find, and kids can "call" them, like subroutines in a library. You could supply them with, say, JPEGs of their favorite cartoon character or rock star (What's the difference? Eh, Barney?) and they could write a program to make a montage, or a kalediescope, or an escher-like pattern from the photo(s).
• It's interactive, if you get ghostscript. I think edit-save-compile-run-debug-repeat style IDEs are a little bit much for beginners. You want to remove all upfront obstacles to their playing with the language. With an interactive language, you can type code from the prompt and see what happens right away. That's what was so easy about BASIC on PCs from the 80s. The computers were so crude back then, most didn't have the free memory to support a modern IDE with seperate editor, interpreter, compiler, and debugger. It all had to fit in ROM.
• PostScript is standardized. There are well-thought out, detailed specs for the language that have very reliable, nearly bug-free implementations. One non-obvious advantage of this is that code examples in PostScript from almost any book will work on your setup. Compare that to BASIC or (shudder) AppleScript, where it depends entirely on the version you have how much work will be required to rewrite the code sample into working code.
• It's a real world language. Most printers, copiers, pre-press equipment and software, and all PDFs use PostScript for their inner logic. You can read the newspaper or a magazine together and look for fonts, rules, ligatures, transformations, and em-dashes.

Printing and publishing are great "nerdy" hobbies for kids. I used to help my parents collate the books they wrote, photocopy hand-drawn illustrations on to the dot-matrix print-out from our Apple IIe, and trouble-shoot Apple Writer II and the printer. It turned out those skills (as prerequisites) ne

Feedback and Showing Off

[eddy the lip]

Interesting that this question comes up now, as I'm just starting to teach programming to a 12 year old.

One of the first things that I worried about was what language to use. After some thought, I decided that as long as a few guidelines were followed in language choice, it didn't really matter. The most important things were:

• rapid feedback. Children are remarkably curious (at least based on a few flammable experiments in my parent's basement), but they also like instant feedback. They need to see results, or they'll lose interest.
• give them something they can show off. Being able to go to their friends and say "look at the cool thing I did" is great incentive.
• avoid theory like the plague. "|| is logical OR and does this..." is boring. "if($friend == 'tracy' || $friend == 'brent') { print "bugger off!"; }" is fun. And better than "hello, world."
• simple environment. They're learning a language and a new way of thinking already, no need to make them learn some complex IDE as well.

Language considerations came from that:

• "rapid feedback" and "simple environment" meant a scripting language (no compile step), and a text editor. A side benefit of this was portability. I can teach on my linux box or her windows machine.
• "showing off" meant something web based. She already knows HTML and maintains more websites than I can count, and a lot of her friends are online. She linked her first lesson from her homepage, so this seemed to be a good decision.
• ability to use a subset of the language. I wanted to jump into making stuff right away, rather than spending three lessons getting up to speed on language requirements.

This all translated into a text editor, PHP and assignments uploaded to her site. I seriously considered Perl and Python (especially Python - as it turns out that would have been very handy for teaching proper style. The concept of whitespace and proper indenting is surprisingly difficult to instill ;) ). PHP isn't my favorite language for a lot of reasons, but it's fine for teaching control flow, logic, data structures, modularity. It was handily available on her server, and meant she could show her work to her web friends right away. Python might be better in a classroom situation, because there's a pool of people with a similar environment that work can be shown to.

At any rate, we're only three lessons in, so this is still in the expermintal stages. But if you're interested in swapping experiences, reply to this and I'll leave an email address.

Re:Kids pick this stuff up automatically.

[wackybrit]

Just incase it sounded like I was blowing my own trumpet in the parent post, I wanted to point out that I haven't become some sort of master coder simply because I started early.

Infact, I've met coders with just a few years' experience who can kick my ass. Despite the early grounding, it appears I turned into a generalist rather than a specialist. Perhaps this proves that nurture is not everything..