This is a much less useful answer than I wanted it to be, but I'm posting it in case it helps someone.
I'm not a teacher, but I've found that most 13-year-olds can learn to program using production languages (Python's a good one). However, I'll regale what I remember of my experience learning my first programming language. (WARNING: Tangents ahead.)
On a Windows 98 SE1, aged five or six2 I was trying to open All Of The Things™ to see what would happen. I happened to right click
autoexec.bat, and there was an option called "Edit"... which opened up Notepad! When I double-clicked it, it popped up a message saying that I "couldn't run Windows when Windows was already running" but when I pressed "Edit", there it was! Code that I could read!
It wasn't long3 before I realised that you just needed the
.BAT extension. All of the programs I'd written looked like this:
echo This is a secret message.
echo Press a key
pause > NUL
Because I'd never seen any examples of a batch file other than these examples, I didn't know that you could run arbitrary programs from Batch files. I did know that you could run
command /?, so when I found another batch file with an
IF command in it, my programs evolved to:
echo Secret Message!
if exist secret.txt type secret.txt
if exist secret.txt pause
if exist secret.txt exit
if not exist secret.txt echo Enter your secret message > secret.txt
Crude, I know, but I didn't know about the web back then. (In fact, I thought Ethernet was the modern version of "Internet" (a modem port) and used neither, save as a magical device that brought back flash games when the browser crashed or I accidentally hit F5.)
I also discovered that Windows popped up a scary warning message about system instability when I renamed the
.bat file to
.com and tried to run it. I always wanted to make a proper executable program.
I later learned Scratch 1.4 on a Windows XP machine (aged 6 or 7), though I was thrilled to bits when I discovered that XP supported Batch Files too.4 Scratch didn't let me make .EXE files, but that didn't really matter because I could make proper games and had all of the blocks available to me. (Now I have "documentation", where I can find new blocks, but I didn't know about that at the time.)
1: a parental discard (as with every laptop up to my very first (which I recently fixed up (read: replaced non-functioning Windows with functioning Debian) and am currently typing this answer on)) which, if I remember correctly, was reinstalled twice after it became completely unusable (MS Paint scribbles were painstakingly preserved via floppies).
2: perhaps around the time I discovered the File Associations dialog and was disappointed that I couldn't make a
.wizzwizzfile type that was a valid WAV, TXT and BMP file (an idea I got from my open-everything-in-Notepad phase, which lead to the destruction of Microsoft Paint and many, many tears before it was recopied from the installation disk)
3: at 30 minutes a day, maximum; permission had to be sought every time I wanted to use a laptop
4: I remember noticing that XP supported multi-line
IF, but 98 didn't; my only emotion was annoyance, and only very minor excitement at discovering the annoying workaround and manually porting the programs back by duplicating the
How is this relevant? Well, it tells us a few things about how young children can learn programming:
- The child needs to be curious. Don't just sit them down and start talking at them. Don't just show them a flashy animation or a neat game and say "You can make one of these!"; they need to have questions. If they're not interested in figuring it out, they're not interested.
I recommend asking a parent / young-child-teacher how to get a child interested in something.
- The child needs to have something to tinker with. For me, it was Windows 98; as a DOS-based system there was an accessible, interesting "puzzle", but as a Windows system there was a nice friendly GUI that wasn't easy to break.
I still have a deep-rooted fear of white-on-blue monospace jumpscares and system beeps, so I'd recommend giving the children something that, when it fails, uses no new UI elements (no persistent red bold text, no popups with a yellow warning sign, etc.). If possible, it should keep on trucking. My recommendation would be Debian with LXDE, with a short GRUB timer, without wireless web access, for the following reasons:
- YouTube is very good at distracting without educational value. You don't want the child to discover YouTube. Even the most banal flash games have more educational value than endless novelty, since they can provide inspiration. YouTube stifles boredom, so stifles curiosity. The computer shouldn't become a YouTube machine.
- Manuals can be downloaded. The only thing that can't be downloaded is Stack Overflow, but they're too young for that anyway; you need to be able to distinguish between good and bad answers to use SO, and SO assumes a minimum amount of knowledge.
man manuals are the right sort of difficulty, I think, since they're as easy to understand as their topic, but boring enough that they aren't your first port of call (you try to figure it out yourself first).
- GRUB shouldn't be discovered early. GRUB should be part of the pretty pictures that show up while the computer is booting (after the manufacturer logo and before the scrolling text), but it shouldn't hang around for 5 seconds. 5 seconds is long enough for a child to get bored, mash some keys, and the computer to not start up. But eventually the child will get curious about what those pretty pictures are, and mash some keys.
- Debian is mostly stable. It doesn't BSOD when you do strange things, and even if your keyboard-mashing happens to be a valid ELF file and you set the executable flag and run it, you're not going to overwrite the kernel or trigger a system crash (just the humble segfault).
- Most things are text files. In Windows, if you manage to crack the shell-level dereferencing of
.lnk files (not
.Ink files) and open one directly in Notepad, you'll see a binary file with
T e x t t h a t l o o k s l i k e t h i s that you can't edit easily because those "spaces" are actually null bytes; in Debian, if you "right-click -> Add to desktop" a program, you'll get a text file (INI, iirc) that you can tinker with.
- Debian's used in real life. The only other OS (family) that I know of that matches enough of the criteria is DOS-based Windows, but almost nobody uses that any more (so its knowledge, while still serving me well multiple times a week, is a lot less useful) and its warning messages are scary. Debian's are scary too, but not quite as scary and only when you've used
sudo to mess something up. Which brings me to the next point:
- Non-elevated users can still do loads, without permanently breaking much. Liberal use of read-only Python scripts with the set-uid flag set can extend this further.
- Lots of Debian's written in scripts. Mostly Python or Sh, which are both good to learn and relatively easy to fiddle around in because they're text files. Showing the child IDLE will keep them occupied for hours. Make sure to show them
- You can access all of the code. Simply press Up in pcmanfm a few times and you're in the root directory!
- Source code is available. It'd be a good learning experience to be taught about compilers and go "Ooooh, that's what the
programname.c files were!" (since the child will probably try, and fail, to run these files bearing similar names to runnable programs).
- Almost all programs accept
--help. While it's not as easy to discover as DOS's
/? (perhaps a reason to favour DOS), if a child is told about
--help they can work out how to use pretty much anything. Same with
- You can set up backups with
cron. Backups. Backups a thousand times. You do not want a sad child who has just erased everything they can write to by trying out
rm -rf / --no-preserve-root (or, at least, you don't want them to be sad for any longer than necessary to learn that lesson early, which in my experience is about 5 seconds). I recommend making backups to a remote machine every 10 minutes, and using
tar's incremental backups feature to ensure that every version is saved.
Note that I didn't say "make sure they can't delete all their files"; nothing should be off-limits. Plymouth shouldn't even run on startup, nor should the OS boot into
startx immediately (though for a very young child you might want it to).
- A teacher who knows everything and can be asked questions is useful. I would've liked this a lot. Unfortunately, no such teacher exists... but is that such a bad thing? You can show them how to find stuff out for themselves, if they're old enough! I tend to use DuckDuckGo, since it doesn't constantly advertise Chrome and YouTube at you in deceptive popups at the side. The child can ask to look something up, plug in the Ethernet cable (located elsewhere; hence the laptop), find the documentation page and unplug it again; if they get to the point where they need to look stuff up frequently (the Stack Overflow point) you can start teaching them like an adult. Until then, answer all their questions, and when they ask a big one you can teach it to them. Be interested in what they're doing, but don't give unsolicited lectures ("Do you want to know about X / how to do Y?" is good, but "X does blah blah blah" is not).
- Code should have immediate effects. When you run the program, something should happen. Scratch is good for this, but a diet of Scratch and nothing else is not as effective as it should be. You want to train a polyglot.
- A tutorial that uses good style, or no tutorial at all. I've used tutorials with good style and bad style, and learned languages without any tutorials (just a few example programs) and it's pretty tricky to unlearn bad style. You can get good style by osmosis, but that's much easier when you've got good style in the first place. I'm not sure where I learned the importance of style, so you'll have to figure that one out yourself.
- Age: 2
Use ScratchJr or similar. It has pretty buttons and you can make things move, and it gets you interested in programming.
- Age: 4
Use MIT Scratch (offline), and have an OS that can be pulled apart. Lots of the things that are done won't be directly programming-related (e.g. spending 20 minutes completely destroying the UI) but it's all learning things that you probably take for granted that you know (e.g. that multiple things can use the same value for font colour, or that pink and green are lovely colours for window titlebars). Have Python available.
- Age: whenever they seem ready
- Start to teach them "grown up" programming languages. Don't say something like "Scratch isn't a real programming language"; that's disheartening and false.
- Introduce them to the Scratch website; it's a good programming community.
- Start introducing more abstract programming techniques.
- Once they've reached the "minimum knowledge" in both a single "grown up" programming language and in programming in general, show them Stack Overflow, the Font Of All Knowledge™. (Perhaps also Wikipedia, the Font Of All Knowledge™, but only if you don't mind them being very distracted for a few months.)