Part One – The Early Years (1981-1987)

I’m an old guy in computing terms. I’ve been programming in various ways, shapes and forms for something over 852,055,200,000 ms. Give or take.

In that time I’ve worked on numerous platforms and used numerous platforms, languages and toolsets as computing as a discipline and supporting technology has evolved.

Before kicking off here I’ll say, unashamedly, that I like learning new programming languages. Sometimes I’ll just read a book a two on one that sounds interesting just to pick up the principles. I find that just knowing these principles, especially from a language that has innovative features or just different origins can change the way that I approach programming in other, more familiar, languages.

It’s on the cards…

In the very old days, before keyboards were invented, I used to create Fortran programs by hand on 80-column punch cards. I recall sitting on a District line tube train travelling between Acton Town and Ravenscourt Park (that’s in West London for those who don’t know) punching out little cardboard squares, much to the amusement of my fellow travellers who deigned to lift their eyes from the magazines and newspapers and chuckle. I’d invariably have to jump off quickly at my stop, departing in a snowstorm of the little pieces.

Those programs were never very complex, merely playing a game of Noughts & Crosses (Tic-Tac-Toe) or performing some fairly esoteric calculation when processed by the mainframe whose cycles my school’s Computer Club borrowed from UCL. It was the first encounter with computer programming though and it got me hooked.

Sinclair ZX BASIC

Between 1980-82 I was introduced to BASIC on the (in)famous Sinclair ZX80/ZX81/ZX Spectrum family. I couldn’t afford such a machine but some of my friends had them and I used to write programs on paper and get them to type them in for me! This limited the complexity to around 80 lines or so – I was losing friends fast!

In 1982 I was given a second-hand DAI microcomputer, which used an Intel 8080 2MHz CPU with 48KB of RAM. This was actually a pretty good machine at the time. It had a BASIC interpreter which compiled code down to an intermediate byte code before execution which made it perform better than you’d expect. I wrote a lot of text-based programs (esp. adventure games) and learnt BASIC properly. Only problem was it never took off so there was no software available for it. It was a dead-end as a platform but a good machine to learn on.

BBC Machines

On my BBC machines (a 32KB BBC Model B and, later, a 128KB BBC Master) which I used a lot between 1983 and 1987, I used a variety of languages.

These machines were absolutely excellent to learn on. They were based on a 2 MHz MOS Technology 6502 CPU though I upgraded to a Master Turbo with a daughter board sporting a 65C102 clocked at a whopping 4 MHz whilst retaining the original CPU & memory as a dedicated graphics and I/O subsystem. Software could be loaded from tape, disk or, my preference, dropped into a ZIF ROM socket. The Master made this especially easy with two pluggable modules for this purpose. But I digress…


The native language in ROM on the BBCs was, of course, BBC BASIC which was head-and-shoulders above Sinclair BASIC and GW-BASIC available on the PC machines at the time. It was properly structured BASIC with functions and subroutines (rather than just GOTOs and GOSUBs). It had a built in 6502 assembler so it was possible to define inline machine code functions and call them from BASIC. Direct memory access was also possible using pointers. Nifty.

6502 Assembler

So, given the availability of the assembler it would be a shame not to use it, so I learnt how to code 6502 assembler which was, in retrospect, a RISC design with only 3 registers available. I learnt how to code “Sideways RAM” images so as to be able to effectively install software images of ROM modules and execute them as interrupt service routines to extend the OS of the machine. This just demonstrates the flexibility of these hobbyist machines.


I stumbled across the Acornsoft BCPL package at a computer fair one day and thought that it seemed very interesting. This was the first exposure I’d had to modularising software and having most of the functions of a language exposed as a set of importable libraries. It was also novel to me in that it was typeless – the type of operands being inferred from the actions being performed on them rather than the %, ! and $ variable suffixes I was used to in BASIC.

I played with it for a while to get an understanding of it but, for the sort of thing I was doing, it didn’t really offer me anything that BBC BASIC couldn’t and was more awkward to use. It went back onto the shelf and rarely saw the light of day.

Acornsoft Pascal / Turbo Pascal

For Christmas I received a book on Pascal and purchased Acornsoft ISO Pascal on EEPROM. This was my first experience in using a language that had strong typing outside of the integers, floats and strings that BASIC offered. It was also the first time, outside of assembler, that I was able to easily use pointers to structures as part of a language. I really liked Pascal and started to use it in preference to BASIC for my own projects. I also used Turbo Pascal for a few small projects at work between 1984-1986 or so.


In my reading about language development I came across this little gem. I knew that the Jupiter Ace had used Forth as its native programming language and had read some good things about how fast it was compared to a ZX81 of similar specification. So I purchased a Forth implementation for the BBC to learn it.

It was a complete eye-opener. To start with it seemed completely unfathomable and alien compared to what I had learnt before. Then it started to dawn on me that Forth is really meant to be a language to write other languages that are very specific to the problem being solved. These days a term you’ll hear a lot is Domain Specific Language – DSL. Forth does that in spades. You have absolutely no other choice but to write a DSL.

I already understood stack manipulation from having learned assembler and was able to equate word definition in Forth as being similar to creating blocks in assembler. I knew about Reverse Polish Stack Notation (RPSN) from my reading on language parsing and AST construction so that was fine. Forth was able to redefine words essentially on the fly giving the ability to streamline (or “refactor”) the code as necessary and was fast.

So why didn’t I use it more? It just didn’t have the support out there. People in the real-world generally used Algol-descended imperative languages and this was where there was interest. I could take a program I’d written in Pascal or BASIC into work and show people what it did and how it worked, if I tried that with a Forth program I’d just get blank stares. It also lacked a standard library set. I actually had a couple of different versions of Forth and they each had a different dictionary of primitive words. It also lacked decent string support which was what I seemed to be working with most of the time. So it fell by the wayside and, after a short while, joined BCPL in the back of the cupboard.

Saying that, Forth is on my list of languages that I believe a programmer should learn as part of their training in order to be a more rounded programmer. It makes you think in terms of the domain and the verbs and nouns that describe it.

Acornsoft C / Beebug C

Around 1985, I started hearing a lot about a language called “C”. At work we had several PDP-11 minicomputers and I was told that the software on there was mainly written in “C” and it was the successor to BCPL. (This wasn’t 100% true but it was close enough to get me interested at the time.) So, after reading a couple of books on it, I picked up the Acornsoft C compiler. The language was powerful and easy to learn given what I already knew. I was initially somewhat uncomfortable giving up the strong typing in Pascal but the other language features made it quite compelling. However, I was quite disappointed with the Acornsoft C implementation which was just too slow. I found that the Beebug version was much better and this became my preferred language on my BBC Master until I switched over to the IBM PC-compatible family.

Z80 Assembler

I actually bought an old ZX Spectrum+ (the one with the hard keys) from a friend back in 1985 and learnt to program Z80 assembler on it using a hex loader which I wrote myself in BASIC. These Zilog processors were commonly used for embedded controllers so I believed it to be a useful thing to know. It was also interesting in that it had duplicated registers that allowed for very fast context switching when handling interrupts (showing its pedigree as an embedded systems chip.) This was my introduction to CISC processor assembler.


Yes. I’ll admit it. I know COBOL. I learnt it between 1983-1986 when I was working on shift in Computer Operations. Most of our business applications (as opposed to systems) were written in COBOL and ran on Univac/UniSys mainframes. Part of the shift duty was to deal with production errors and it helped a lot to be able to print off the program listing and map, then interpret the crash dump to the programmer over the phone so they knew at least generally what the problem was before they arrived on site. At that time I never needed to write any COBOL, just read it, however, when I worked as an IBM systems programmer one of the systems I supported was partly written in IBM COBOL and I got some good practice writing it then! Haven’t used it much since though. Not my favourite language mainly because of it’s verbosity (and this was the days before decent editors with IntelliSense). It also gave me the heebie-jeebies about having to manage a lot of global data in a program. After using BBC BASIC, Pascal and even ‘C’ with their scoping rules this seemed like a backwards step (and it was, of course, having been designed in 1974).

ARM Assembler

Later on I learnt, but never really used, ARM assembler when making a decision as to whether to go down the Acorn Archimedes or IBM-compatible route in 1987. I was surprised by how powerful and clean the instruction set on the ARM chip was. The ability to make pretty much any command conditional on a variety of flags and also whether it should affect flags itself meant that a lot of the branching code that you’d normally have to write could just be put inline. If the conditional flag wasn’t set the operation would just become a NOOP. The pipeline didn’t need to be flushed and reloaded making the RISC chip really fast at code execution. The whole Acorn Archimedes had a really elegant hardware design but the PC market was heading down the IBM-compatible route and I jumped on that bandwagon.

So, that’s really the end of the beginning.

Next, the middle bit where I learn about Object Oriented programming, Declarative programming and that little thing called Windows.


3 Responses to “Programming Languages – I”

  1. Subba Says:

    That was cool and I felt like reading history of progranning languages. Cant wait for the object oriented language experience. Have you written or attempted to write any technical books?

  2. Traveller Says:

    This was a very interesting read for someone who’s only been into programming computers for the past 6 years (and counting!).

    Having read it, I noticed that your use of BBC Machines took you 86 years into the past. How’d you get back to the present that was? 😉

    • keyzero Says:

      lol!! Just a typo but I got back to the future with a lot of cranking on a Difference Engine!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: