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?)

On LÖVE, and Other Things

I’ve been spending some time using LÖVE lately, much to the disgust of my long-term game programming friend, SDL. (Well, C + SDL + etc.) I’ve found it pleasingly straightforward to use, so I decided to write about it here.

I first heard about it last year, although I can’t remember how. (I probably just googled something along the lines of “Lua game programming” and stumbled across it.) Despite downloading and playing with it for a day or so, I didn’t really use it until now, which I’m kicking myself for. It really is excellent.

Basically, for the uninitiated, making games is hard. Very hard. I’m not even talking about “triple-A” (AAA? AAA!) games here; even a project on the scale of an indie game is a massive amount of work. Nobody seems to realise this. Allow me to illustrate this point with a short story.

When I was a wide-eyed teenager, with heart set on making video games for a living, I undertook the games development course at my local university. Unsurprisingly, this course was packed. Wall to wall with like-minded individuals who “just wanna make awesome games, boyo!” (I was in Wales.) There was easily forty fresh-faced students in there, possibly closer to fifty. There wasn’t enough seats to go around and at the time I remember wondering how this was ever going to work when we got into the computer labs, which are always smaller than the lecture rooms. My question was soon answered. After two weeks, barely twenty of us were left. Nearly that number made it through the first year, and by the end of the second, less than ten remained.

I don’t know how many people went on to complete the course, because I dropped out. (I then went on to drop out of uni a second time, but that’s a story for another day.)

Making games is hard. Part of this misunderstanding is probably the fault of the universities. At least in this country, they market these game development courses as if “it’s all fun and games”, in other words, not difficult and you’ll definitely get a job at the end of it and everything will be lovely forever. In reality, if you don’t already have a programming background you are monstrously unlikely to succeed. I’m not saying it’s impossible, but learning to program and starting with programming games, while fun, is like learning to swim while competing in the Olympics. Then you find that acquiring a job in this industry is something of a game in itself. It depends on where you live, to an extent, but if you’re not willing to relocate then you’re going to have a bad time. If you do find a job, and actually enjoy working in the environment (which will be quite a surprise because SURPRISE! They lied to you / failed to tell you just what it’s really like) then you’ll be circulated around every eighteen months to two years anyway. Job security? What’s that?

I know what you’re thinking. “You’re a filthy drop-out so what would you know about the games industry?” etc. That’s fair enough, but I can still read and talk to people who didn’t drop out and ended up working in the industry, and they all say pretty much the same thing: I didn’t miss anything. But that’s me personally; some people thrive in environments like that. Clearly I don’t, or I wouldn’t be a filthy double drop-out.

Anyway, what was I talking about? Oh yeah, LOVE. (I can’t be bothered to type the Ö every time, so let’s pretend it doesn’t exist.) LOVE is great. It makes the usually laborious process of creating a game slightly less laborious. Which is great. You can throw something together very quickly, and what’s more, distributing your final creation is crazy simple. Distributing a game written in C/C++ with SDL can be a nightmare, a nightmare which I’ll no doubt write about soon because I’m working on something. As usual.

It has everything you need to make anything, as long as it’s 2D, which is hardly a limitation. (Another topic to write about someday soon.) Just check out its documentation.

So this is my first post. I had intended to flesh it out with some code examples but instead I ended up flying off on a tangent and ranting about something which I really have no right to rant about. I suppose that sums up my writing style (and myself) in general. On the plus side, it gave me ideas of topics to write about in the near future, and that’s the main struggle when maintaining a blog really.