In the first part of this series I looked at the Raspberry Pi -- a $25 computer which is being developed to remove one barrier to encouraging the next generation of programmers. It's ambitious and commendable but on its own it may not be enough. The choice of software for such a project is important and as important is the implementation of that software.
Encouraging the next generation of hackers
This is part two of a series looking at encouraging the next generation of hackers and how free software is being or can be used for this.
As I said in the previous part the hardware/price combination of the Raspberry Pi is commendable. What worries me though is that hardware alone will not get children programming. Accessibility to hardware is an important barrier to remove and this project should be commended for that. But -- and I know this will make me sound old -- what got me and I suspect others my age into programming was not just the hardware but the software and its implementation. With a ZX-81, Spectrum, BBC Micro, Acorn, C64 you got a very important prompt when you switched it on. It was only a flashing cursor but it was calling for you to type something.
The programming/hacking culture grew up with computer clubs and magazines printing source code
The programming/hacking culture grew up with computer clubs and magazines printing source code often sent in by readers (imagine that: people sharing code in public media). Users -- who were mostly kids -- would type this in to create a simple game or similar and then fiddle with it. What was important -- for me anyway -- was the sense of achievement when you ran a program you had just typed in. Without realising it I learned about code structure and techniques while I was typing it in.
There was a further sense of achievement (and associated learning) when I deliberately broke the code and fixed it to do something else. Believe it or not this was fun, this grew into -- or at least joined -- the hacking culture from which sprang so many ideas for Free Software. Code and process of creating it became the goal of the users not the program. I lose track of how often I spent nights hacking to create a workable clone of Pac-Man or Space Invaders and then ripped it apart to make it better or scrapped it and moved onto something else. I may be alone in that but I suspect not.
So what changed? Why did the playground hacking culture stop? Eben Upton touched on it when he remarked at the usage of the computer at home changed (see quote in first part of this series) but in the context of programming I think the key change was in the interface we users were presented with. A games console has little interactive input opportunity. Oh the manufacturers tell us their one does but they don't, not in a way that encourages programming anyway. The family computer offers greater opportunity but it's hidden among a host of icons, sounds and graphics. Had the ZX-81 or the spectrum presented a GUI upon booting like the Amiga 500 I got later, then I am sure I would not have discovered programming at all.
If projects like Raspberry Pi want to encourage kids to program then they are going to have to ensure the software offers the same encouragement as those home computers of the early 1980s
As I said the flashing cursor invited us to code, it tempted us and if projects like Raspberry Pi want to encourage the kids who receive their products to program then they are going to have to ensure the software offers the same encouragement. I'm not convinced it will be enough to install a cut-down desktop system and give them a mouse. There's no indication that this is Raspberry Pi's plan by the way but it does strike me that the standard procedure when creating computers these days is to slap a standard GUI on it and ship it. I've no objection to the GUI but I think it's important that the experience of a computer designed to encourage coding offers the 21st century equivalent of those flashing cursors.
In a series of television programmes called "Electric Dreams" the BBC took a 21st century family and put them into the environment they would have been in in the 1970s, 80s and 90s. In particular this included giving them only the technology that would have been available at the time. Each "decade" of the experiment lasted for a week and the experiment included things like reducing the number of TV channels and switching off the electricity to simulate power-cuts in the 1970s. As part of the 1980s week the family were given the option to choose a home computer. They were given the option of a Sinclair ZX Spectrum or a BBC Micro B and to help them they were given advice by two "experts".
Rather annoyingly for me as a former Spectrum user the "expert" advice they received suggested the Spectrum was the gamer's choice and the BBC was the choice for programmers. The family -- mostly driven by the children's preference -- chose the BBC Micro -- the 'programmers choice'. Upon getting it home and hooking it up to the TV the excited boy of the family grabbed the manual, typed in and ran the example "Hello World!" program. His excitement grew when he started to adapt the colours used and the spacing and case of the text. Here was a 21st century 10 year old excited about coding in BBC BASIC on a 1980s computer. This was even more evident when he did what I did at his age and invited mates round to join in. Kids are creative and inquisitive, they like to experiment and push boundaries. Programming is a creative science -- some would say an art -- and it not only permits but encourages inquisitiveness and experimentation.
Unlike the mutt from the Bizarre Cathedral, I am not a grumpy old hacker who hates the GUI. I think graphics are important when learning to code. Visual and audio feedback is important when you learn to code. Being able to change a few lines of code, run the program and see the size of the window change would I imagine be as encouraging as when I first changed a maze by fiddling with the ASCII codes. So having a GUI would help but having a real time programming environment autostart on boot could be more important. The particular language and environment is also important and I'll talk about that in the next part of this series but as important is encouraging code sharing and good old fashioned hacking. Sample code, code sharing hubs and the like are all key to encouraging hacking. If something is to teach, it has to fan the sparks of kids' natural inquisitiveness. I cannot be alone in that what encourages me to code is seeing what somebody else has done and wanting to know how they did it. It's one of the reasons I got into web-development because with a browser you can view the page source and dig around.
Having a GUI would help but having a real time programming environment autostart on boot could be more important
So -- getting back to the Raspberry Pi and its ilk again -- while I applaud moves to remove a key barrier in getting kids into programming it should only be part of the solution. The right hardware has to be accompanied not only by the right software and language but also the right implementation of them so that hacking is one of the key activities that occurs to the user. I'm not saying kids should only or even primarily code as part of their life but if a device is being developed or at least targeted at getting them into programming then hacking should be the primary activity it encourages.
Having said all that I am sure the people behind Raspberry Pi have considered all this because they are those kinds of people. This is backed up by the fact that of them is a legend of 80s programming: David Braben. What do you mean you haven't heard of him? Honestly kids today -- don't know they're born!
This work (excluding the figures) may be distributed under the terms of the Creative Commons Attribution-ShareAlike License, version 3.0, with attribution to "Ryan Cartwright, first published in Free Software Magazine".