Spellcaster
or, discovering and recovering a lost programming language over the course of a weekend
I go down rabbit holes. One of the great pleasures of this dumb future we live in is that you can dig through the milk crates of our culture forever, following whatever interests you, and there is no bottom. My latest rabbit hole looked something like this:
- I have been spending a few minutes each day seeking out backgrounds for use on Google Meet calls at work that match my t-shirts.
- I was wearing a t-shirt featuring some early computer comic art from a Beagle Bros catalogue, drawn by Robert Cavey
- Started poking around at old Beagle Bros catalogues, settled on this background
- Started poking around Apple II magazines for more Bob Cavey comics
- Discovered the following advertisement:
Wait, hold on a minute. This kind of sounds exactly like the weird idealized programming environment I keep in my head. Obviously with serious restrictions and caveats, but, as a learning tool? They implemented this on an Apple II in 1984? How far exactly did they go?
I mean, look at this:
- “Everything a Spellcaster program does leaves marks on the screen. You watch all its inner workings in motion.” Programming is frustratingly opaque – it can be incredibly difficult, especially for a beginner, to answer the question, “why is the computer doing this?” But for the purposes of a teaching language, why not put all of the program's state on the screen?
- “Debugging a Spellcaster program is easy, because you can stop it, make it back up to the mistake (while you watch), change it, and let it run forward again.” I have been fighting to build this literal exact workflow for YEARS. Time travel debugging crossed with edit and continue??
- “Imagine an editor and interpreter so wed that every keystroke, as it is typed, is syntactically checked and executed, so you instantly see its effects. If you backspace, the program reconstructs its previous state — even in the middle of conditions and loops.” A special livecoding editor built for the tightest possible feedback loop, with no invalid states?
So of course I went looking for disk images.
There were no disk images. There were a couple of scanned magazines with the same ad. That was all I could turn up.
I started asking around on the internet and a couple of people tracked down a few more references; a couple more short reviews in some magazines. The jackpot, though, was this reimplementation of Spellcaster written in Processing. The readme gave me names, and the names gave me email addresses.
Long story short, I reached out to Scott Gilkeson, the original programmer of the C64 version, and it turned out that he had conveniently made disk images a few years ago. He also put me in touch with John Fairfield, the original designer and programmer of the Apple II version, who gave his blessing to share them. (The Apple II version is lost, as far as anyone knows.) There was also a PC version, written in C; nobody seems to know where that is, either. Within a day of reaching out, I had a copy.
You can use Spellcaster now, right from your browser.
A manual is also available. (Scott is seeing about creating a higher-quality scan, but what's there is much better than nothing.)
John Fairfield would go on to cofound the company that produced the Rosetta Stone language learning software. Spellcaster is, in a deep way, also language learning software. There are some truly fascinating design decisions made, not only in the Spellcaster programming environment, as advertised, but also as a language.
- It is the only programming language I am aware of that is designed to be spoken. The way the editor works, you generally press keys corresponding to syllables, rather than letters. There are occasionally some mnemonic properties to those syllables, but they're pretty arbitrary; you end up writing words like
NUBOBORIBOBOLIAKA
. Presumably, in a group learning setting like a classroom, this means programs can be unambiguously talked about, down to the last instruction – an often overlooked but useful property, as anyone who has tried to read code off a slide can attest. - There is a base 4 numbering system that's used in a few different places; 4 of the 5 vowels are used as digits, and paired with a starting consonant to mean different things that are done with that number (
MABO
means “repeat BO once”, KA means “set the pen to colour #1”). The fifth vowel, U, is used to choose a random number between 0 and 3. Because there are four cardinal directions, and 16 colours, this means something likeMURI
(turn clockwise a random number of times) is a nice concise way to write “point my pen in a random direction”, andKUKU
is a nice concise way to write “choose a random colour”. Again, designed to be spoken, but also designed to be concise. - You can have spaces in identifiers, but not the letter Z. Z is short for the
ZIM
syllable, which ends free text entry. Honestly? I kind of really love that tradeoff. A beginner is much more likely to run into the question of “why can't I write two words here” long before they ask “why can't I write a Z”. - You can also give a spell an empty name. I did this by accident but the manual says “Well, that's the name that has no letters in it, and it's a perfectly good name.” And indeed, it just works, to call it you just write
TUZIM
, a little like if there was a special function you could call in Lisp by writing()
. - Reading just a little further into the manual, it turns out the spell with the empty name has an actual, specific purpose!
VUZIM
means “see if the user pressed a key, and if they did, run a spell corresponding to that key”. So if the user hits the “A” key, it will run theA
spell. So of course since you can't have aZ
spell, if the user hits the “Z” key, the empty spell is called. Given that you do have to hit the “Z” key to create the spell, there is a certain strange elegance to it; I don't entirely know if I think it's a good design but it's sure not a choice I would have thought to make.