Enter the maze

Smart Translation

Computers don't speak English, or Urdu or Cantonese for that matter. They have their own special languages that human programmers have to learn if they want to create new applications. Even those programming languages aren't the language computers really speak. They only understand 1s and 0s. The programmers have to employ translators to convert what they say into Computerese (actually binary): just as if I wanted to speak with someone from Poland, I'd need a polish translator. Computer translators aren't called translators though. They are called ‘compilers', and just as it might be a Pole who translated for me into Polish, compilers are special programs that can take text written in a programming language and convert it into binary.

Motorway Lights as cars pass in a blur

The development of good compilers has been one of the most important advancements from the early years of computing and Fran Allen, one of the star researchers of computer giant, IBM, was awarded the 'Turing Prize' for her contribution. It is the Computer Science equivalent of a Nobel Prize. Not bad given she only joined IBM to clear her student debts from University.

Fran was a pioneer with her groundbreaking work on 'optimizing compilers'. Translating isn't just about taking a word at a time and substituting each for the word in the new language. You get gibberish that way. The same goes for computer languages.

Things written in programming languages are not just any old text. They are instructions. You actually translate chunks of instructions together in one go. You also add a lot of detail to the program in the translation, filling in every little step.

Suppose a Japanese tourist used an interpreter to ask me for directions of how to get to Sheffield from Leeds. I might explain it as:

"Follow the M1 South from Junction 43 to Junction 33".

If the Japanese translator explained it as a compiler would they might actually say (in Japanese):

"Take the M1 South from Junction 43 as far as Junction 42, then follow the M1 South from Junction 42 as far as Junction 41, then follow ... from Junction 34 as far as Junction 33".

Computers actually need all the minute detail to follow the instructions.

The most important thing about computer instructions (i.e., programs) is usually how fast following them leads to the job getting done. Imagine I was on the Information desk at Heathrow airport and the tourist wanted to get to Sheffield. I've never done that journey. I do know how to get from Heathrow to Leeds as I've done it a lot. I've also gone from Leeds to Sheffield a lot, so I know that journey too. So the easiest way for me to give instructions for getting from London to Sheffield, without much thought and be sure it gets the tourist there might be to say:

Go from Heathrow to Leeds:

1. Take the M4 West to Junction 4B
2. Take the M25 clockwise to Junction 21
3. Take the M1 North to Leeds at Junction 43

Then go from Leeds to Sheffield:

4. Take the M1 South to Sheffield at Junction 33

That is easy to write and made up of instructions I've written before perhaps. Programmers reuse instructions like this a lot - it both saves their time and reduces the chances of introducing mistakes into the instructions. That isn't the optimum way to do the journey of course. You pass the turn off for Sheffield on the way up. An optimizing compiler is an intelligent compiler. It looks for inefficiency and actually converts it into a shorter and faster set of instructions. The Japanese translator, if acting like an optimizing compiler, would actually remove the redundant instructions and simplify it to:

1. Take the M4 West to Junction 4B
2. Take the M25 clockwise to Junction 21
3. Take the M1 North to Sheffield Junction 33

Much faster! Much more intelligent! Happier tourists!

Next time you take the speed of your computer for granted, remember it is not just that fast because the hardware is quick, but because, thanks to people like Fran Allen, the compilers don't just do what the programmers tell them to do. They are far smarter than that.