Transcript
Ruston: My name is Jeremy Ruston. You may know me for my work on an open source project called TiddlyWiki, which is 20 years old this year. I'm actually only going to talk about that tangentially, and leave this here to whet your appetite. I hope instead to take you on a journey back to the very early days of home computers in the UK, and use my experiences then to help us think about the landscape that we see around us today, and the challenges that we face for the future. We'll talk about technology, but also culture and communities.
We'll hear a little from the young man on the left. We'll be seeing some extremely fruity, old 1980s computer animations. I should first apologize to people who might feel strongly about other home computers, and there were many other fine home computers in the '80s. I'm not denigrating those at all. Perhaps a machine like the Spectrum might have had more influence on the games industry than the BBC Micro.
The BBC Micro was unique in its influence on the broader computer industry. Of course, I wasn't one of the pioneers who built these machines, or built that generation of hardware and software. QCon has already been lucky enough to hear from some of those people such as Sophie Wilson, and I highly recommend those talks. I was just an enthusiast, a fan in the right place at the right time.
Computers, in the Culture of the 1980s
Let's step into this handy TARDIS and go back to January 30, 1983.
Interviewer: In South East at 6 tonight, Mastering the Microchip, are two teenager's expertise on computers is making them a fortune. You don't need a computer to tell you that we're now living in the age of the microchip. Our homes are randomly being invaded by mini computers, 17-year-old Jeremy Ruston, and Alex Gollner who's 15, are two London school boys who stand to make about 16,000 pounds between them this year, cashing in on the computer craze.
Ruston: Strip away the prurient interest in money, and the focus on our ages. That little news slot actually quite neatly shows how computers sat in the culture of that time. There was excitement about them, and that was newsworthy, but really, I was there as a curiosity. Computers were new and exotic, vaguely threatening things that the vast majority of people at that time would never even have knowingly laid eyes on. In fact, at that time, my parents would bring their friends up to my bedroom, or hackerspaces, just to marvel at the sight of a computer, rather, as people in the 20s marveled at the sight of aeroplanes passing overhead. The thing I love is that now those people are all addicted to their iPad.
I think the interviewer talking about computers invading our homes is incredibly revealing. I didn't have to be very astute at that age to realize that the problem was that he was scared of computers and the change that it represents. That's my attempt to make a scary BBC Micro roaring. I found that really weird at the time. How could anyone be scared of computers? They were self-evidently wonderful, fulfilling things. Since then, I've worked for many organizations that face threatening existential change, and discovered that for many individuals within those organizations, the best strategy faced with a catastrophic change is just to ignore it, and pretend it's not happening. For instance, at BT, I remember senior people who profess to believe that Voice over IP wouldn't be a threat to BT's core business, because customers, you, instinctively prefer the familiar reliable feel of a landline call. They believe that given a choice that's what people would choose.
Let's go back to 1983 and see how Jeremy responds to this impertinence.
Interviewer: Jeremy, first of all, how did you become hooked, and what's the fascination?
Ruston: I started off being interested in electronics and building radios and so on. Then I started building small computers. From then, I just started buying ready-built ones instead.
Here indeed is that first computer. Its chief advantage was that it was 39 pounds 95 in kit form. Probably on this screen you can see my candid soldering. I don't know what that is. I was 12. Of course, it says there, only had 256 bytes of RAM. I don't think I ever filled that memory in my time with it. An astonishingly limited specification. As it says, no stack register.
It was like a RISC processor that had been cut in half, then cut in half again, and then cobbled together to work. Incredibly hard to convey how hard it was to use. It was about as much fun as programming a central heating controller. Our expectations of 256 bytes of RAM can be wrong. This is an image, it's an entry in a demo scene competition. The conditions of this competition are to write a MS-DOS XE in 256 bytes. That image is a 20 kilobyte JPEG generated by 256 bytes. How can 256 bytes contain an image as rich and complex as that? An astonishing achievement, but an extraordinary commonplace achievement today. What if I told you that actually, if you run this code, let's see what happens. This is actually animated. To me, it's stunning that in the amount of space that I might allocate to a comment at the top of a file, somebody can build an entire immersive world. I think that is in the category of impossible things that we need to believe before breakfast.
The Role of Computer Magazines, in the '80s
Going back to the '80s, in the absence of the internet, the home computer community primarily manifested itself through computer magazines, and there were a lot of them, and they were a big business. A weird thing is, besides providing a substrate for the community, computer magazines were also a software distribution mechanism. They were stuffed full of listings of programs that people were expected to type in for themselves.
I soon started sending them in because they got published. It was, at the time, quite easy to figure out what people liked and send in this code. It was my first experience of what happens in a community, and today working in open source to see the same thing. It's the cycle of copying from other people, modifying what they've done, sharing it within the community, typically within a platform. It's weird to me that my first experience of that community was built on a substrate of old media, magazines, and books, and so on. It was still the same process that we see today.
That was the context for me when the BBC Micro appeared, fresh from using a machine with 256 bytes of RAM. The photo I showed at the beginning was the front of the machine, but in fact, the underneath and the back are far more relevant to our discussion. You can see a large array of ports on the back and the front, mysterious ports, but easier to see on the schematic. The BBC Micro arrived with a very detailed manual, this included circuit diagrams of the connectors, which makes me laugh to think of the iPhone coming with a circuit diagram.
You can see there's a stunning array of ports, ones that you would expect, like a cassette interface. Also, a networking interface, in 1981 was for us, I know, one of the first networkable home computers. It had a video output that you could connect to your television. Indeed, the videos that you're seeing today were recorded on VHS like that. It also had a digital RGB output. Underneath, you can see parallel interfaces for disk, printer, and unassigned user ports that could be used for a variety of things.
I jumped in and enjoyed all of that, and made my way from sending programs to magazines to writing books. Books at the time were also a software distribution mechanism. We tried to do the same things with software but we had to make do with the media at the time. I think these books today would just be a YouTube channel. Kids today do that kind of thing, or probably a Discord server. We didn't have any choice. At the time, I was typing out these books on an electric typewriter with my mum proofreading them.
It's also weird to think that home computers were so popular. The book, "The BBC Micro Revealed," actually made it into the Sunday Times top 10 bestseller list for a couple weeks, which is extraordinary for an incredibly arcane, confusing, very technical book. I think what happened was that a lot of parents were buying the BBC Micro for their kids in the belief that it would help educate them for the coming invasion of computers. They also picked up a copy of my book to reassure themselves that their child was going to be learning to program and not just playing games. Less gloriously, the book, "The BBC Micro Compendium," got me sued by Acorn. Several of the books were translated into other languages. It was actually really cool at the time to see the mechanism that the publishing industry, how quickly and efficiently they could do that.
The book you see in the middle is an American edition of one of my books. Even that needed translation. I'd use the word clever. In the English sense, that was a clever thing to do, but that has a completely different connotation in North America. The translators quite rightly had changed it to the word smart, which I would never use in that context. That experience underlined for me the way that unknowingly our own culture and geography can be a barrier to communication. We need to pay attention to that. I hopefully will try to show you why.
Collaboration in Open Source
We see this idea in open source projects like TiddlyWiki. It has, like many open source projects, a plugin mechanism. We have a common substrate, a universal core. Plugins are our mechanism for people to accommodate people's sometimes conflicting requirements. We've architected it deliberately to be translatable. What you can see here is what happens as I work on TiddlyWiki. I'll merge a PR, that might include a change to the English translation. Then, within an hour or two, BramChen will submit a PR with matching changes for the Chinese translation. It's by far the highest quality translation we have and the most up to date.
Quite often, he'll point out errors in what I've done or inconsistencies. As you can see, this has been going on for 10 years. I've had a 10-year relationship with Bram, but I've never met him. We can't really communicate except in Google Translate mediated broken English, and of course through the code. The privilege for me is that I feel I have these talented people looking over my shoulder helping me with my work. I feel as though I, like a lot of us here, are participating in a completely new way of working, that we're going to see more of in the future.
It simply couldn't have happened just a few decades ago, the idea of collaborating so closely with somebody on the other side of the world. In fact, the Chinese community of TiddlyWiki is interesting in other ways too. The first thing is, it's huge. It's based on Chinese message boards, and an ecosystem of tools that I can't really see. It's like dark matter, this community that I can't see directly, but I know about it from the members of that community who also participate in the English language community. Indeed, there is a small group of Chinese developers, who are incredibly prolific and valued contributors to the project. What it means to me is that I haven't accidentally made a piece of software that represents me. I haven't accidentally made a piece of software that embodies the thinking of a middle-aged white man. I have actually achieved the goal of making something that's universal enough to be used by people of any culture. I think that is important for all of us in our work.
Understanding the Inside of a Machine (BBC Micro)
What were those books about? I think this is the first bit of code I've shown. When I got the BBC Micro, I dived into it, trying to understand every aspect of the machine, such thing that would be impossible now. Nobody could understand the inwardness of an iPhone, there's just too much going on. It was possible for one brain to understand the entirety of the inside of the machine. I'm afraid a lot of that is gone now. At the time, I knew where every memory location, hardware register was for, and I knew how to blow up your monitor by freaking the video chip.
For me, I think the biggest impact of the BBC Micro was going from programming in machine code to an extremely at the time, advanced, sophisticated, elegant, basic language with a built-in assembler, so that I could still jump into the assembler when needed. I was fascinated by the way programs like BBC BASIC, were constructed by people with great skills, deep technical skills. They were using those skills to empower people with less deep technical skills to do the same thing. To me, that's the kind of magic, to take your skills and empower people with less skills to pull them up behind you.
We live in a world today that's riddled with software. Software is eating the world. Software is making the world. It's riddled with it. Dig into the ground, anywhere, all you'll find is software. Every type of business now has to be a software business. Software developers like us are in a unique position. We're the people that can not only understand this world built of software, but also, we know how to change it. That was me disassembling BBC BASIC. I did a lot of that. In fact, that's still going on today. You'll find the BBC Micro community, those members who will publish a new disassembly of some popular game from the '80s. It's a big event.
TiddlyWiki in Use
Armed with what I'd learned by disassembling BBC BASIC, I went on to write many compilers and interpreters myself, and realized that's what I cared about, creating a tool that I could then watch other people build something with. Empowering them to do something that they couldn't do previously. I think you see a nice example here with TiddlyWiki. TiddlyWiki has wiki in the name, but it's not at all interested in the idea of being a single page that lots of people can edit. Although it can do that, if you configure it that way.
What it's really rooted in is a much more fundamental idea of wikis, which is that they elevate linking to be part of the punctuation of writing, as opposed to tools that require you to dive into a sub-dialog box, to set up a link. TiddlyWiki takes that further with a rich wikitext syntax, that can express complex interactive applications. The goal of that, the reason why we do it, creating yet another computer language, is to let domain experts create their own custom tools, rather than having to go through a cycle of trying to explain the unexplainable requirements to a developer, and then the feedback cycle that results.
Here, what we see is an example of TiddlyWiki being used by an American high school teacher to develop a custom application for teaching volleyball. I have no idea what it means. You click around and there's masses of it. Little tables of instructions, ways of tracking the progress of the students. The thing that's interesting to me about that is I don't believe this world at the moment has a viable business model for custom software for volleyball teachers.
There's no business there. How can we serve those people? We know that what we do is useful. We know that computers and software applied carefully can help jobs like that. We simply don't have a business model. To me, the best that we can do is this, is empower the people who have the domain skills to build their own software. We have to step around capitalism and focus on people's needs.
Another example is TiddlyWiki being used by the Anna Freud center. They're a London based charity that do training and resources for working with young people with mental health problems and their families. They train all the social workers and similar people around the country. The challenge for them is that they've got a team in London, who are highly skilled, experienced, and they know, based on evidence, what practices work when you're in that situation with troubled young people. Their approach is to build a manual telling people what to do.
The discovery very early on was they had a team in London put together a manual telling you what to do, and then you give it to the team in Dagenham. If the team in Dagenham see things in the manual that don't apply to them, they'll reject the whole thing, that it's not for me. What we do with TiddlyWiki at Anna Freud is build what they call a fractal manual where there's a central manual, where individual teams get their own version of the manual that adds and removes content to make it relevant for them.
Of course, that's easy. It's just a database query, put different stuff on a webpage. What's hard here is to build a model for doing that kind of task that these domain experts can do. I'm not designing a system for you to use, I'm designing a system for social workers to use, for people whose skills are in another area.
Self-Education
Let's, with that, step back to 1983, and have another patronizing question from our interviewer.
Interviewer: It must be pretty difficult writing all these bestselling books, and trying to struggle with your A levels?
Ruston: Yes, it is issue, very difficult. I failed my A levels in the summer because of it.
Interviewer: Has it been worthwhile?
Ruston: Yes, very much so.
Of course, I wouldn't want to advertise the benefits of failing school. At the time, all I was interested in was computers. That was all I wanted to learn about. Back then, I didn't have any chance of learning about that at school. Instead, I learned from the community and hanging around foils, reading all the important academic textbooks at the time. Now, of course, it's never been easier for people to educate themselves. We saw earlier those ports on the BBC Micro, they gave rise to an ecosystem of hardware that was really fun. I think the barriers to entry for that market were quite small. We saw a lot of innovative strange hardware.
This is a very early graphics tablet, which I have put to good use, in some quite fun work again for the BBC. It was later in 1983, I think one of my favorite ever gigs, where I made a series of animations on the BBC Micro that we use with a voiceover to introduce Children's BBC TV shows. That was a wonderful job. I would slouch into BBC TV center in the morning and have a meeting with the head of presentation, and we'd decide together that the next animation would be a tin of sardines with a wiggly tail. Then I'd go back home, stay up all night with a pint glass of coffee, putting these animations together. Then slightly bleary eyed, take them into the BBC the following day, and press the spacebar at the operative time for the animations to flow. I was involved for a few years in this but ultimately replaced by a broom cupboard, of all things.
Watching these back now I think, actually, the best thing about them is the sound effects. I hadn't kept these obviously, and so I put out a Twitter alert and found that again, there's a community that we didn't know about of people who collect old British TV VHS tapes. I have managed to now scrape together about eight of them, but there were a lot more of them originally.
Latency in Computing
I also wanted to briefly mention the late Joe Armstrong. We'd been working together on a book about TiddlyWiki, just about a year before he died, almost exactly 5 years ago. Joe had first gotten in touch with me back in 2011, having somehow become obsessed with TiddlyWiki. We stayed in touch regularly and collaborated on a conference talk. Then the book, which was sadly curtailed when Joe passed. It was actually very difficult to get Joe to talk about his own work. I didn't have at that time any experience of Erlang, but I was fascinated to learn more.
Every time I'd ask him a question, he would redirect it to some arcane intricacy of TiddlyWiki. You can still see his blog today, based on TiddlyWiki. Joe taught me the full implications of a really simple observation that I think really, we're all grappling with: latency matters. If you care about latency, you need to move computation to where it is needed. If you have separate bits of computation, the laws of physics pretty much mean that you're using the actor model. I think Joe's formalization of the actor model into Erlang to me was a formalization of the laws of physics that I found incredibly inspiring.
BBC's Doctor Who (Game)
We'll go back to 1983.
Interviewer: Perhaps we could now take a look at your latest computer game which is called Doctor Who. How does this work? Is this sort of Pac-Man, isn't it?
Ruston: Yes. It's based on some of the ideas from Pac-Man, but it's a very long program. It's taken quite a long time to lay it off disk. Essentially, you're that little dot in the corner, and you're being chased by those worms who have now eaten me. That's the game.
The game I showed was described as being called Doctor Who, but in fact, it was a bit more than that, it was the BBC's first official computer game using their now cherished Doctor Who intellectual property. I don't think it was quite so prized at the time. You might think it was an eccentric decision to entrust a franchise like that to the hands of a 16-year-old, however precocious. I know we've got people from the BBC here, and I'm about to talk about how the BBC worked in 1983. I'm pretty confident it doesn't work like this anymore.
What actually happened is I'd co-written a book for BBC publications, first called, "The Book of Listings." Again, reminding us that a book was considered an efficient mechanism of software distribution at the time. Getting a book published means having lots of meetings. That's how the industry worked at the time. I remember being quite often in the BBC publications offices in Marylebone. Once I was there, anything could happen. The lesson I learned is that people are lazy. One day, I was in the office and somebody said, Jeremy, would you like to do some modeling?
I really thought they meant Plasticine or McCartney, but they actually meant this. I ended up on the box of the BBC's robotic Turtle addon. In that context, when they started exploring making a Doctor Who game, obviously, I was the logical choice. I was a massive Doctor Who fan, of course, still a child at the time. I was thrilled. I wasn't really a games player. My interest in games again was diving into the tour de force programming that I saw, and I wasn't that interested in playing games. I never got to meet any of the actors, of course, but did get to collaborate with the Radiophonic Workshop on the music and sound effects, and did go to a props warehouse, where I saw an enormous pile of Cybermen body parts being prepared for an explosion.
It's a coding conference, let's look at the code. A couple of interesting details, I mentioned before how it mixes assembly language and BASIC together. You might notice we essentially minified our own code back in the day. The game was not an unqualified success. I think it suffered from being made by a committee, and a committee of people who are inexperienced, didn't really know what they're doing. That's not the recipe for success. I hope I had an excuse being 17. Even though the game could have been so much better, it is actually still bringing great joy to people. There's a steady stream of YouTubers reviewing it, and they revel in its hapless terribleness. I particularly recommend this to French people who watch it who have a species of hysterics that is quite infectious.
Jeremy's JavaScript Linguistic Serendipity Generator
Let's jump back to one last dip into that interview.
Interviewer: What are the practical applications really for home computers. What are the most useful things you can do with one in the home?
Ruston: I think the most useful thing really is word processing for writing letters and so on. Then, there are the less general applications like shopping lists. I use it for cataloging records and books.
I answer honestly that I use computers for cataloging books and records, and had in fact written more than one program for that task. Of course, I was far too distracted by the joys of programming to actually use it for its intended purpose. Instead, I'm going to talk about something that I think the interviewer would have firmly considered utterly impractical and stupid.
This gives me a chance to talk about AI and large language models which I know we'll all be expecting. What I'm actually going to show you is the smallest feasible language model. It's something that many of you will know. There's a Markov chain generator. I didn't know that at the time. It's a program I originally wrote for the BBC Micro. What you see here is a more recent JavaScript version that's on the web and you can play with. What it does, very familiar process. You give it a body of training data. It does some frequency calculations. Then it generates essentially random text that matches the same letter sequence distribution.
Let's see if we can give it a try. I've primed it with a list of all the tube stations in London. This is what I remember doing with it in the '80s. My friends and I found this hilarious. We've got a setting. We'll start with two letters. It chooses the first two letters of the output text, and then chooses the next letter based on the frequency of all the different letters in the original text that follow those first two letters. Then it bumps along and does a bit more. There's two letters here. As it says, we get near gibberish, but recognizably, English, and some of them if you weren't from London, you might think could be a plausible tube station name.
If we crank it up to three letters, get slightly more plausible gibberish. I think South Greathrow is not bad. Hyde Parking Bridge. I'm not sure about Cockfoston, and so it goes. If we crank it up a little bit further, we get to confusingly readable where we'll see frequently, Farring Broadway. We were 17. This stuff is funny, but we really found it hilarious. I think the reason why we found it so funny, is interesting and relevant to where we are now. I think it's because our brains are desperate to find meaning. We're sense making machines.
We bring in sensors to our brain, and then our brain makes a story to ourselves about what it's seen. What this thing shows us is that our brains are so desperate to find meaning that we're like somebody, a narc for a con artist. We're perfectly primed to see intelligence and meaning where there is none. The fact that it's so easy to see meaning in a simple statistical trick like this proves how our brains make us vulnerable.
The Purpose of Life
We are going to have one last dip into the 1980s. I worked with Richard Dawkins, who at the time was famous as the author of, "The Selfish Gene." We worked together on the graphics for a couple of BBC Horizon documentaries. I worked with him on these illustrative animations. They also let me make the end credits, which again seems crazy.
Dawkins: There has to be an initial critical number, a critical mass of [inaudible 00:33:41] that have to get together before they can take off in the evolutionary sense. [inaudible 00:33:48] chance of cooperation.
Ruston: Once again, digging through this old stuff, something I find amazing is that that 8-bit pixelated aesthetic was so mainstream, and that plinky-plonky music, extraordinary. Working with Dawkins did have a huge impact on me. In the years before as a teenager, I'd become what I today you might call a techno-utopian optimist, which has negative connotations to me, priding myself on my rationality.
I was obsessively worried, wondering about the meaning of life. We all are at that age. By the time I met Dawkins, I'd pretty much convinced myself that he was right, that the purpose of life is to pass on your genes. Dawkins was very kind and generous with his time and I learned a lot from him. What I actually learned, what I actually became convinced of is, there's a lot more to human life than passing on our genes. I learned a lesson that I find still guides me every day. It's this, it's surely that if life has a purpose, it is to love and be loved.
I think we need to ground ourselves on that perspective if we're to realize the potential of global collaboration. The fact is we find ourselves working alongside people sometimes who take different sides in a bitterly contested argument. Only love, compassion, and understanding will get us through. We can think that we're in the technology business, but actually, there's the people business. People work together best through love.
See more presentations with transcripts
