Reading a recent piece on Slashdot about the BBC Micro set off a wave of nostalgia which got me thinking about just how I got involved in computers in the first place. The BBC Micro was not the first computer I had used – we had a ZX Spectrum at home – but it was the first computer that I made a proper effort at programming. My primary school had several BBC Micros. The intended purpose of the machines was never clear, though we did occasionally make use of the famous LOGO turtle. Whatever other uses we made of them have faded into the recesses of my memory; the one thing that remains crystal clear to me is the undirected time I had in which to play about with creating my own programs. I learned how to do this from a school friend, who knew some rudimentary BASIC. (And there you have it – I learned more about how to program computers in school from a nine-year-old boy than I ever did from a teacher). He taught me enough that I could create some very simple programs, most of which never did very much at all. I had a few attempts at creating what I would now describe as text-based adventure games but which were really just chunks of narrative separated by some IF statements.
I was hooked. The idea that I could control this box of electronic magic by giving it a set of commands fascinated me. The fact that, once running, a computer program essentially had a life of its own was a source of wonder and amazement to me. I spent far more time than I was supposed to at school inputting endless lines of BASIC code, just to see what I could cause to happen.
As I got older, I moved on to DOS and Qbasic, which was similar enough to the old BBC Micro BASIC that I could do all of the same things with it. But this was around 1995, and DOS was finally on the way out. I tried some Visual Basic but didn’t particularly enjoy it. The sense (an illusion, but not a too gratuitous one) of having total control over the computer’s operations was not present with Visual Basic’s event-driven model. And I had picked up from somewhere that real programmers didn’t use Visual Basic – real programmers used C. So, I picked up a C++ (I figured that I might as well learn C++) manual and began reading it.
I was still reading it a year later and wasn’t any closer to understanding it. I played around a bit with Borland Turbo C++ - a retrograde step in that I was going back to DOS, but this was probably necessary; having to learn C++ and the Win32 API at the same time was probably too much for my 14-year-old brain. I soldiered on, but advanced little; I was now using printf() instead of PRINT, but that was it.
Then, one day, it all clicked into place. I suddenly got it and discovered just how amazing it feels to get it. I was now, irretrievably, a computer geek, but I was now also proud of it. I had taken on a proper programming language and I had won! The mysteries of pointers, references, operator overloading, memory allocation, polymorphism, virtual functions and static typing had been revealed to me. (I admit that it took a bit longer before pure virtuals, templates and the STL made any sense).
After this, the Win32 API was next – the concept of the message pump, window handles, the Win32 threading system, socket programming and, ultimately, COM and its associated technologies. I wasn’t even sure what I wanted to do with any of these except understand how they worked. And I can say with complete confidence that that is exactly what I did. To this day, I can still remember the definition of the IUnknown and IDispatch interfaces, or explain what IConnectionPoint was for, even if that makes me one of the few people outside of Redmond who bother to remember.
After I finally did some assembly programming (for an alpha-blending function using those new-fangled MMX instructions), my quest to learn the geekiest stuff available to me was complete. I realised that sometimes knowing stuff isn’t as important as what you can achieve with what you do know, and diverted my attentions toward more practical technologies. Linux and the internet were changing what it meant to be a developer, and the new age of web applications meant learning SQL and web scripting languages such as PHP and Python. Nowadays, it’s not uncommon for me to be working on projects that have frameworks on top of these scripting languages. In many ways, I’m working at a much higher ‘altitude’, a long way from the C code which is at the heart of the OS and web server that my applications sit on top of. But merely knowing that these things are there, and understanding how they are built, and how the minds of the people who built them work, provides an incredible advantage in developing higher-level applications.
For new programmers starting out now, the experience must be greatly different to mine. I could sit down at a BBC Micro and input a set of commands which would produce an immediate output. I’m not even sure how one would go about this using Windows XP or Vista – sure, both operating systems have scripting systems built in, and I recall that the Windows Scripting Host can do some command-line I/O, which is all that you really need to get started. But it is surely more complicated than commands like PRINT and INPUT and this complexity might be enough that my equivalent, some 15 years behind me, might not bother to learn how to take those first steps.
So, perhaps there is something that the BBC Micro can still teach us. In many ways, it would still be a good platform for learning to program on. If I wanted to teach kids programming, I can think of worse systems to use.Share