From numbers to words: how people talk to processors

Pick up your phone and count the apps. WhatsApp, your bank, the camera, the calculator, a game, Inova. Every one of them is a program — a list of instructions, like Tiny's in Lesson 3.5 — and every one was written by people.

Now think about what writing one would mean in the way you learnt. Tiny's little budget program took nine instructions, each a number like 28 or 104, and it only added two prices. WhatsApp is millions of instructions. If the people who built it had to write every one as a number, getting every bit right, it would never have been finished.

Nobody writes programs like that any more. Somewhere between the Manchester Baby in 1948 and the phone in your hand, people found a way to tell the rock what to do in something much closer to human language — and to make the computer itself translate those words into the numbers it actually runs. This lesson tells that story, and shows you what really happens to a line of code between your keyboard and the processor. It is the moment the machine you built in Modules 1 to 4 becomes something anyone can command.

Words in this lesson

The problem with numbers

Here is Tiny's budget program again, exactly as the processor sees it in memory:

28 45 79 30 63 104 26 75 0

Nine numbers. Can you tell, by looking, what this does? Neither can anyone else. Now imagine finding a mistake in it — say one instruction should have used box 13 instead of box 12. You would have to work out which number was wrong, convert it to bits, change the right bits, and convert back. One slip, and the program does something completely different, with no warning.

That was the reality of early programming. The Computer History Museum describes programming before the mid-1950s as writing instructions directly in machine language — a slow and error-prone process. IBM says that before its Fortran language, programmers had to key in as many as a thousand program instructions by hand to solve a single problem.

Something had to change. And the change came from a beautifully simple idea: let the computer do the translating.

Giving instructions names: assembly language

The first step was small. Instead of writing 28, write LOAD 12. Instead of 45, write ADD 13. You did exactly this in Lesson 3.5, when you wrote Tiny's program as names and then worked out the numbers.

Writing instructions with short names like this is called assembly language. And here is the clever part: converting LOAD 12 into 28 is a perfectly mechanical job — look up the code for LOAD (0001), write the box number in binary (1100), put them together. Mechanical jobs are exactly what computers are good at. So people wrote a program to do it: an assembler, which reads assembly language and writes out machine code.

This was a quiet revolution. It was the first time a program wrote another program. Every assembly instruction still matched exactly one machine instruction, so programmers still had to think like the processor. But at least they could read what they had written.

Languages that look like the problem: Hopper and Fortran

The next idea was bigger. Why should a person think like a processor at all? Why not write in something closer to the problem itself — mathematics for scientists, plain words for business — and let a program work out all the machine instructions needed?

One of the people who pushed hardest for this was Grace Hopper, an American mathematician and naval officer who worked on some of the earliest commercial computers. According to Yale University, where she studied, in 1952 she developed a compiler called A-0, which translated mathematical code into machine-readable code; the Computer History Museum describes A-0 as often considered the first compiler. By 1956, Yale says, her team was running FLOW-MATIC, the first programming language to use word commands — everyday English words, for business data processing. That work fed into COBOL, a business language that Hopper is widely recognised for helping design. Its reach was astonishing: the Computer History Museum notes that by 1997, over 200 billion lines of COBOL were still running on critical systems around the world.

Meanwhile at IBM, a team led by John Backus built Fortran — short for "formula translation" — released commercially in 1957. IBM's history describes the difference it made: a problem that had needed as many as a thousand instructions keyed in by hand could be written in 47 statements in Fortran. Scientists and engineers could write something close to the mathematics they already knew, and a program turned it into machine code.

The languages you will meet today — Python, JavaScript, C, Java and hundreds of others — all come from this idea. Python, which Inova teaches in its own course, was created in the early 1990s by Guido van Rossum at a research centre in the Netherlands, according to Python's official documentation.

Compilers and interpreters: two ways to translate

There are two main ways a program written in a language becomes something the processor can run.

A compiler translates the whole program into machine code before it runs, and saves the result. Think of translating a book: the translator works through it once, produces a translated copy, and from then on readers use the copy. The original author's words never need to be translated again. Most of the apps you install arrived already compiled — that is why you cannot read them.

An interpreter reads the program and carries it out step by step, as it goes, translating each part as it reaches it. Think of a live interpreter at a meeting between a Yoruba-speaking chief and a French-speaking visitor: nothing is written down; each sentence is translated as it is spoken. Python's official tutorial describes Python as an interpreted language, saying this can save considerable time during development because no separate compilation step is needed. The JavaScript in the websites you visit is run by your web browser as the page loads.

Each has its strengths. Compiled programs usually run faster, because the translating was done in advance. Interpreted programs are quicker to change and try out, which is why beginners often start with languages like Python. In practice, many modern systems mix the two. What matters is the idea they share: people write in a language; a program turns it into machine code.

One line becomes many instructions

Here is the budget decision from Lesson 3.5, written in Python:

total = rice + oil
if total > budget:
    print("Over budget")

Three lines. You can probably read them already, without any training: add the rice and oil prices to get a total; if the total is more than the budget, show the message "Over budget".

Compare that with Tiny's nine numbered instructions with their boxes, their LOAD and STORE and JUMPNEG. Python's translator does all of that work for you: it decides which memory boxes to use, loads the numbers, uses the processor's adder, compares, and jumps — and then, for that one word print, runs many more instructions to turn the letters into Unicode numbers (Lesson 2.3), draw their shapes as pixels (Lesson 2.4) and put them on the screen. One readable line can become hundreds or thousands of machine instructions.

The same program on different processors

There is a second gift. Different families of processor understand different machine codes, just as Tiny's codes are not the same as a real processor's. Apple's own developer documentation shows this clearly: an app for the Mac can be built as a "universal" program that runs natively on both Apple's own chips and Intel-based Macs, because it contains machine code for both — the same source code, translated twice, once for each kind of processor.

That is the power of languages: you write the program once, in words, and translators turn it into the right numbers for whatever processor will run it.

What software really is

You can now answer a question that most people who use computers every day never ask: what, exactly, is software?

Software is not a substance and not magic. It is instructions and data, stored as numbers — in storage when it is installed, copied into RAM when it runs (Lesson 4.3), and fetched, decoded and executed by the processor, billions of times a second (Lesson 3.5). People write it in programming languages; compilers and interpreters translate it into machine code.

In Lesson 1.1, you were promised that you would learn exactly how the power of software works. Here it is. The hardware — sand, switches, gates, memory — never changes after it leaves the factory. Everything that makes your phone a calculator one minute, a camera the next and a bank after that is software: different numbers in memory, telling the same switches to do different things. The Manchester Baby in 1948 made that possible; languages made it practical for millions of people to write.

One last distinction you will meet often at Inova: HTML, which Inova's HTML course teaches, is a language for describing a page — this is a heading, this is a paragraph, this is a picture — rather than a list of steps for the processor to follow. That is why it is called a markup language. The step-by-step instructions that make a page interactive are usually written in JavaScript. Both are translated and run by your web browser — which is itself a program, written in a programming language, compiled into machine code, running on the switches you now understand.

Common mistakes

The short version

• Early programs were written as machine code — numbers — which was slow and error-prone. IBM says one problem could need a thousand hand-keyed instructions.
• Assembly language gave instructions names like LOAD and ADD, and an assembler — a program — turned them into numbers.
• Grace Hopper developed the A-0 compiler in 1952 and led work on languages using English words. IBM's Fortran (1957) let a thousand-instruction job be written in 47 statements.
• A compiler translates a whole program in advance; an interpreter carries it out step by step. Python is usually interpreted.
• One readable line can become hundreds of machine instructions, and the same source code can be translated for different processors.
• Software is instructions and data stored as numbers. Hardware stays the same; software makes it do different things.

Try it yourself

Watch words become instructions.

1. Write Tiny's budget program three ways side by side: as machine-code numbers, as assembly (LOAD 12 and so on), and in plain English sentences. Which would you rather fix if one part were wrong?
2. Read the three lines of Python in this lesson aloud to someone who has never programmed. Can they say what it does? What does that tell you about why languages were invented?
3. Open any web page, right-click on it, and choose View page source (in Chrome, Edge or Firefox). You are looking at the HTML that describes the page. Find one heading and one paragraph in it. Look for the word script — that marks where JavaScript begins.
4. Write, in plain numbered steps, a program for something you do: sending airtime to a friend, or deciding what to wear. Then circle every step that is a decision, and every step that repeats. Those are the places a real language would use if and a loop.
5. Explain to someone the difference between a compiler and an interpreter using the book translator and the meeting interpreter.

You'll know you've got it when you can explain how a line someone types in Python ends up as switches flicking in a processor — and why, since the 1950s, almost nobody has had to write those numbers by hand.