The FIGnition/Raspberry PI Challenge!

Hi folks,

I managed to meet up with a fellow embedded techie friend at my old church last Sunday and he mentioned he’d been chatting with some friends about whether my FIGnition project stands much of a chance against Raspberry PI, so I thought I’d blog my response.

Although I’m persuaded that there should be room in the market for both of us, of course it’s perfectly true that the publicity of Raspberry PI has presented a major challenge as both it and FIGnition are being sold as machines to encourage children to program. However, my conclusion is that kids don’t program today primarily because modern computers (like the Raspberry PI) are 10,000 times more complex than in the 80s. I blogged about this more fully a while ago.

FIGnition is as simple as an old 80s computer, but suffers from some practical dis-incentives. The keypad is unconventional, requires learning and is slow (though better than texting); getting code in and out of FIGnition is still awkward and Forth isn’t an ideal language for beginners. I don’t plan to change the keypad, but at some point, FIGnition owners will have created a PS/2 shield for FIGnition. I want the keypad as it is because I don’t want to be dependent on an artificial protocol for reading keys, that is, I’d probably have used a switch-matrix membrane if I could have sourced one cheaply, but my primary goal was to have a machine that was as self-contained as possible. I’m working on the uploading/downloading issue by enabling audio saving and loading, which is still being debugged. I’m not absolutely committed to Forth though I personally enjoy the language, instead I’m committed to comparable 8-bitter user code performance (because otherwise I can’t say that FIGnition is a substitute for an 80s 8-bit computer), and that with my original development schedule meant that Forth was the natural choice. Nevertheless I’m working on making it easier to use, starting with a new editor once the audio I/O is ready.

At the heart of it though I think FIGnition is the right kind of machine, because it can be understood whereas Raspberry PI can’t be understood by a single person. This is why I think FIGnition is worthwhile. Because Raspberry PI is a full machine its very complexity leads to the same mentality and solutions as for other modern machines. You can either give it a dumbed-down language and programming environment which teaches you less about programming than a ZX81; or you give it an emulated 80s computer (which is to admit the host computer isn’t the right tool for the job); or you program it with modern tools and put up with the same complexity that turned kids of programming in the first place.

Let’s extrapolate what’s going to happen with the Raspberry PI. Raspberry PI is a full Linux system, so you can recompile thousands of programs, tools and games so I strongly suspect kids will find it easier just to run pre-written programs and games than do actual programming (note MAME was ported to the PI before its general availability). Kids will simply stuff their own SD cards in the PIs and do what’s easiest. It’s an unavoidable effect of the complexity of the system which makes it overwhelmingly easier to go with that flow.

Consider what happens when a child makes an effort to resist. Let’s say they learn Python and want to write a game, e.g. Snake or Blitz. Python’s fine for scripting text processing stuff, but even doing something as simple as the equivalent of a Spectrum’s PRINT AT y,x; (or FIGnition’s x y at) requires substantial effort and at the end you don’t even get user-defined graphics, just plain characters. Scratch can’t really handle that complexity so they’re forced into developing a java or javascript game (with all the overheads) or developing on (e.g) a BBC Micro emulator. At this point the hurdles and disappointment will make it far more inviting to just start downloading and running other people’s stuff.

Let’s say educators or individual adults see the problem with the above so they develop an ‘easy’ programming environment alternative. The problem is that because of the underlying complexity of the system, developing this ‘easy’ environment becomes far more than a one-person job so it’s either left unfinished; or they short-cut and expose the underlying complexity for the ‘real’ stuff or they open-source it and the several(?) collaborators create a bloated composite of their partially overlapping variants of the idea.

Or let’s say they want to by-pass the Linux OS and re-write a classic BASIC (or something) kernel for the Raspberry-PI. What’ll happen is that the effort of developing a kernel from scratch means they’ll get outmaneuvered by programmers who take short-cuts that bolt something that looks like the classic environment onto the normal kernel. Then what’ll happen is that people will get frustrated by the way this dedicated Rasperry-PI programming kernel doesn’t interface with all the other full-desktop goodies (editors/scripts/games/drivers/protocols etc) that they’ll add a full Linux bootup in the background and then basically we’re back to square one.

A typical example is the BBC Micro 2.0 project. It looks like they’ve employed a number of 21st century programmers to create a ‘new’ programming environment. The idea is to have the ‘simplicity’ of BBC Micro programming, but hosted by a full Linux/Mac/Windows system with bindings for multiple languages and programming paradigms. So already it’s just the same multi-pane, monstrous class library, over-complex nonsense that put kids off programming in the first place; because the programmers and designers are immersed in modern environments and aren’t raising the key question about why kids don’t code today: that modern systems are 10,000 times more complex and can’t be genuinely understood - and their failure to understand how no-one understands modern systems forces them to replicate the problem on the new BBC Micro 2.0 platform.

But once you accept that the issue is the actual, literal complexity of modern systems, then the way to get kids to code becomes a case of constructing real, but genuinely simple computers. Computers like FIGnition. You can make use of genuinely new concepts, but it’s no longer a problem if these computers don’t do everything as long as they meet the criteria of being simple, complete, immediate and understandable. FIGnition isn’t perfect, but it gets the primary thing right: you can build it, code it and understand it. It is to complex computers what Phonics and the Gruffalo is to War and Peace and no-one would ever think of teaching kids to read and write using the latter.

In a future blog, I’ll argue why the issue isn’t cost, nor primarily ICT teaching, nor the inevitability of progress. These kinds of arguments are smokescreens for the only issue: computers are 10,000 times more complex than computers that can be learned and understood. I’ll finish with one comment about price: both FIGnition and R-PI are so cheap you could buy more than 10 of both for the adjusted cost of a ZX Spectrum from 1982 and millions of recesssion-hit, cash-strapped parents bought Spectrums and their ilk then. If journalists, parents and educators can’t afford or encourage a market big enough for both then our cultures and economic prospects must be so messed up the challenges I face in promoting FIGnition are the least of my problems :-)