I think I just had a sports dad moment. This has always seemed a little alien to me: in the movies there’s always the middle aged dad who still remembers his glory days in high school and relives them vicariously through his children. I didn’t have glory days in high school, I had misery. Oh, there was fun, too, but the fantasy of going back in time and reliving high school holds negative attraction for me. I would pay money not to have to do it.
And yet, there we were. Badb was doing her math homework and I was helping her understand it and we got to the last problem: “Write down all the prime numbers less than 100.” I explained to her how to use pencil and paper to perform the sieve of Eratosthenes and she got started. The first problem was that in generating the list, she skipped a few numbers. I think maybe she got bored with the task and started thinking ahead of where the pencil was writing.
I told this story to Junglemonkey and she said I should try teaching Badb to program. Programming, after all, is all about attention to detail and planning, and it would really help the kid exercise mental discipline. I thought about it and I’m really unhappy with modern computers and programming languages. All the flashy, blinking, beeping, Internet-connected whiz-bang features combined with the really loose requirements for data typing, control flow, variable declaration, and so forth that you get with modern scripting languages really gets you a recipe for frustration. She hasn’t, up to this point, demonstrated any curiosity around programming. I figured it was something like, “Dad’s doing it so therefore it must not be cool,” but seriously, a little kid doesn’t care about object oriented highly scalable enterprise middleware; she just wants to solve this problem on her math homework.
- Line numbers. Having to go renumber your program by hand (and make sure that you’ve updated all the GOTO and GOSUB line references) is a major pain in the neck. Once you do that, you learn to leave yourself lots of room for future work. To an observer this might look like “planning ahead” but that’s too specific. One doesn’t know necessarily what changes one will make, nor where, nor even if one will make them. But learning to leave oneself the option…that’s a really valuable lesson.
- Barely functional programming paradigm. Sure, you can declare subroutines, but it’s really all just labels and line numbers with no parameters. One needs to cultivate some ability to hold the whole set of instructions in mind at once. With no encapsulation, she’ll have to be able to remember what that variable means and which sections of code modify it.
- Really primitive I/O. This is killer. She won’t get distracted from her dimensional analysis by trying to make the units feed in from some website and play an entertaining video when the answer’s spat out.
- Cryptic error messages. Not, “Exception processing token <sieve> on line 2,” but merely, “Syntax error,” or perhaps, “Invalid character.” It’s like one of those I, Spy puzzles but instead of looking for a nail, a 4, and two butterflies you’re looking for the instruction that the computer can’t understand. You get really good at proofreading.
I love this idea. From now on, her math will be less and less about mastering basic operations and memorizing multiplication facts and become more and more about understanding and exploring relationships between numbers. Programming can totally help with that.