Free to code

This week at the Cloudflare Internet Summit I have the honour of sitting down and talking with Sophie Wilson. She designed the very first ARM processor instruction set in the mid-1980s and was part of the small team that built the foundations for the mobile world we live in: if you are reading this on a mobile device, like a phone or tablet, it almost certainly has an ARM processor in it.

But, despite the amazing success of ARM, it’s not the processor that I think of when I think of Sophie Wilson. It’s the BBC Micro, the first computer I ever owned. And it’s the computer on which Wilson and others created ARM despite it having just an 8-bit 6502 processor and 32k of RAM.

Luckily, I still own that machine and recently plugged it into a TV set and turned it on to make sure it was still working 36 years on (you can read about that one time blue smoke came out of it and my repair). I wanted to experience once more the machine Sophie Wilson helped to design. One vital component of that machine was BBC BASIC, stored in a ROM chip on the computer’s motherboard. She wrote the code on that ROM.

Understandably, BASIC seems old-fashioned, useless and simplistic these days but I was struck by something as I switched on that machine: it booted instantaneously (anyone who used a BBC Micro will be familiar with the two tone boot sound) and I was presented with a prompt without any delay.

Could I immediately write and run code? Yes, I could, and so I did (see below and click here to listen to that program running). And that’s all programmers really want, isn’t it? The ability to write code and run it; the ability to express to the machine their thoughts and have those thoughts turn from the ephemeral into the real.

Ideally, nothing gets in the way of the jump from brain to CPU. Anything that does is a useless distraction. Which is why you see programmers complaining bitterly about keyboards and buying custom keys. And it’s why you’ll see them wearing headphones to avoid distractions when they get into the magical zone where code seems to flow from the imagination onto the screen.

And for the same reason some languages have a REPL (read, edit, print loop) so that code can be written, modified and run without distraction. And it’s why the venerable make program has default options that mean you can perform common tasks (like compiling a program to an executable) without even having a Makefile at all:

$ ls
helloworld.c
$ cat helloworld.c
#include <stdio.h>

int main(int argc, char* argv[]) {
  printf("Hello, World!\n");
}
$ make helloworld
cc     helloworld.c   -o helloworld
$ ./helloworld
Hello, World!

It shouldn’t then be a surprise that the last thing programmers really want to think about when programming is the computer and its complexities. Anyone who’s worked with manual tools will know that the brain incorporates those tools as if they were part of the body. Programmers experience a similar feeling and then an almost visceral sensation when something doesn’t work correctly and a program can’t run.

A very common source of trouble is the difference between “it works on my laptop” and “it fails in production”. Programmers configure their laptops to maximize their productivity but subtle differences between the laptop and production server (such as different versions of a system library) mean that beautifully crafted code can suddenly fail to run at all because of some irritating, and irrelevant, mismatch.

All programmers know that pure exasperation of seeing their code fail to run because of some mere configuration problem.

To solve this, first Virtual Machines and then Containers have been proposed as ways for the so-called environment (all the things that a program needs to run like memory and CPU and an operating system and libraries) can be duplicated between laptop and server to make the transition to production as smooth as possible.

Recently a new buzzword has appeared: serverless. As I said above programmers really don’t want to think about computers: they want running code. Serverless promises just that: push code to production and it’ll run somewhere, who cares where, who cares how? Much fun is made of the fact that, of course, there are servers running code even when it’s called ‘serverless’.

But ‘serverless’ expresses the desire to neither know nor care about the how or where.

Cloudflare has its own serverless platform that runs in every one of our machines across the globe. We call it Cloudflare Workers: push code to us through our API and it’ll be available everywhere on the planet within seconds. It’s augmented by our Workers KV service that provides a global, key-value store accessible from within a Worker.

Until today Cloudflare Workers code had to be written in JavaScript. That changed with the release of WebAssembly on the Workers platform. Now you can write in any language that compiles to WebAssembly and deploy that code to the Cloudflare network. Frictionless development and deployment on a serverless platform in your language of choice.

That’s all programmers really want.

Now, if you don’t mind, I’m switching my BBC Micro to the Acornsoft LISP ROM, because I’ve got a REPL to run.