Programming Education, Then and Now

I have a girlfriend. She has three daughters. Her eldest daughter is twelve years old, and is peripherally interested in computer programming. Like a lot of kids her age now, she quite likes the idea of programming games, but doesn’t really know what she’s in for. The girlfriend and I have tried explaining it to her, but it’s hard to tell if the information is getting through; any mention of having to undertake anything that requires effort tends to make her lose interest faster than you can say YouTube. But I digress.

The soon-to-be-grumpy-teenage-creature is being taught programming at her school. That alone is intriguing to me, because when I was her age my computer-related lessons were dubbed “ICT” (Information & Computer Technology, if you don’t know) and were mostly not interesting. There certainly wasn’t any programming involved in the curriculum, but myself and a couple of equally geeky individuals did get informal tuition in Pascal and Visual Basic from our teacher during lunchtimes, which was nice. (It was very informal; mostly he sat with us, chatted about it, showed us some code, and let us explore. There were no learning materials handed out or anything like that.) The brunt of the ICT curriculum was geared toward teaching us how to use Microsoft Office, as well as basic computer tasks, and there was some lower-level information thrown in for good measure. (I distinctly remember the size of floppy disks being drilled into us ready for the upcoming GCSE. I’m pretty sure they were already obsolete by the time I finished school and went to college.) Basically, you were just about taught enough to get you through the ECDL, although the existence of that wasn’t revealed to us until we got to college.

From what I can gather, grumpy-teenage-creature is being taught Small Basic (never heard of it, but BASIC is BASIC) and is heading toward being taught Python. She’s picking it up very well–she’s a bright kid, but has the problem a lot of bright kids seem to have: apathy. But that’s not why I’m writing this blog post. No, the spark that started this verbal (textual?) diarrhoea is that she showed me her homework the other evening, and she’s learning about recursion and fractals. Recursion. And fractals.

I found myself surprised at this, but I’m not sure why, to be honest. I know she’s smart enough to understand it (and I doubt I was when I was her age) but it just seems like a big leap. Maybe because recursion is generally taught later in programming courses, if it’s taught at all. Usually it’s touched upon or mentioned in passing, then brushed under the rug and forgotten about. Even when I was in university, the programming lecturers seemed eager to glide past recursion and get it over with, and there is one obvious reason why that might have been the case. I’ll leave that as an exercise for the reader, but it brings me to my next point quite nicely: grumpy-teenage-creature is already a more capable programmer than most of the people I went to university with.

I’m not being hyperbolic. Sure, she needs refining, and it would be a lot easier to do that if she would actually put some effort into learning outside of school hours, but the potential is there. Things I would explain to my university colleagues in exchange for blank stares and vague grumblings of acknowledgement get soaked up and understood by her amazingly quickly.

So I’ve been mulling this over for the last few days. I’m not sure if it’s just that schools are pushing programming on kids these days coupled with the fact that kids’ brains are information sponges, or what. I know the last few paragraphs made me sound like a proud non-parent of a genius child, but I don’t think that’s it. She’s smart, but more often than not says and does things that make me worry about her intelligence, but that’s common among kids, I suppose.

Do all kids learn programming this quickly and easily now? I don’t know, having no other kids to compare her to in her age group. It is true that programming is the hot new topic that’s getting forced down the throats of our offspring, and maybe it’s that simple. Maybe adults when I was twelve found it really hard to use Microsoft Office or computers in general, and I looked like a semi-genius freak to them? That sounds more likely.

I would have relished programming classes when I was her age. I didn’t really get into it until I was thirteen, but I had a keen interest in the concept and computing in general at twelve. Perhaps I would’ve found topics like recursion and fractals easier to digest with my young sponge-brain?

Oh yes, fractals. I think it’s a good idea to be teaching kids something of that nature along with programming. (The homework I mentioned earlier basically involved explaining what recursion is, what a fractal is, and how they are related.) It isn’t something that is immediately obviously useful to a budding programmer; it seems more theoretical than useful, but is an interesting thing to think about and implement, and I guess it gets kids used to thinking more abstractly and outside the box, which can only be a good thing.

People tend to be divided on whether or not it’s a good idea to be forcing kids to learn at least some programming. In general terms, I think it’s good for developing logical thinking and problem solving skills, but I don’t believe that everybody is a good programmer just waiting to be educated and pushed in the right direction. Like any skill, to reach even intermediate levels of capability you really need to devote a lot of time to it, which itself requires that you have some kind of primal, innate interest in it. I’ve written before that programming is hugely satisfying for me on a base level, and I believe that it takes a certain amount of this raw passion for a person to remain interested in learning any skill to a decent proficiency.

I believe that the kids who do possess this strange passion for programming may very well be excellent programmers in the future, certainly more proficient than most people (read: adults) who pick it up now. I’m witnessing an increasing trend on related online forums of people my age (or only slightly younger) asking how they can best start learning to program in order to get one of those abundant high-paying programming jobs they’ve heard so much about. Assuming even half of the people who ask every day actually stick with it (and I think half is a very generous estimate here), that’s a whole lot of people who don’t really know what they’re doing, aiming for a career they can’t really handle. We’ve all heard horror stories of programmers who copy and paste code from Google on the job, right?

This is rapidly flying off on a tangent; perhaps I’ll write more about this in a separate post. I’m not even sure what my point was in that last paragraph, it just kinda got away from me, but that’s typical for me.

Anyway, this post didn’t really have an overarching point, which is making it hard to wrap up. It’s just some words about stuff. Feel free to leave your thoughts in comment form.


Returning Usable Values in C

I program in C a lot. Like, 90% of the code I write is C code. The main reason for this is that I’m stuck in my ways; C was the first language I learned after getting hooked on programming with Visual Basic 6. Additionally, it is for several reasons (which I might outline one day) my favourite programming language, and is certainly the one I know best.

One of the major considerations when writing any non-trivial program in C is how you plan on returning error codes from functions. How does code calling the functions you write know whether or not your function succeeded?

There are multiple traditionally-used approaches to this problem, but I try to follow two simple rules when writing functions:

  1. If the function is a predicate, name it as such (e.g. player_exists()) and have it return boolean true or false.
  2. If the function is a command, for example do_work(), and it doesn’t return a usable value to its callers, then have it return zero on success and minus one on failure, as is typical in C. If it does need to return a usable value which is a pointer, then I return NULL on error. If it needs to return a non-pointer value, then I return a retval_t.

What the heck is a retval_t? It’s similar to the optional<T> from the C++ Boost library, and Haskell’s Maybe. It’s a simple two-element structure containing a void pointer and a boolean value, like so:

struct retval_t {
void *data;
int valid;

(Note: I don’t actually write code without indentations. I just don’t know enough HTML / CSS to get tabs in there and don’t care enough to learn how to do it properly right now.)

I had considered making the data a tagged union, and I could have some macros to make declaring the things a little less of a chore, but I decided against it. (I always try to err on the side of minimalism until it’s proven that something more complicated is required.)

It seems like too much messing about at first glance, and a fair number of you are probably wondering why I don’t just use C++ and Boost. In practice it’s not so bad, because you don’t need to return usable non-pointer values that often. As for C++… No. I will probably end up writing a rant about this in the future, but… just no.

I really do enjoy writing things “properly” in C. Well I do in any language, but especially in C. Proper error checking and handling, judicious memory management, the lot. Probably because I just enjoy firing up valgrind on a basic, nerdy level. The same way I just enjoy programming on a basic, nerdy level. It stirs up something primal within me, even if I’m using a language and styles considered “antiquated” or “no longer relevant”. I have occasionally been guilty of using C where a different, higher-level language would have sufficed, but I don’t care. It’s fun.

Anyway, with a retval_t we can write code like this:

// ...
retval_t r = some_function();
if (r.valid) {
// use ...
} else {
// panic, abort, log error, etc.

Which I quite like. It saves having to remember or look up what some_function() returns when something has gone wrong, and if it’s returning a usable non-pointer value then it really could be anything. Some out of bounds value, usually, but in C there is no universal out of bounds value, it depends on the type involved. (NULL is the only obvious exception, hence my rule regarding it.)

So like it or dislike it, this is one of the ways I (ab)use the C language. More to follow.

(Closing comment: I actually dislike the name retval_t. Plenty of people think the something-underscore-t naming convention is disgusting and should be taken out the back and shot, but I’m not talking about that. I just think “retval” is a stupid name for it. I mean yes, it is a return value, but still. I originally called it maybe_t but that annoyed me because I felt I would have had to use a tagged union in that case, so it didn’t make sense. “Optional” makes even less sense to me. Any suggestions?)