Speaking to Computers
Computers are good at doing their job, but you should remember to tell them to do it.
Computers are good at doing their job, but you should remember to tell them to do it.
Have you ever spoken to a computer?
I don’t mean saying hi to Siri or Alexa, or asking Google what the weather is. Those are just simple question-and-answer sessions, or disjoint chats about changing topics. What I mean is, have you had a proper conversation with a computer, where you describe abstract concepts at length and have them worked upon?
Perhaps I’m not using the right words. “Speaking” tends to suggest a quick back-and-forth, not long paragraphs of description.
Maybe I should say: have you written to a computer? Not in some strange foreign language like English, but actually in the computers’ native tongue? You write down long passages with detailed instructions. The computer reads them, understands them, acts upon them, and finally gives you the result.
But wait — did I say “native tongue”? What is the native tongue of a computer?
In the end, a computer is just a complicated network of switches, with circuits to connect them. And switches can only do two things: they can go on, or they can go off. That’s why people speak of computers working in “binary”, or running “with ones and zeroes”. In that context, ‘1’ is just a way of saying “on”, and ‘0’ is just a way of saying “off”.
So if you want to speak to a computer in their real native tongue, you’ll have to flick the correct switches, at the the correct time, and very, very fast.
That’s why nobody speaks to their computer in pure binary. It’s so hard to do, they might as well just go and do the work themselves. Instead, they’ve made special circuits that control the other circuits, and still more circuits to control those circuits, and finally got the languages up to a level that humans can work with.
Those languages are called ‘programming languages’.
Programming languages are somewhere in between human languages and binary ones. They don’t arise naturally, but are specially designed for humans to be able to write instructions, and for computers to be able to read them. That’s because, usually, those instructions need to be very precise. So if you tried to write them in English, you’d have to be a very good lawyer.
These programming languages are very precise. Every instruction you give can only mean one thing and nothing else. The computer can read them and carry out the exact instructions, depending on what you said.
Note that I said “depending on what you said”. Not what you meant to say, or what you thought you said, but what you actually did say. And that’s where the challenge of programming lies: not in learning how to speak the language, but in deciding what to say.
Computers are very good at doing their job, but you have to remember to tell them to do it.
When people are writing a program, they have to think very carefully about every possible situation and tell the computer how to handle it. It’s a bit like having a robot which can do anything you ask, but which needs detailed instructions for every step. If you wanted that robot to fetch you a chocolate from the fridge, here’s what you might tell it to do:
* Walk to the fridge* Open the fridge door* Do this for each item in the fridge:
* If the item is a chocolate, then:
* pick up the item with your right hand
* stop doing ‘this’
* Otherwise, move on to the next item* Close the fridge door* Walk here* Give me the object that is in your right hand
At first, that looks very nice and detailed. The robot goes to the fridge, looks at each item until it finds a chocolate, picks up the chocolate, closes the fridge door, and comes back to give it to you. Everything taken care of, nothing left out.
Well, not exactly.
Suppose you (okay, it wasn’t you; must have been someone else) left the fridge open by mistake. The robot will go up to the fridge — and then get stuck and Step 2. It won’t be able to open the door, because the door will already be open!
That sounds ridiculous, but it’s the kind of thing that keeps programmers busy. And, from the robot’s point of view, it could well be what you intended. Suppose it was the switch of a toaster, not the door of the fridge, that needed to be moved. You’d want the robot to wait till the previous person’s toast popped up, and not try to stuff your toast in on top of it.
In our case, all we have to do is modify Step 2, to make it look like this:
* If the fridge door is closed, open the fridge door
Oh, but there’s also another problem. What if there’s no chocolate in the fridge? Will the robot stop? Will it keep searching again and again? Or will get stuck trying to move on to the “next item” because there’s no “next item” to move to?
Remembering and writing down all these instructions can get a bit tedious — especially if all you want is a piece of chocolate. That’s why people have a way to save the instructions and reuse them later. Several ways, in fact.
To start with, you can write down those instructions and save them as a very small ‘program’. You can name it something like ChocolateFetcher. Tiny, single-purpose programs are often used by programmers, who call the “scripts”.
But are simple programs enough? What if you want to make a program that fetches you chocolate and does other things as well (such as making you a toast)? Surely you wouldn’t want to rewrite the whole set of chocolate-fetching instructions in every place where chocolates need to be fetched?
In that case, you can make a ‘function’. A function is basically like a new word. “From now on”, you can say, “getMeAChocolate means this — ”
…and you can go on to list the instructions I mentioned earlier (with all your edits and corrections, of course).
Now, you can use that function in other instructions, like this:
* When I snap my fingers, getMeAChocolate()
Why are the brackets there? Programming languages usually have them when functions are being used. That’s in case you functions lets you give additional details on how to run. For example, you might have a function getFromFridge(thing)
that gets whatever thing
you ask for. You could use that function to do something like this:
* When I snap my fingers, getFromFridge(chocolate)
That’s the same as saying getMeAChocolate
— but now, you can also ask for something else:
* When I scream, getFromFridge(ice-cream)
As you can see, this function will be very useful. Lots of people want to get stuff from their fridges. (That’s why the have fridges in the first place!). Luckily for them, there’s a way to take many useful functions like that and collect them in a ‘library’.
A library sis a program that doesn’t actually do anything on its own. It just has lots of new words (I mean, functions) that other programs can borrow to do their work more easily.
Instead of re-writing getFromFridge
for every program, you just have to write it once and keep it in a library. Then, when you write your other programs, you can ‘borrow’ the getFromFridge
function from that library and use it to do your own stuff.
Popular programming languages have libraries for everything. Over time people have written functions for reading your keyboards, drawing things on the screen, connecting to the Internet, writing information to a file, and almost anything else you can think of.
You don’t need to know how the functions work: you just need the words to run them. As you program, that’s what you’ll spend a lot of your time doing: reading up on new words, and learning when and how to used them.
Once you’ve learnt the basics of the language, most of what’s left is just an advanced version of looking up a dictionary. It’s much simpler than having to manipulate zeroes and ones.
That’s why you’ve probably never spoken directly to a computer in its native tongue. And it’s why I haven’t either.
Have something to say? At Snipette, we encourage questions, comments, corrections and clarifications — even if they are something that can be easily Googled! Or you can simply click on the ‘👏 clap’ button, to tell us how much you liked reading this.