The White Room: Understanding Programming

Understanding programming can be challenging because programming is an abstract subject. Except, it isn’t. Everything in programming is based on concrete actions that happen within your computer. Indeed, everything ultimately comes down to physical processes that occur in the electronics within the computer.

This all sounds very good in theory, but do you need to understand the physics and electronics of what happens in a computer to write computer programs? No. Absolutely not. The whole point of programming languages, especially high-level languages such as Python, is that you can communicate with the computer using a common language—one that you and the computer both understand. This is good. But it also shifts programming further towards the abstract end of the abstract-concrete spectrum.

This can be a challenge, especially for a beginner who’s just starting to get to grips with coding.

The White Room is an analogy for understanding programming. It makes programming more concrete and easier to understand without studying electronics! It explains what happens behind the scenes when you run a computer program. Once you understand the White Room, programming will get a bit easier.

The White Room

Picture a medium-sized empty room. The walls are white. The floor and ceiling are also white. The White Room represents the place where your computer program will run. You’ll meet the computer program shortly. Any resources that the computer program needs to perform the tasks will be in this White Room.

When you create a new, blank Python file in your editor, you’re creating a White Room, ready to host the computer program.

Meet Monty

The White Room is the environment in which the computer program will run. It’s the computer program that will need to do the hard work! Let’s give the computer program a face and a name so that you can picture what’s happening in this analogy better.

Meet Monty, the computer program. Yes, that’s a nod to the TV series which Python’s creator Guido van Rossum used as inspiration for the name of the language. If you’re a Monty Python fan, you can use your favourite Python from the series to visualise Monty!

Monty springs into action when you run a Python program, ready to perform the actions you ask him to do through your code.

Shelves on The Wall

When you create a new White Room by creating a new Python file, the White Room is not quite empty. On one of the four walls, there are several shelves on which Monty will be able to store things that he’ll need as he works his way through the tasks he needs to perform.

There’s also one other thing that’s always available in the White Room, even before you’ve written a single line of code. On the lower shelf, there’s a thin red booklet with the title built-in. This booklet contains information about parts of the Python language that Monty can use right away. It includes functions such as print() and input(), and values such as True and False, and more.

If you had to place Monty in a completely empty room, then he’ll have no resources to get started with, and he won’t be able to get anything done.

Let’s see what happens when you create a new .py file and run the following code:

When you run this script, Monty springs into action. In the first line, you’re asking him to look for the name print. The only place for him to look is in the only thing that’s in the White Room at the moment: the little booklet on the bottom shelf. Monty finds the word print in there and gives you a thumbs-up. You’re not asking him to do anything once he finds this name, as there are no parentheses after the print on line 1.

Monty then moves on to read the second line of code. You want him to find the name say_hello. He looks in the booklet, but he cannot see this name. He looks around the room, but there’s nothing else. Monty tells you the following:

Traceback (most recent call last):
  File "<path>/<filename>.py", line 2, in <module>
    say_hello
NameError: name 'say_hello' is not defined

Monty can’t find the name say_hello anywhere in the White Room. He doesn’t know what to do, so he complains to you that he can’t carry on working!

Books From The Library

There aren’t many pages in the little booklet that’s in every White Room. However, Python is a very rich language. Elsewhere, outside the White Room, there’s a vast library. I like to picture one of those very large library halls with high ceilings and books covering all the walls from floor to ceiling. Each book is a module that has information about a specific topic that you Python for.

Let’s see what happens with the following code:

In the first line, you’re asking Monty to leave the White Room and go for a stroll to the library. Once he’s in the library, he’ll look for a book called random, and he’ll bring it back to the White Room. Monty will then place the random book on one of the shelves in the White Room.

Monty can now move on to the following line of code. He’ll look for print which he’ll find in the built-in booklet. You’re now asking him to do whatever print is meant to do, which he can read in the booklet.

Monty will then read the word random. He’ll look around the White Room for this word. Although he won’t find this name in the built-in booklet, Monty will see the book with the title random on one of the shelves.

The full stop or period after random tells Monty to open the book and look for the name randint inside the random book. When Monty finds this name, he’ll know what to do!

Boxes to Store Things

You’ll recall that earlier on, Monty couldn’t find the name say_hello. Let’s try to write the following code:

The assignment on line 1 asks Monty to bring an empty box and stick a label on the outside of the box with the name say_hello. He will then create a string with the characters shown and store this data in the box. Monty will then place the box labelled say_hello on one of the shelves in the White Room.

When Monty reads the name say_hello on line 3, he’ll look around the room and find a box labelled say_hello. He’ll look inside the box and get its contents out, which in this case is the string.

Let’s look at a modified version of the code:

On the last line, you’re again asking Monty to bring a box and label it say_hello, but you cannot have the same name used twice anywhere in the White Room. Monty will first dispose of the contents of the box labelled say_hello and then put the integer 42 in the box. The original string is gone as it’s not being stored anywhere anymore. The rubbish bin in the White Room is a special one which gets emptied very quickly, so the information is gone forever from the White Room!

Let’s add a few more lines:

Monty now has a line asking him to label a box with the name meaning_of_life. I’m “mixing metaphors” here as I move from Monty Python to The Hitchhiker’s Guide to the Galaxy, but you’ll forgive me for this! This label should go on the thing named say_hello, which is itself a storage box. So Monty puts a second label on the box, and this box now has two labels.

Whichever label you use later on in the program, Monty will fetch the same box and get its contents out. Both lines with the print() function will display the number 42.

Next, let’s extend this analogy to include defining functions.

The Function Room

A function is a self-contained unit of code that performs a specific action. Indeed, a function is a mini-program, not too different from a full program. For this reason, you can think of a function as another room, similar to the White Room. I’ll call this the Function Room.

Let’s see what happens when you define a function:

When you define a function, you’re creating a new Function Room adjacent to the White Room. There’s a door that leads to the Function Room, and the label on the door says do_clever_stuff. This is the name of the function.

Whatever happens inside the function definition happens in the Function Room and not in the White Room. The box labelled stuff with the integer 10 stored within it is placed on the shelves in the Function Room. When the print() function is called inside the Function Room, there are no problems as Monty will find a box with the name stuff.

However, when the name stuff is used in the White Room, which represents the main program, Monty can’t find any reference to this name anywhere in the White Room. And what does Monty do when he can’t find a name? He complains:

Traceback (most recent call last):
  File "<path>/<filename>.py", line 5, in <module>
    print(stuff)
NameError: name 'stuff' is not defined

This error refers to line 5, the last line with the print() function in the main program. The box labelled stuff is available in the Function Room but not in the White Room. Next, you can call the function from the main program:

On the last line, Monty reads the name do_clever_things. When he looks around the White Room, he’ll find this name as a label on a door that leads to another room. Monty identifies this as the name of a function. When Monty reads the parentheses after the name, he knows to make his way through the door labelled do_clever_things and enter the Function Room to perform the actions needed in that room. When he’s finished all the function’s steps, Monty will make his way back to the White Room, and he’ll close the door to the Function Room behind him.

Let’s go a bit further with this analogy:

You’ve made the function perform some highly complex arithmetic (!) and then you used the return statement in the function. When Monty finds a return in a function, he’ll take some information back with him when he returns to the White Room.

However, Monty does not take the box labelled stuff from the Function Room to the White Room. Instead, he only takes the contents of the box with him. This is a subtle but important difference. Let’s see why.

When you run the code above, you’ll get Monty’s now-familiar complaint:

Traceback (most recent call last):
  File "<path>/<filename>.py", line 8, in <module>
    print(stuff)
NameError: name 'stuff' is not defined

Monty still can’t find anything with the name stuff in the White Room. When Monty returned from the do_clever_things Function Room, he brought with him the integer 20, which is the value stored in the box labelled stuff in the Function Room. However, Monty didn’t know what to do with the number 20 when he returned to the White Room. So, he discarded it in the rubbish bin to free his hands up for the next task. Let’s fix this:

When Monty returns to the White Room after completing all the tasks in the Function Room, he’s now told to do the following:

• get a new, empty box
• label it using the name stuff
• store whatever information he brought with him from the Function Room in the box

Monty now places this new box with the name stuff on the shelves of the White Room. Therefore, there are two boxes named stuff, but they’re in different rooms. Indeed, the box created in the White Room to collect whatever comes back from the function could have any name:

Your final task is to add parameters in the function definitions, and you’ll see what Monty does with the parameters and the arguments in the function call:

As before, you’re creating a Function Room with the door leading from the White Room to the Function Room labelled do_clever_things. However, just inside the Function Room door, there are two empty boxes labelled first_thing and second_thing. These boxes are ready to be used by Monty when he enters the Function Room.

In the function call, when Monty reads do_clever_things(3.5, 5.2), he’ll make his way to the Function Room, and he’ll carry two numbers with him, 3.5 and 5.2. As soon as Monty enters the Function Room, he’ll find the two empty boxes. Monty will then put the first number he has in the first box labelled first_thing. He’ll then put the second number in the second box with the name second_thing. Finally, Monty will take these boxes on the shelves of the Function Room, and he can start doing whatever is needed in the function.

The Python City

You can stop here if you want. The main aim of the White Room analogy is to understand what’s been discussed above. But if you don’t want the analogy to stop here and you’d like some bonus material, then read on.

You’ve already seen that you can create a White Room when you open a new Python file and that this room may have one or more adjacent Function Rooms. However, you’ve already seen that there’s more outside. When you used an import statement, Monty left the White Room and went for a stroll to find the library. The library is at the centre of Python City.

You looked at the example of importing the random module and using the randint() function. When Monty reads the line random.randint(1, 5), he’ll find the book named random on the shelf, and he’ll open the book to look for the name randint.

Now, randint is a function. You’ve seen how this is represented by a Function Room in our analogy. However, this is not a function you have defined yourself, so it’s not adjacent to the White Room. What Monty finds in the random book next to the entry for randint are the directions for the randint Function Room elsewhere in Python City. Monty will therefore take the two integers 1 and 5 in his hands, and he’ll leave the White Room to go for a walk in Python City.

This time he’s not heading for the library but for the Function Room called randint. There’s an area in Python City with many standalone Function Rooms close to each other that all belong to the random module. Monty will find the randint Function Room. He’ll enter the room and take the numbers he’s carrying with him.

Monty will do something in that Function Room. You don’t need to know the details of what he does in there! What you do need to know is that when Monty comes back from the randint Function Room, he’ll be carrying another number in his hand. This will be a random number between 1 and 5.

Monty will then go back to the White Room, and he’ll take this number with him.

Python City has lots of areas, each containing Function Rooms that belong to specific modules. As you can guess, Python City is extensive and constantly growing!

Conclusion

Understanding programming can be challenging, but the White Room analogy makes it a bit easier. The usual analogy caveat applies: no analogy is a perfect representation of reality!

Let’s finish with a quick summary of the White Room analogy:

• The White Room is the environment in which a program will run. Monty is the name I’m giving to the computer program.
• When you create a new Python file, you’re creating a new, empty White Room.
• The White Room has several shelves, and it’s not entirely empty at the start. One small booklet called built-in has all the words that you can use in the Python language out of the box.
• When you use import, you send Monty to the library to fetch the book with that name. He brings the book back into the White Room and puts it on the shelf.
• When you create a variable, such as with an assignment, Monty brings an empty box, labels it using the variable name, and stores the information inside the box.
• A function is a mini-program and is represented by its own room, the Function Room. When you define a function, you’re creating a Function Room adjacent to the White Room. The label on the door to the Function Room is the function name.
• When you call a function, Monty goes in the Function Room, performs the tasks needed by the function, and then returns to the White Room.
• If there are input arguments when you call the function, Monty will take that information with him into the Function Room. He’ll store the data in the empty boxes at the Function Room entrance. These boxes are labelled with the function parameter names.
• If there’s a return statement in the function, Monty will take that data back to the White Room when he finishes all the tasks needed in the function. If there’s no return statement, Monty will return nothing, or None.
• The White Room is one part of Python City which contains the whole Python ecosystem.

As you write your next Python program, you can think about the White Room you’re creating and the books, boxes, Function Rooms, and Monty, who’s busy working hard, moving from one room to the next. You’re now a stop closer to understanding programming.