GamesIndustry.biz is proud to present the best writing from #AltDevBlogADay, a blog populated by game developers who write about the creation and business of games and related subjects.
Here, Dylan Cuthbert of Q Games discusses the best language to learn programming, his history with BASIC and why he thinks old machine code is a perfect fit for children.
There was some talk on twitter a few weeks back about "I want to teach my 10 year old to programme, what should I start him on?", and a number of people responded with common student-like answers such as "flash script", "java", "lua", "C", no! "C++", no! "C goddammit", etc etc, and I started to have a think about this problem in some detail.
First some history, I learnt to program in BASIC starting from the age of about 10 (1982), by copying in listings from magazines at a friend's house on a ZX Spectrum he had got from an uncle who worked in the Sinclair factory, no less. My friend and I would take turns copying in the text, with one of us reading it out while the other typed, and this is how I learnt to type relatively quickly. What is amusing is that because we were so young we didn't know the proper names for the various symbols in the code, for years afterwards I would still call quotations marks "those things" as a result. But anyway I digress, in many ways the old BASICs with line numbers and older forms of machine code were perfect languages for learning in and this is article is my attempt to explain why.
Abstract Thought is an Adult Skill
It's my view that for a child to be able to learn quickly to code he/she needs a language with the minimum amount of abstraction possible. Have a think about that for a bit. Abstract thought is a skill that gradually grows as you get older, but when you are a kid your brain is wired to take everything at face value; it's a survival instinct that helps you place complete trust in your parents and other adults and as you get older the opposite becomes a survival instinct and abstract thought develops (e.g. the concept that Father Christmas perhaps isn't really visiting you via the chimney every year). Anyone who has or deals with children knows that what you tell them is believed pretty much absolutely.
The old-school BASICS were imperative languages and fairly crap, but one important feature they had was a very low level of abstraction.
As an example, this means that even the relatively simple C concept of '**' meaning "pointer to a pointer" is hard to visualise for young children. They might eventually get to the meaning of it in their own terms but the more abstract concepts there are, the harder they will find it to move forwards, and if guided correctly to avoid these abstraction pitfalls children can move forward at a faster rate and learn much more. I really think the trick is to steer clear of the extraneous abstraction we, as adults, cope with so easily and take for granted.
The old-school BASICS with line numbers were imperative languages and fairly crap when compared to any other language, but one important feature they had was a very low level of abstraction. Any school kid can type 10 PRINT "HELLO MUM!" and then 20 GOTO 10 and understand exactly what it does – even my mum can understand! – the equivalent in (almost) any other language requires many, many abstract concepts.
To illustrate this, here is what it looks like in C, one of the "simplest" languages:
What's so hard about that you probably ask yourself? That should be a total doddle for a kid to learn! But let's take it step by step (actually, let's just take the first line!) and you'll understand why a child would have trouble, the questions would probably go something like this:
- 1. What's that funny # mark?
- 2. What is "include"
- 3. What is "stdio.h" and what are the funny arrow symbols for?
Just to begin with, those three questions require days of teaching and I leave the rest as an exercise for the reader (and it is an interesting exercise to sometimes remove the blindfolds caused by familiarity) but the list is long. Of course the standard adult answer to these "where do babies come from?" kinds of questions from children is something to divert the question or leave the explanation for a later date. But this is exactly what you don't want if you are trying to teach children. You don't want the child using concepts because they have been told to use them "because that's the way it is", you want them to use the concepts because they understand them.
"Let us praise machine code O'Lord, ooh you are so big, so absolutely huge. Gosh we're all really impressed down here, I can tell you. Forgive us O'machine code for this our dreadful toadying and barefaced flattery, but you are so strong and, well, just so... super." – Monty Python on machine code.
...is generally the opinion of people who haven't touched or worked with machine code to any extent. Machine code is seen as an untouchable omnipresent super-being that is better to simply be in awe of than to have to deal with it. For those of us who have made entire games on CPUs with only three registers, typing with our nose and both hands tied behind our backs (on a good day), well... it's as easy as pie (preferably a chocolate one as you will see later).