Re: Ask the Right Question
Hi Jess,
Thanks for your reply.
> > The Pi is an ARM based device, (ignoring the GPU, which is fair enough given the lack of
> > documentation :) ) it is not ridiculously more complex than a 1989 BBC A3000
It's true that ARM assembler on a R-PI isn't that different from ARM assembler on an A3000, but the problem is with the overall complexity of systems and its the overall complexity that impacts on both how programming is learned and how developers develop for the systems. So, the 10,000 figure isn't hyperbole, but the literal growth in complexity between the early 80s and now (e.g. 256Mb / 32Kb = 8192; 200million lines of code of Linux / 10K lines in the BBC's firmware => 20000 etc ) Let's start from the bottom to the top.
At the bottom we have the CPU. Modern CPUs are orders of magnitude complex than in the 80s and R-PI's CPU is actually a microcontroller in itself. So, just considering the effect of memory management and cache means that in a modern system kids can't just poke around the computer, you have to use APIs just to be able to get access to memory (if it's allowed) and reading and writing to it involves more complex protocols (i.e. because of cache coherency, write-back policies).
Booting a modern CPU is more complex than an early 80s one: they don't just start running from address 0; you find you have to consider the boot-up reason, switch into the appropriate CPU mode; you find you have to explicitly enable RAM (enable chip selects and memory areas, take it out of self-refresh perhaps, allocate memory regions for the MMU). Thus rewriting say the ROM to support a fundamentally different OS to Linux is orders of magnitude more complex than for an early 80s computer.
Moving to the on-chip peripherals. The level of integration means that the R-PI's chipset is orders of magnitude harder to deal with than, say, an Atmel AVR, which in turn is several times more complex than the peripherals on early 80s computers. They are 1000s of pages long just for the main CPU itself (including peripherals) - so much more complex that the designers of the R-PI must only know a fraction of the contents. I used to be an Symbian OS baseporter, I've seen these things, no-one knows these chips to the degree hundreds of thousands of people understand the innards of a BBC or ZX Spectrum. By comparison I've read the docs for the chipset of the Arm250 (=> A3020), and although more complex than an early 80s micro, are pretty much fully graspable with some effort IMO.
All this has a knock-on effect further up the chain. Supporting a chipset with a billion transistors requires complex APIs and frameworks to be defined which itself impacts on the complexity and design of the Operating System itself. But of course, for a large system we want to run everything it theoretically can run, so the complexity is compounded by multiple frameworks, libraries, tools, environments, drivers, front-ends and at this stage what happens is that because the developers who contribute to these systems only understand a tiny fraction of the systems (and can't afford to spend the time to learn the rest) there's continual re-invention and duplication. Then the people who bundle the OS distribution similarly can't spend the time to work out what's truly needed they have to play safe and include the lot.
Finally, on top of all this we want kids to learn to program again. However, the development environments we've constructed to manage our 10,000x more complex systems are themselves formidable beasts compared with the 10 PRINT "I AM FAB!" environments on early 80s computers. Ironically, these environments were better than, say Python's interactive mode (so much for 30 years of progress). So we're drawn to recreating noddy programming environments that don't *really* teach programming as well as, say, a 1K ZX81 can (that is, I strongly suspect one can learn more about programming from a 1K ZX81 than by downloading and exploring for example, Scratch). It's like trying to teach kids to read and write using War And Peace and then deciding we'll just start with the easy words in it: and, of, the, it etc.
It's this baggage at all levels that makes it hard for an R-PI to provide an educational programming environment as effective as an original BBC Micro or ZX Spectrum; although of course you can run an emulator for these machines on it (which in a sense is to validate the earlier machine); yet even that wouldn't be terribly good, kids know the emulated machine is a fake, a form of magic and the deception would impact their learning.
All this is to say, the complexity has an impact in every way when it comes to development. Which brings me back to the original point: if it's true that kids don't program because today's computers are 10,000 times more complex than their forebears then we really need to give them simple computers, not small, cheap, complex ones. The difficult thing is accepting it, because powerful systems are so desirable we kid outselves into thinking they're better in every way. To finish with, a quote from Richard Altwasser (BBC News 17776666):
"What is important is not the technical speed of the device but the speed with which a user can get their computer out of a box and type in their first program." At this level, a BBC micro, ZX Spectrum and FIGnition succeed where R-PI would struggle.
-cheers from julz