Part of the reason I haven't been posting to this blog in a while is that I have been moving my business and life from Toronto to Halifax. Coincidentally, frequent collaborator Paul Doerwald has moved Liquid Media out to Halifax around the same time as well.
Every Friday around noon, anybody who is interested meets up at The Hub and we go a nearby restaurant for lunch. Then we return to the Hub and spend the afternoon working on our own interesting projects.
Some people are working on Adhearsion implementations, others are building iPhone applications, and others are playing with the Twitter API.
Me, I'm going back to BASIC:
While clearing out my Toronto apartment, I found an old book from 1983: "Write Your Own Adventure Programs For Your Microcomputer". It was part of a series of colourful computer books by Usborne press. The early 80s were an era when every home computer came with BASIC, and you could buy magazines and books with short program listings in them that you could type in. I had enjoyed Usborne's books of short programs, so I remember looking forward to trying this one. It turned out that my 12-year-old brain couldn't quite handle the complexity of this program (200 lines of code on 5 pages, with lots of data statements and $tring management), but I liked the pictures and so put it aside for later. It somehow managed to not get thrown away in the intervening 26 years or so, and was rediscovered in a box just a few weeks ago.
So my first Friday Afternoon Hack event is to finally type in this program, and rediscover the world of programming in the early 80s, when an average machine would have 16 KILObytes of RAM, would store programs on audiotape, and often had cheap plastic or membrane keyboards.
It's a bit surreal to type in 80s-vintage Apple II BASIC using EMACS and TextWrangler, and then copy-and-paste it into a browser window to see how it runs. It's more surreal to be figuring out code from a quarter century ago.
The program makes a good exercise. It's more sophisticated than the simple "1-6 randomizer with a win or lose message" Russian Roulette games I used to type in. It has a small vocabulary of verbs and nouns, multiple data sets, and a request/response event loop.
The book is well written as well: it covers how to plan out the locations and objects for an adventure game, explains how arrays and event loops work, and how to handle a vocabulary - all in full colour with little cartoon ghosts pointing out the interesting bits.
Here's what the first page of the code listing looks like:
Line numbers. Wow, what a crappy way to have to write code. The standard approach is to increment the line count by 10 on every line, so that you have some space to insert code without having to renumber every following line. Sections of code were often offset by 1000 or 10000 so that they could be kept separate. Often if you did have to insert large amounts of code, you would have to use...
Goto and Gosub. This is the reason that you have to have line numbers. When you only have 1k or 16k of RAM, there isn't really the space to have named functions or named code sections, so to be able to jump around inside your code, you need to refer to the numbers. It's pretty easy to see why goto is considered harmful.
Data statements. It's a tiny program in a low-resource environment, so there's no separation of code and data. All of the application data is entered in a collection of DATA statements and FOR loops which populate (single-dimension only!) arrays. Get any of the DATA statements wrong, and nothing will work.
No compile step and an instant runtime. Probably the best aspect of BASIC that helped build a generation of programmers - you can type something in, type RUN, and instantly see the result. This almost makes up for the non-descriptive error messages.
If nothing else, I can finally finish what I started when I was 12. Remember, it's never too late to have a happy childhood!