0.3.1 Programs Follow Instructions

Computers Do What the Instructions Say

People are very good at filling in missing information.

Computers are not.

If a person hears:

they may automatically look around, identify the Jordan on their team, decide which foot to use, avoid the defender, and choose an appropriate amount of force.

Those details were not written in the sentence.

A person used context and experience to fill them in.

A computer program cannot safely depend on that kind of unstated assumption.

Programs follow the instructions that have actually been defined.

Human Understanding Often Hides Missing Steps

Imagine these soccer instructions:

  1. Get the ball.
  2. Pass to Jordan.
  3. Shoot.

A soccer player can probably imagine a reasonable sequence.

A literal system immediately exposes unanswered questions.

Where is the ball?

What if another player currently has it?

Which Jordan?

How does the program know when the pass reaches Jordan?

Who shoots?

What does “shoot” mean in the current situation?

The problem is not that the goal is impossible.

The problem is that the instructions rely on information a human reader is supplying automatically.

Programming requires you to become aware of those hidden assumptions.

A Program Executes Defined Actions

A program is made of instructions that a computer can execute.

Those instructions may:

  • create or change information;
  • perform calculations;
  • display information;
  • call another part of the program;
  • or later choose among different paths.

For now, focus on one simple idea:

An instruction needs to be specific enough that the program can determine what action comes next.

“You Know What I Mean” Is Not a Programming Rule

Suppose you tell another person:

They might ask:

  • alphabetical order?
  • jersey-number order?
  • field-position order?
  • order of arrival?
  • starting-lineup order?

A person can ask for clarification.

A program only has the instructions and data it has been given.

A better requirement might say:

Now the intended ordering rule is much clearer.

Precision reduces the number of assumptions hidden inside the instruction.

Programs Do Not Know the Goal Unless It Is Represented

Imagine that the coach's goal is:

The program does not automatically know which information matters to that goal.

The software needs instructions that operate on represented information such as:

  • players;
  • positions;
  • availability;
  • and the match being prepared.

That connection reaches back to abstraction and modeling.

Before a program can follow useful instructions, the system must represent the information those instructions depend on.

One Instruction Can Depend on an Earlier Instruction

Consider:

  1. Identify the player with jersey number 7.
  2. Display that player's name.

The second instruction depends on the result of the first.

If the program has not identified a player, “that player's name” has no clear target.

Programs frequently build later actions from earlier results.

That makes order important.

The same instructions in a different sequence can produce a different result or may not make sense at all.

Small Steps Are Easier to Reason About

Compare:

with:

  1. Select the current match.
  2. Load the team roster for that match.
  3. Identify players marked available.
  4. Display the available players.

The second version is easier to analyze because each step has a narrower job.

That does not mean every program should be written as a huge list of tiny instructions.

It means complex behavior becomes easier to understand when you can identify the meaningful actions and the order in which they occur.

Unexpected Results Come From Executed Instructions

When a program produces the wrong result, it is tempting to say:

A more useful question is:

The result may reveal:

  • a missing step;
  • an instruction in the wrong order;
  • a value that was not what you expected;
  • or a requirement that was too ambiguous.

This is why debugging focuses on evidence about actual execution.

Instructions Need a Shared Meaning

Programming languages solve part of the precision problem by giving instructions a defined syntax.

For example, C# gives a specific meaning to statements written in valid C#.

UML activity diagrams give a visual way to represent flow using standardized notation.

Before you use those formal representations, it helps to develop the reasoning underneath them:

  • What action should happen?
  • What information does it need?
  • What happens immediately after it?
  • Which assumptions have not been stated?
Keep the Core Idea

A computer is powerful because it can carry out defined instructions consistently and quickly.

That power depends on the instructions being clear enough to execute.

When a program behaves differently from what you intended, start with the instructions and the evidence.

The computer cannot rely on “what you meant.”

It can only work with what the program actually represents and tells it to do.