Algorithms vs. Programs: Expressing Solutions Without a Language

Algorithm vs. Program: Same Solution, Different Forms

An algorithm is the method: a sequence of steps that solves a problem. It is independent of any programming language and can be described in multiple ways (plain language, pseudocode, flowcharts). A program is an implementation of an algorithm in a specific language and environment (Python, JavaScript, C#, a spreadsheet formula, etc.).

Think of an algorithm as a recipe and a program as the recipe written in a specific kitchen’s format, using that kitchen’s tools and rules. The method stays the same; the implementation details change.

What changes when you move from algorithm to program?

• Syntax and libraries: Programs must follow strict language rules and may use built-in functions.
• Execution environment: Programs run on a computer with specific constraints (memory, file access, permissions, device inputs).
• Data representation: Programs must choose types and structures (integers, strings, arrays, objects).
• Error handling: Programs often include extra checks for invalid data, missing files, network failures, etc.

Three Ways to Express an Algorithm (Without Committing to a Language)

1) Plain-language steps

Plain language is useful for communicating intent to humans. It should still be structured and testable, not vague. A good plain-language algorithm uses numbered steps, consistent terms, and explicit conditions.

Example style guidelines:

• Use imperative verbs: “Read”, “Compare”, “Repeat”, “Stop”.
• State decisions with clear conditions: “If X is true, do A; otherwise do B.”
• Avoid ambiguous words: replace “some”, “a few”, “as needed” with measurable rules.

2) Pseudocode

Pseudocode is a “neutral” code-like description. It is more precise than plain language but still not tied to a specific programming language. It helps you express loops, conditionals, and data updates clearly.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

IF condition THEN    action ELSE    other_action ENDIF

Good pseudocode uses consistent conventions (indentation, keywords, and naming) so that it can be translated into many languages with minimal interpretation.

3) Flowcharts

Flowcharts represent control flow visually. They are especially helpful for branching logic and repeated steps.

Common symbols (text description):

• Start/End (terminator): oval
• Process: rectangle (an action)
• Decision: diamond (a yes/no question)
• Input/Output: parallelogram
• Arrows: show the direction of control flow

Even without drawing, you can describe a flowchart by listing nodes and arrows (e.g., “Start → Read value → Decision: value > 0?”).

Structured Comparison: Algorithm Descriptions vs. Programs

Guided Activity: One Algorithm, Three Representations, One Meaning

Goal: Write the same algorithm in (1) plain language, (2) pseudocode, and (3) a flowchart description, then check that all three are equivalent.

Problem: Given a list of numbers, compute the average of the positive numbers. If there are no positive numbers, output 0.

A) Plain-language algorithm (structured steps)

1. Set sum to 0.
2. Set count to 0.
3. For each number x in the list:
4. If x is greater than 0, add x to sum and increase count by 1.
5. After processing all numbers, if count equals 0, output 0.
6. Otherwise, output sum / count.

Precision check: The condition “greater than 0” excludes 0 and negatives. The output rule for “no positives” is explicit.

B) Pseudocode version

ALGORITHM AverageOfPositives(numbers)    sum ← 0    count ← 0    FOR EACH x IN numbers DO        IF x > 0 THEN            sum ← sum + x            count ← count + 1        ENDIF    ENDFOR    IF count = 0 THEN        OUTPUT 0    ELSE        OUTPUT sum / count    ENDIF

Translation check: Each plain-language step maps to a pseudocode statement: initialization, loop, conditional update, final conditional output.

C) Flowchart (textual description of nodes and arrows)

• Start
• Process: set sum = 0, count = 0
• Loop setup: take next element x from list
• Decision: “Is there an x available?”
• If No → go to final decision (count = 0?)
• If Yes → decision “Is x > 0?”
• If Yes → process “sum = sum + x; count = count + 1” → back to “take next element”
• If No → back to “take next element”
• Decision: “Is count = 0?”
• If Yes → Output: 0 → End
• If No → Output: sum / count → End

Equivalence checklist (use this to verify all three match)

• Same inputs: all three take a list of numbers.
• Same selection rule: only numbers with x > 0 are included.
• Same accumulation: sum and count update together and only when x > 0.
• Same termination point: processing ends after the last element.
• Same output cases: output 0 when count = 0; otherwise output sum / count.

Common mismatch to watch for: In one representation you might accidentally treat 0 as positive (using x >= 0) or forget the “no positives” case, which would cause division by zero in a program.

Criteria for a Good Algorithm Description

1) Unambiguous steps

• Every action should be clear enough that two different people would perform the same operation.
• Every decision should have a precise condition (e.g., x > 0, not “x is big”).
• Terms should be consistent (don’t switch between “item”, “value”, and “number” if they mean the same thing).

2) Defined inputs and outputs

• Inputs: what information the method requires (e.g., “a list of numbers”).
• Outputs: what it produces (e.g., “a single number: the average of positive values, or 0”).
• Edge cases: explicitly state what happens when special situations occur (empty list, no qualifying elements).

3) Termination (it must finish)

• Loops must have a clear stopping condition (e.g., “after the last element”).
• Recursive descriptions (if used) must include a base case.
• Avoid “repeat forever” unless the task is explicitly a continuous system (and then define how it is controlled).