What Is a Program?

Programming FoundationsLesson 1 of 860 minutesLessonBuilds on: Linux Investigation LabNo lab next

Learning objectives

By the end of this lesson

• Explain the difference between source code and a running program.
• Identify a program’s input, output, operations, and state.
• Describe the roles of an interpreter and a compiler without treating them as magic translation boxes.
• Run a small Python program and connect its output to the instructions that produced it.
• Compare the expected result with the program’s behavior.

A program is a set of instructions

A program is a set of instructions written to make a computer do some task. That task might be adding two numbers, displaying a website, decoding a photograph, or keeping an alarming number of browser tabs alive.

Those instructions usually start life as source code, which is text written in a programming language. The language gives us a defined vocabulary and grammar for expressing operations, and that grammar matters considerably more than it does in English, because a computer will never politely work out what we probably meant.

Consider this tiny Python program:

name = "Ada"
message = "Hello, " + name
print(message)

Even without knowing any Python, we can make a reasonable first pass at it:

1. Store the text Ada under the name name.
2. Combine Hello, with the stored name and call the result message.
3. Display the message.

There’s an order to those jobs. The second line needs a value for name, so the first assignment has to happen before Python can construct the greeting. The third line needs the completed message. Moving the print to the top wouldn’t make Python search ahead for the value we meant to give it. It would try to use the name before this program had defined it.

The quotation marks tell Python that "Ada" is literal text. Without them, Ada would be a name to look up, just as name is on the second line. The + joins the two pieces of text, and = associates the result with the name on its left. Finally, print(message) asks Python to display the value associated with message. The parentheses supply the value to that operation. We’ll use this notation repeatedly, so it’s worth distinguishing the text we want to store from the instructions that work on it.

That source code is not the running program. It’s a durable description of what should happen when something runs it. When the program does run, the computer creates a process to carry out those instructions. You met processes back in Linux Foundations, and now we care about what one is doing on the inside.

Key concept

Source code describes, a process acts

Source code is stored text, sitting on disk and doing nothing. A process is a running instance of that program, carrying its own current state and holding its own operating-system resources. Run the same source several times and you get several separate processes out of it.

Four questions make code less mysterious

When you meet a small program, begin with four questions:

1. What input can enter?
2. What operations are performed?
3. What state changes while it runs?
4. What output or effect does it produce?

Input is data the program receives from somewhere else, and it might arrive from the keyboard, from a command-line argument, from a file, from a network connection, or from another program entirely.

An operation is work performed on that data, whether that’s adding numbers, comparing text, copying bytes, or choosing which instruction comes next.

State is whatever the program currently remembers. In the example above, name and message are both pieces of state, and state changes as the instructions run.

Think about pausing just after each line. After the first, the program has a name to greet but hasn’t built the greeting. After the second, it has both values but hasn’t printed anything. After the third, the terminal has received the greeting. The same source file describes all three moments; which one we’re asking about determines what the process has done so far.

Output is anything that leaves the program or changes something outside it. Printed text is output, and so is a written file, a network message, or the exit status handed back to the shell when the process ends.

And these categories aren’t just vocabulary for a quiz. Understanding unfamiliar behavior usually starts by asking how the input drives state and operations toward some particular output.

How source code becomes behavior

A processor doesn’t execute Python or C source code as written (not one line of it). Something has to bridge the gap between the language humans work in and the instructions the machine can actually run.

An interpreter reads a program and carries out what it means, and Python is normally introduced this way, with the python3 program reading your Python source and executing it as it goes.

A compiler translates source code into some other form before you ever run it, so a C compiler turns C source into a native executable holding machine instructions for one particular platform.

That distinction is useful, and there’s a good deal more machinery under it than that. Python first converts source into an intermediate bytecode, and modern compilers run through a whole series of processing stages before an executable finally comes out the far end. We’ll dig into those details at the point where they help answer a real question. For now the practical difference is what matters:

• With our Python examples, we give the source file to python3 when we want it to run.
• With our C examples, we compile the source into an executable and then run that executable.

In python3 hello.py, the shell starts the python3 executable and supplies hello.py as an argument. Python then reads that file as Python source. The shell doesn’t interpret the assignments inside it, and the processor doesn’t suddenly learn Python syntax. The interpreter itself is running machine instructions that implement the language’s behavior.

Each ordinary invocation starts a fresh run. A variable created by one run of hello.py doesn’t remain available to the next run just because the terminal window stayed open. The source file survives, and the terminal may still display the old output, but the next process has to execute the assignments again. Keep those three things separate when you test an edit: saved source, the current run, and text left on the screen.

Neither approach makes one language a toy and the other one “real”, whatever anyone tells you. They expose different parts of the system, and that’s exactly why we’ll use both.

The small examples in Python’s introduction give you another way to compare source text, values, and printed output.

Run the smallest useful example

Open a terminal in your Linux course VM. First, confirm that Python 3 is available:

python3 --version

You should get output beginning with Python 3. The remaining version numbers may differ from the examples, and that doesn’t affect this exercise.

If Python is not installed

If the terminal reports something similar to:

python3: command not found

then Python 3 isn’t currently reachable through the normal command path. On the Ubuntu course VM, install it with Ubuntu’s own package manager.

First, refresh the package list:

sudo apt update

sudo asks Linux to run this one administrative command with elevated privileges. Enter the password for your course VM when it prompts you. The terminal won’t show dots or asterisks while you type, and it is still accepting every keystroke.

After the package list finishes updating, install Python 3:

sudo apt install python3

When apt asks whether you want to continue, read the proposed change first, then type y and press Enter. Now check the result:

python3 --version

But don’t substitute python if that command turns out to be missing. Some Linux systems never create a python command at all, and others configure it to mean something quite different from what you’d expect. This course says python3 explicitly so there’s no mystery about which major version we intend to run.

Safety note

If apt cannot download packages

Confirm the course VM has a working network connection, then run sudo apt update again. Read the last few error lines before you change anything else. Messages about name resolution or failed connections point at networking, while messages about a locked package database usually mean another software installation is already running.

Create a directory for this module:

mkdir -p ~/underdunn-course/exercises/programming-foundations
cd ~/underdunn-course/exercises/programming-foundations
pwd

The final pwd output should end with:

/underdunn-course/exercises/programming-foundations

Open the Text Editor application. Enter these three lines exactly:

name = "Ada"
message = "Hello, " + name
print(message)

Save the file as hello.py in ~/underdunn-course/exercises/programming-foundations.

Return to the terminal and confirm the file is where you expect it:

ls -l hello.py
file hello.py

file should identify it as text (which tells us about the stored source file, and nothing whatsoever about what those instructions will do when they run).

Checkpoint

Predict before running

Work out the output you expect. Which line creates the final text, and which line sends it outside the program?

Make the prediction before you continue. Being wrong is genuinely useful here (a wrong prediction gives us something specific to explain).

Run the program:

python3 hello.py

The output should be:

Hello, Ada

So compare that observation against your prediction. The first line created state called name, the second line read that state, performed a text-combination operation, and created new state called message, and then the third line produced the output you saw.

The quotation marks don’t appear in the output, because they mark text in the source code rather than forming part of the text between them.

Change one thing at a time

Edit hello.py and replace Ada with your own name. Before you run it, predict exactly which part of the output will change and which parts will stay put.

Run it again:

python3 hello.py

You changed one input value embedded in the source and left all of the operations alone. If several lines changed unexpectedly, go back and recheck the file rather than piling on more changes. A controlled experiment is a great deal easier to reason about than a heap of simultaneous edits, and that gap widens fast as programs grow.

Assignment also happens at a particular moment. Once message has been built, changing name doesn’t go back and rebuild it. In a copy of this example, insert name = "Grace" immediately before print(message). Predict the output, then run the copy. If it still greets Ada, that isn’t Python ignoring the change: the print uses the message constructed earlier. Restore the original afterward. This is our first example of why following the order of operations matters.

Now add a second print instruction:

name = "your name"
message = "Hello, " + name
print(message)
print("The program reached the end.")

Predict the order of those two lines, and then run the program. Python normally carries out instructions from top to bottom, and later on conditions, loops, and functions will make that path a lot less direct.

Errors are output too

Temporarily remove the closing quotation mark from the first line:

name = "Ada

Now run the program again. Python should report a SyntaxError, and it should point somewhere very near the place where it stopped being able to understand the source at all.

A syntax error means the source doesn’t follow the language’s grammar, so Python can’t even begin carrying out the program. That error message is evidence, and a fairly rich piece of it. It names the type of failure, the file, a line, and often the exact part that first became impossible to parse.

So put the quotation mark back and run the program once more. Don’t leave the exercise sitting in a broken state just because breaking it was educational.

Key concept

Failure is an observation

An error message is program output describing what failed, and it deserves the same attention as any other output. Read it from the beginning, check the error type, and go and look at the line it references. Random edits will sometimes silence an error, and they never explain one.

Check your result

After repairing the quotation mark, run hello.py again. It should print the greeting using the current value of name. The assignment builds the message; print sends it to the terminal. If the syntax error remains, compare your quotation marks with the complete example.

Common failures and recovery

• python3: command not found: go back to Prepare Your Course Workspace and confirm the supported Ubuntu image and the Python baseline.
• The source file isn’t found: run pwd and ls, then get back to the exact exercise directory before you retry.
• A syntax error survives the repair: replace the file with the complete known-good example, run it, and then reapply one intended change at a time.
• The output differs after several edits: go back to the saved baseline source, and change one line at a time from there.

What this lets us investigate

You can now separate the file holding source code from the process that gets created when the code runs. You’ve also got a first-pass method for reading a program. Identify its input, operations, state, and output, predict the behavior, run it, and then compare the evidence against the prediction.

Next, Python Scripts and Values replaces that fixed name with data supplied when the program runs. That’s where programs start becoming genuinely useful, and it’s also where the input starts deserving some suspicion.

Check your understanding

Knowledge check

Question 1 of 2

You change a greeting string in hello.py but run a copy in another directory. The greeting stays the same. What should you check first?

Which source copy Python ranWhether C compilation was neededWhether printing changed the source

Check answer