A few years back I remember reading this article by David Brin suggesting that it is hard for children to learn programming nowadays, and how it ain't happening so much any more. It's something that I have been wondering about for some time now, and it's something that I think has to be important for the future.

Is there really a huge slowdown in the numbers of computing graduates coming out of University? Perhaps there is really nothing there to worry about. Maybe there are so many more computers around, that even with a smaller percentage of users becoming programmers there will continue to be enough programmers around.

It is something I do question. I have wondered how it is possible to get my own son interested in programming, not because I want to push him in that direction for a career, but because I think it will probably be a useful skill to go with the traditional three.

Some informal ways that I think do work in the current programming climate for various groups of people are:

• In-game programming
• Robotics kits
• Simple -> complex web pages
• Spreadsheets
• Databases

Spreadsheets can work for people who have complex numerical requirements, and who find their formulae getting increasingly complicated. It doesn't usually teach good habits and these people are probably better off being pointed towards Databases...

Databases are often good, because they can provide the ability to customise code in small snippets, while leaving the heavier lifting to more interactive tools. It's likely that someone with an aptitude for it will find themselves frustrated and eventually move on to other languages as they realise their strengths.

Simple web pages, where some programming is available (particularly server-side programming) can provide a good introduction, allowing people to 'smarten' their web pages, doing relatively simple things, and transitioning to complex functionality. Again a person with aptitude for this is likely to go further and do more.

Some games allow for simple programming of objects, and in some cases even depend on this for gameplay. One of the most durable games in our house has been "The Incredible Machine" which I remember playing in the early '90s. Our copy is a CD some friend gave to me which is so old it probably wouldn't run on Windows 7, but it mostly works fine under Wine on Linux. These beautiful 'Heath Robinson' constructions are very educational from the point of view of physics and logic and program flow. It seems to be good from about age 5 onwards, depending on the kids, and ours are still enjoying it at 9 & 12 - well I know I still enjoyed it at nearly 40, as well.

Robotics kits are an interesting one, and I think they lend themselves to solitary development much more than (e.g.) languages like Logo, which are designed to simulate them to some extent. It will be interesting to see how these pan out as the availability and quality of these kits increases.

Even before it does, though, there are some excellent opportunities for the budding roboticist to hone their skills in a virtual environment like Fantastic Contraption or IncrediBots. These fascinating games are just part of a modern genre of physics games.

Finally though, I do see my son starting to program beyond just constructing complex contraptions on the sites above. Thanks to Nat Torkington, since Software Freedom Day last weekend, , both of my sons have got heavily into Scratch. This has taught them quite a lot about programming, and interestingly it is teaching them programming where there are a seemingly infinite number of cores, and their earliest lessons highlight things like 'race conditions' that I never really encountered until the early '90s. Message passing and variable scoping come naturally.

What the kids are asking me for is something that combines IncrediBots and The Incredible Machine with Scratch. They love programming Scratch, but it has practically no physics model and they've played so many flash games that they're sophisticated about what happens when things fall, or are stressed to breaking point, but a sprite in Scratch doesn't even have a sensor that can tell how far away it is from a wall (except that special case wall that is the edge or another sprite).

There are no 'for all sprites' constructs either, so conditionals can get very large - and fragile if you are adding more sprites. Since it's graphical in layout the 'large' translates to a horizontal size that can become unreadable.

I'll be surprised if it lasts them long as a language.

I don't mean that the language won't last, I mean it doesn't cover the range of possibilities that it's practitioners want from it. When I first started writing in BASIC I did the standard '10 PRINT "Hello"; 20 GOTO 10' that everyone does, but once I'd mastered the language it had the flexibility to let me write RPG character generators and accounting systems. Maybe Scratch is Turing complete, but it is missing some efficient library mechanism to be useful for teaching real programming so that we don't have to cut and paste everything everywhere.

Max looked on the Scratch website yesterday and was frankly disappointed in the quality of the offerings there saying 'man, they can't even get gravity right' and 'my boss level is way better than these'. Now gravity isn't hard - Max's program does it by setting a vertical motion variable, then looping through "decrement vertical motion; vertical position -= vertical motion" for a surprisingly elegant expression of acceleration at work. The problem is that he can't code that into any kind of a 'make gravity apply to this sprite' unit - he has to cut and paste the whole script onto each sprite, which ends up massively cluttering the playing^Wcoding area. The camel spits, but the spit doesn't follow a gravitational path because it was too much effort to apply that.

Do we want to teach our kids to create an unmaintainable mess?

Real programming languages let you hide the complexity somewhere and bring it to the front when you need to work on it. It's quite possibly an essential characteristic for any complex tool to be usable, so as a result Scratch ends up being a toy. A complex toy, but it's still a toy - just what it starts out looking like. Without this kind of mechanism Max's scripts are going to end up looking like his bedroom, where he can't tell the clothes that need to be washed from the clothes that have been, and he ends up wasting effort washing everything!

Even more sadly, once you've figured it's a toy where are you going to move on to? There isn't really any natural progression that I can see. No real programming language that gives a greater separation between the programming area and the running area, or which lets you turn your carefully crafted scripts into common code libraries.

Ultimately, Scratch gives you enough of a taste that maybe it will be enough to push some people into more advanced progamming languages. It certainly provides some of the feel of programming, and when the practitioner encounters it's limitations maybe some of them will want that feeling again. Maybe enough to jump the abyss to Python, but they are unlikely to do that particular leap on their own.

I guess I'm going to be holding some hands across that chasm in the coming weeks. From what Max has managed to learn in a week of playing with Scratch I think that if he desires it he could be a good programmer, but he is an incredibly visual person and having to suddenly switch to a language where he has to type programs into a text editor is going to be hard for him.

David Brin bought his son an old Commodore 64, but I don't think that particular solution is going to work in this household, even if we do seemingly have someone who can draw a perfect flying elephant beautifully in a 12x12 pixel matrix - something which would exactly suit that era.