In 1952 computer scientist and playful inventor, Marvin Minsky, designed a machine which did one thing, and one thing only. It switched itself off. It was just a box with a motor, switch and something to flip (toggle) the switch off again after someone turned it on. Science fiction writer Arthur C. Clarke thought there was something ‘unspeakably sinister’ about a machine that exists just to switch itself off and hobbyist makers continue to create their own variations today.
A pat on the shoulder In lockdown, during the Covid-19 pandemic, inventor and roboticist Simone Giertz created a coin-operated ‘proud parent machine’ which, for 25 US cents, would pat her on the shoulder and give a few words of encouragement. Putting in a coin sent a signal to a microcontroller that turned a motor on which lowered a 3D-printed arm (to pat her shoulder), then played a pre-recorded audio file telling her how proud of her the automaton was. Making the machine involved skills in woodworking, computer-aided design, mechanics and electronics. She also gave a TED Talk called “Why you should make useless things”.
Elite computer programmers are often called wizards, and one of the first wizards was Christopher Strachey, who went on to be a pioneer of the development of programming languages. The first program he wrote was an Artificial Intelligence program to play draughts: more complicated (and fun) than the programs others were writing at the time. He was not only renowned as a programmer, but also as being amazingly good at debugging – getting them actually to work. On a visit to Alan Turing in Manchester he was given the chance to get his programs working on the Ferranti Mark I computer there. He did so very quickly working through the night to get them working, and even making one play God Save the King on the hooter. He immediately gained a reputation as being a “perfect” programmer. So what was his secret?
No-one writes complex code right first time, and programming teams spend more time testing programs than writing them in the first place to try and find all the bugs – possibly obscure situations where the program doesn’t do what the person wanted. A big part of the skill of programming is to be able to think logically and so be able to work through what the program actually does do, not just what it should do.
So what was Strachey’s secret that made him so good at debugging? When someone came to him with code that didn’t work, but they couldn’t work out why, he would start by asking them to explain how the program worked to him. As they talked, he would sit back, close his eyes and think about something completely different: a Beethoven symphony perhaps. Was this some secret way to tap his own creativity? Well no. What would happen is as the person explained the program to him they would invariable stop at some point and say something like: “Oh. Wait a minute…” and realise their mistake. By getting them to explain he was making them work through in detail how the program worked. Strachey’s reputation would be enhanced yet again.
There is a lesson here for anyone wishing to be a good programmer. Spending time explaining your program is also a good way to find problems. It is also an important part of learning to program, and ultimately becoming a wizard.
Some people’s innovations are so amazing it is hard to know where to start. Sophie Wilson is like that. She helped kick start the original 80’s BBC micro computer craze, then went on to help design the chips in virtually every smartphone ever made. Her more recent innovations are the backbone that is keeping broadband infrastructure going. The amount of money her innovations have made easily runs into tens of billions of dollars, and the companies she helped succeed make hundreds of billions of dollars. It all started with her feeding cows!
While still a student Sophie spent a summer designing a system that could automatically feed cows. It was powered by a microcomputer called the MOS 6502: one of the first really cheap chips. As a result Sophie gained experience in both programming using the 6502’s set of instructions but also embedded computers: the idea that computers can disappear into other everyday objects. After university she quickly got a job as a lead designer at Acorn Computers and extended their version of the BASIC language, adding, for example, a way to name procedures so that it was easier to write large programs by breaking them up into smaller, manageable parts.
Acorn needed a new version of their microcomputer, based on the 6502 processor, to bid for a contract with the BBC for a project to inspire people about the fun of coding. Her boss challenged her to design it and get it working, all in only a week. He also told her someone else in the team had already said they could do it. Taking up the challenge she built the hardware in a few days, soldering while watching the Royal Wedding of Charles and Diana on TV. With a day to go there were still bugs in the software, so she worked through the night debugging. She succeeded and within the week of her taking up the challenge it worked! As a result Acorn won a contract from the BBC, the BBC micro was born and a whole generation were subsequently inspired to code. Many computer scientists, still remember the BBC micro fondly 30 years later.
That would be an amazing lifetime achievement for anyone. Sophie went on to even greater things. Acorn morphed into the company ARM on the back of more of her innovations. Ultimately this was about returning to the idea of embedded computers. The Acorn team realised that embedded computers were the future. As ARM they have done more than anyone to make embedded computing a ubiquitous reality. They set about designing a new chip based on the idea of Reduced Instruction Set Computing (RISC). The trend up to that point was to add ever more complex instructions to the set of programming instructions that computer architectures supported. The result was bloated systems that were hungry for power. The idea behind RISC chips was to do the opposite and design a chip with a small but powerful instruction set. Sophie’s colleague Steve Furber set to work designing the chip’s architecture – essentially the hardware. Sophie herself designed the instructions it had to support – its lowest level programming language. The problem was to come up with the right set of instructions so that each could be executed really, really quickly – getting as much work done in as few clock cycles as possible. Those instructions also had to be versatile enough so that when sequenced together they could do more complicated things quickly too. Other teams from big companies had been struggling to do this well despite all their clout, money and powerful computer mainframes to work on the problem. Sophie did it in her head. She wrote a simulator for it in her BBC BASIC running on the BBC Micro. The resulting architecture and its descendants took over the world, with ARM’s RISC chips running 95% of all smartphones. If you have a smartphone you are probably using an ARM chip. They are also used in game controllers and tablets, drones, televisions, smart cars and homes, smartwatches and fitness trackers. All these applications, and embedded computers generally, need chips that combine speed with low energy needs. That is what RISC delivered allowing the revolution to start.
If you want to thank anyone for your personal mobile devices, not to mention the way our cars, homes, streets and work are now full of helpful gadgets, start by thanking Sophie…and she’s not finished yet!
More on …
LGBTQ+ [part of our Teaching London Computing Diversity pages]
Combine an understanding of science, with electronics skills and the creativity of an artist and you can get inspiring, memorable and fascinating experiences. That is what the Hive, an art instillation at Kew Gardens in London, does. It is a massive sculpture linked to a subtle sound and light experience, surrounded by a wildflower meadow, but based on the work of scientists studying bees.
The Hive is a giant aluminium structure that represents a bee hive. Once inside you see it is covered with LED lights that flicker on and off apparently randomly. They aren’t random though, they are controlled by a real bee hive elsewhere in the gardens. Each pulse of a light represents bees communicating in that real hive where the artist Wolfgang Buttress placed accelerometers. These are simple sensors like those in phones or a BBC micro:bit that sense movement. The sensitive ones in the bee hive pick up vibrations caused by bees communicating with each other The signals generated are used to control lights in the sculpture.
A new way to communicate
This is where the science comes in. The work was inspired by Martin Bencsik’s team at Nottingham Trent University who in 2011 discovered a new kind of communication between bees using vibrations. Before bees are about to swarm, where a large part of the colony split off to create a new hive, they make a specific kind of vibration, as they prepare to leave. The scientists discovered this using the set up copied by Wolfgang Buttress, using accelerometers in bee hives to help them understand bee behaviour. Monitoring hives like this could help scientists understand the current decline of bees, not least because large numbers of bees die when they swarm to search for a new nest.
The Kew Hive has one last experience to surprise you. You can hear vibrations too. In the base of the Hive you can listen to the soundtrack through your teeth. Cover your ears and place a small coffee stirrer style stick between your teeth, and put the other end of the stick in to a slot. Suddenly you can hear the sounds of the bees and music. Vibrations are passing down the stick, through your teeth and bones of your jawbone to be picked up in a different way by your ears.
A clever use of simple electronics has taught scientists something new and created an amazing work of art.
Superheroes always have an origin myth that describes how they emerged as a hero. Spider-man has his spider bite and death of his uncle; Batman, his fall into a cave full of bats and the murder of his parents; Captain Marvel was exposed to an alien energy source… Why not work out your own origin myth? Everyone should have one. Mine involves a beach, a book of programs, and before that a missionary. It is the backstory of how I became a computer scientist.
My origin myth usually begins with a beach and a book containing some programs, some articles about computers and some computing cartoons. The articles were vaguely interesting, some of the cartoons were funny, but the program listings were fascinating: a whole new language that made computers tick.
At that point computers were way too expensive for me to dream of owning one (and in any case back then there were no mobile computers so unlike now, you certainly couldn’t take one to the beach). All I had was my imagination, but that was enough to get me started.
With nothing else to do on the beach (it was too hot to move), I spent my time lying in the sun reading programs and trying to work out what they did and how they did it. With no computer, all I could do was pretend to be the computer myself, stepping through the listings line by line with paper and pen, writing out the changing numbers stored (their variables) and what they printed. I then moved on to writing some simple game programs myself, like a cricket game. I wrote them in my notebook and again pretended I was the computer to make them work. By the end of the holiday I could program.
I didn’t discover this till decades later but Ada Lovelace, the famous Victorian computer pioneer working with Charles Babbage was in a similar position (well sort of … she was a rich countess, I wasn’t). She also had no computer as Babbage hadn’t managed to fully build his. She had no programming language either to write programs in, or for that matter any actual programs to read. However, she had some algorithms written by Babbage that he intended his machine’s programs would be based on. Just like me, she stepped through the algorithms on paper, working out what they would do (should Babbage ever build his computer), step by step. As a result she learnt about the machine and as it happens also found a mistake in one algorithm. The table she drew of the computer working is often taken as proof she was the ‘first programmer’, though as Ursula Martin, who studied her papers, has pointed out, it is not a program. It is an execution trace or ‘dry run table’. She was actually the first ‘execution tracer’ or ‘dry-runner’.
The importance of dry running code
Dry running programs like this on paper is not just a useful thing for people with no computer, it is also a critical thing for anyone learning to program to do – a way of actively reading programs. You didn’t learn to write English (or any other language) by just writing, you read lots too and the same goes for programming. It turns out that the way I taught myself to program is a really, really powerful way to do so.
Just as importantly dry running programs on paper in this way is also important as a way of checking that programs work as Lovelace found. The modern version is the code walkthrough – a powerful technique that complements testing programs as a way of discovering problems.
While that is the point in time when I learnt to program, there was someone earlier who originally inspired me about computation: a missionary. Sadly I don’t know his name, but he came to our school to talk about his life as a missionary in Papua New Guinea. He told us that one of the problems of travelling there was that communities were isolated from each other and each village spoke its own language. That meant that, as he travelled around, he had a big problem speaking to anyone. Every time he moved on he had a new language to learn or an old one of many to remember. It wasn’t the idea of converting people, or travelling to exotic places that means I remember him more than 40 years later. It was what he showed us next: how he solved the problem. He pulled out a massive pile of cards with holes punched round the edges, labelled with letters. Each had a word written on it in English as well as words in other languages from different places. He spelled out a word a letter at a time (pig was the example he used) by putting a knitting needle through a hole in all the cards next to the letter. Those that fell out were used for the next letter and so on. After three rounds just the card for pig fell out, as if by magic. It wasn’t magic though, it was computation. On the pig card he had cut notches in the holes for p, i and g. As that was the only word with those letters, it was the only card that could fall out for all three letters and then he could read off the translation for the village he was in..
Bitten by a bug
What the missionary was showing us was an edge-notched card system (see the ‘Wood computer’, page 16). I was fascinated and have been ever since about computation, especially when it’s done physically. It was that general fascination for algorithms that led me to want to learn to program.
In my origin story, I was bitten by a bug: the missionary converted me… to computer science.
by Peter W McOwan and Paul Curzon, Queen Mary University of London
(from the archive)
By understanding the way hoverflies mate, computer scientists found a way to sneak up on humans, giving a way to make games harder.
When hoverflies get the hots for each other they make some interesting moves. Biologists had noticed that as one hoverfly moves towards a second to try and mate, the approaching fly doesn’t go in a straight line. It makes a strange curved flight. Peter and his student Andrew Anderson thought this was an interesting observation and started to look at why it might be. They came up with a cunning idea. The hoverfly was trying to sneak up on its prospective mate unseen.
The route the approaching fly takes matches the movements of the prospective mate in such a way that, to the mate, the fly in the distance looks like it’s far away and ‘probably’ stationary.
How does it do this? Imagine you are walking across a field with a single tree in it, and a friend is trying to sneak up on you. Your friend starts at the tree and moves in such a way that they are always in direct line of sight between your current position and the tree. As they move towards you they are always silhouetted against the tree. Their motion towards you is mimicking the stationary tree’s apparent motion as you walk past it… and that’s just what the hoverfly does when approaching a mate. It’s a stealth technique called ‘active motion camouflage’.
By building a computer model of the mating flies, the team were able to show that this complex behaviour can actually be done with only a small amount of ‘brain power’. They went on to show that humans are also fooled by active motion camouflage. They did this by creating a computer game where you had to dodge missiles. Some of those missiles used active motion camouflage. The missiles using the fly trick were the most difficult to spot.
It just goes to show: there is such a thing as a useful computer bug.
Edge-notched cards (see the Wood Computer) implement a physical, but still powerful, version of a database: an organised way of storing data. Information about some specific thing is represented on the card by cutting notches into holes around the edges following a set of codes.
Databases consist of lots of records each storing the information about one thing like one kind of timber. Each card in our pack corresponds to a record. A whole pack of records about one thing (like our pack of cards) is a database table. Records consist of fields with each field describing some aspect of the data like what the grain of the timber is like. Each group of related notches therefore acts as a database field.
In a relational database you do not have one gigantic set of records, so not just one gigantic pack of cards. You have a series of different sets of records/cards. Each has fewer fields so fewer holes as they no longer need to store details of every possible feature. Each smaller pack of cards is a table describing a specific thing (so if the cards store information about trees, the smaller packs might be about features of leaves and bark). There is also still a master pack describing trees as a whole. The tree cards no longer have to include all the details of leaves and bark, however. Instead each table includes a unique identifier field. Leaf cards include a leaf identifier that is also on the tree’s card. Bark cards similarly include a bark identifier. Once you have identified the leaf, you can use the leaf identifier on the tree cards to find any trees with that set of properties of leaf, then narrow it down further once you know the bark identifier. The smaller packs of cards still do the job but in a much more convenient way.
Punch cards inspired Babbage as he invented the first Victorian computer, and were a way the first computers stored data a hundred years later. Variations, called edge-notched cards, had their uses before the first working computers, though. They provided an efficient way to look up information. One use was to help identify timber: Oxford’s human-operated ‘wood computer’ was used in forests world-wide.
Interested in nature and enjoying a nice walk, you come across an unfamiliar tree, and want to identify it. How do you do it? You might work through a set of questions, first looking at the leaves: what shape are they, what colour, do they have stalks, do they sit opposite each other on a twig or are they diagonally placed, and so on. You then move to questions about the bark… Gradually, you narrow it down to one tree. What, though, if your job is to check that your company is buying the right timber and the tree is cut up into logs (no leaves or bark)? The task is the same, going through a checklist of questions, just harder unless you are an experienced botanist. Now you consider things like the pattern of the grain, the hardness, the colour and any scent from the tree’s oils.
Historically, one way of working out which piece of timber was in front of you was to use a wood identification kit or ‘wood computer’. This was prepared (programmed!) from a pack of index cards with 60 or more features of timber printed on them. However, they weren’t just cards to read but cards to compute with.
Holes and notches
The cards were special because they had regularly placed holes round all four sides. Each card had notches cut into different holes. Each feature of the timber was linked to one or more holes. The features were grouped together around related properties: so, for example, all the possible colours of timber might be grouped together on one section of the card. Properties about how fine-grained the timber is would be grouped in another section.
Each card represented one type of wood and the ‘programmer’ of the cards would notch the holes next to the features that defined it. If a particular type of timber was fine-grained you would add the notch to the hole next to “fine-grained”, if it wasn’t that hole would be left un-notched. Notches were added for all relevant timber properties making each card unique, with a slightly different pattern of notches, uniquely describing the features of the tree it represents. (See an example of an edge-notched card below.)
How it works
To use a wood computer, take the pile of cards, pick a feature of the timber in front of you and insert a thin knitting needle into the hole linked to the feature. Then lifting the pile up shake out any cards with notches in that hole. All of the cards for timber that don’t have that feature will have an un-notched hole and will hang from your knitting needle. All cards representing timber that does have that feature are now sitting on the table. Yours is somewhere amongst them. If your timber is NOT fine-grained then instead, when you put the knitting needle in the fine-grained hole, keep those left on the knitting needle.
You repeat the process several times to whittle (sorry!) your cards down, each time choosing another feature of the timber in front of you. Eventually you have only one card left and have identified your timber.
Just the cards for the job
The cards are incredibly low tech, requiring no electricity or phone signal and are very easy to use even without specialist botanical knowledge. All the knowledge is programmed into them. You also find the answer very quickly. Margaret Chattaway, a botanist at the Imperial Forestry Institute, Oxford, in the 1930s realised that was exactly what was needed for their team inspecting timber and so the original wood computer was created.
So next time you are out for a walk, make sure you have your knitting needle and a suitable pile of cards with you. Then identifying trees, birds, fungi or even animal poo will be so much quicker and simpler.
by Adrian Johnstone, Royal Holloway, University of London and Paul Curzon, Queen Mary University of London
Despite his hatred of Barrel organs, Babbage used barrels with relocatable pins in his machines. They worked in a similar way to a music box, where the pins flip the teeth of a metal comb to sound a note and by moving the pins you get a different tune. In Babbage’s version the barrel’s pins push levers that send information round the machine, determining what it does.
By programming the positions of the pins, different overall operations are created from the combinations of lever pushes. This is a similar idea to what later became called microcoding, in modern computers, where very simple low level instructions are used to program the operations available in a computer’s instruction set.