Taking tools to the max. With BASIC?
3 November 2012 - ~7 Minutes Software Development
“Know your tools” is one of the key rules serious software developers live by, because it can make you highly productive. How far you can take this rule?
This is a story about BASIC. I don’t mean Visual Basic, I mean the proper old-fashioned BASIC. People of a certain age (such as myself) who got a “home computer” between the late 70s or early 90s will be familiar with BASIC. When you switched on one of these computers, you were dropped straight into a BASIC interpreter.
To even start a game or application required typing a couple of commands of BASIC. These home computers opened up the first experience of programming for many, inspiring a career in computer programming, myself included.
However many said that BASIC was not a serious programming language. It wasn’t suitable for commercial software development; it wasn’t suitable for large-scale programs; it taught bad habits. Wannabe programmers should graduate off it as soon as possible. Many games and applications for these home computers were actually written in assembly language. So I set to and learnt 68000 assembly language for the Amiga, quickly realised that any non-trivial program would be huge, and moved on to C. In later years, C++, then Java and C#, and even a bit of Ruby and its ilk. I realised that over the last decade or two, I’ve slowly been moving back up the language abstractions to where I’m nearly back to BASIC again.
The character at the centre of this story is Colin. Colin and his family lived in the same village as I did, and his eldest son was a similar age to me and my brother and went to the same school, and we became family friends. Colin worked in computers - at the time, I didn’t really know exactly what. I wanted to enter a career of computer programming, but didn’t really know how to get there. At the age of about 13, everyone in my school year took part in work experience week. I saw a chance and suggested that I get placed at Colin’s company.
What started was my first experience of computing as a career. I learnt about what Colin’s company did - specialised accounting software for petrol stations. Colin’s knowledge of this vertical market was comprehensive. I learnt all kinds of weird facts - wet stock and dry stock (meaning stuff that comes out of pumps and stuff that the shop sells, respectively), tank variance (how to tell if your petrol has merely evaporated, or is actually leaking into the ground), barcodes (if 50143047 doesn’t appear in your sales records for the day then something has gone wrong), as well as what these mysterious words “sales ledger” and “purchase ledger” actually meant. I learnt about interoperating with external hardware - the extensively customised “tills” that handled shop and petrol sales, often with weird interfaces that used synchronous serial communications and EBCDIC. Above all, I learnt how other companies making products in the chain didn’t understand the real world, as proved by various devices having bizarre communication protocols and behaviour.
But Colin’s product was written entirely in BASIC - something that I had been conditioned into believing was a bad thing. Yet here it was running a successful business, deployed at a couple of hundred sites in the UK. How was this possible? It turned out that BASIC was not the evil monster I’d been warned about. If you could truly master BASIC, you could do some surprising things with it. It had several practical advantages that you couldn’t get if you were writing in C or assembly language.
For a start, there actually wasn’t a practical reason why you couldn’t write a large application in BASIC. GW-BASIC
and its successors could define record files, giving you simple database-like functionality in a flat file. For faster
access, a second flat file database containing just a couple of fields for indexing purposes. QuickSort could be
implemented in BASIC, so your index file gets sorted. Then a binary search algorithm on the index file - result, you can
search a field for a specific value (a barcode, for example) and retrieve the full record in next to no time. Not bad
for a supposedly toy language working on a 386 or even 286 PC. Commands for poking hardware meant that BASIC could drive
some of the more esoteric communications hardware that was required. And although BASIC didn’t have enough memory to
handle a truly large application, there was no need to have everything in one program - split it into modules and
CHAIN
between modules.
QuickBASIC made it easier again, by dropping the requirement for everything to have line numbers. Code reuse? Use
an $INCLUDE
directive to bring in common material.
BASIC had some great advantages for supporting customers, too. The primary method of support was by way of 2400 baud modems and pcAnywhere software, which replicated the remote user’s screen and keyboard. This worked fine for interactive DOS sessions, but at that speed file transfers were slow - you would want to avoid transferring the customer’s database back to the office, working on it, and then transferring it back. But the customer’s PCs also had GW-BASIC on it. A skeleton set of BASIC source code was part of the standard install at the customer’s site, containing the file record definitions and various debugging utilities. Colin could start the BASIC interpreter on a customer’s PC, load a skeleton file and write a few lines of code to perform the specific task required - searching a database file for a corrupt record, or for a specific transaction with certain known fields, or to update a set of database records according to virtually any criteria.
I continued working for Colin during school holidays and, later on, between University terms. I was learning more about computing, and I told Colin about some of the things I had learned for myself. C, for example, had better error handling. A function call would return an error code, whereas in BASIC, an error would result in the interpreter jumping to a completely different area of code to run a generic error handler. “But”, said Colin, “that means that after every function call, you need to check for errors. That means writing more code. BASIC does that for me.” It’s difficult to argue with that.
“C is faster because it’s compiled,” I said. Colin replied, “what’s the equivalent to running GW-BASIC so I can quickly write a BASIC program to make a special change to the customer’s database?” “Well, you can’t have the C compiler on the customer’s computer. You’d have to write the code here, compile it, upload it to the customer’s computer, then run it there.” “That doesn’t sound like an improvement to me,” he replied. Dammit, he’s right.
So what has happened in the following years? Exceptions become the norm for error handling - basically a more
object-oriented way of jumping to a completely different area of code to handle an error. Embedded SQL databases are now
showing up in desktop applications, where support engineers can start up an SQL client to query and fix data errors.
We’ve all been moving back up through the stack. Are we nearly back at BASIC - or have we surpassed it? The default
behaviour in most modern scripting languages when an error occurs is to bomb out, unless you’ve explicitly added ON ERROR GOTO
- err, sorry, try...catch
to catch the error. A bit like BASIC.
Meanwhile there’s PHP, a language that by many accounts is a disaster, and recommended against by all kinds of people in the know. Yet some people have mastered it and built strong empires on it - WordPress powers over 70 million websites (this blog is one of them), and Wikipedia is one of the most well-known destinations on the Internet. Not bad going for something that is often considered a pariah.
BASIC was made to be the language that made computers easier to use, but it was rejected by many. However it doesn’t get the credit it deserves - an expert in BASIC (like Colin) could surpass those working in other languages. In the intervening years, the computer industry has re-invented a lot of it, with modern names for its concepts. Luckily, however, line numbers haven’t made a comeback.
Sadly, Colin died recently, leaving behind a wife and two sons, and my thoughts are with his family at this time. Colin was undoubtedly an influence on me, and I learnt a great deal about the computer software industry from him.
About the author
Richard Downer is a software engineer turned cloud solutions architect, specialising in AWS, and based in Scotland. Richard's interest in technology extends to retro computing and amateur hardware hacking with Raspberry Pi and FPGA.