Algorithms: Final Steps

Long road, wasn’t it? We started by asking what an algorithm is; now you’ve got a whole toolbox in your hands: variables, conditionals, loops, lists, functions, dictionaries.

This is the last post in the series. I won’t teach a new topic here. Instead we’ll look back: what did we learn, and how do these pieces connect? Then we’ll bring them all together in one small program and close things out. Relax; this one is a bit of a victory lap.

What you learned is really just a few ideas

Nine topics can look intimidating. But here’s the nice part: they all revolve around a few simple ideas. Look back and what we learned splits naturally into three groups.

1. Holding a piece of information somewhere

Every program first has to put something somewhere. A number, a name, a bunch of grades… We grew this step by step.

First there was the variable: a box you put one thing in and write a name on. You said age ← 30, done. Then things got bigger and the list arrived: not one box but a row of boxes, all sharing a single name. When you said grades[3] you looked at the third box. Remember how “which position the box is in” and “what’s inside it” were two different things, that mailbox example.

Last came the dictionary: here you reached a box not by a position number but directly by name. grades["Ada"]. Just like a phone book; to find someone’s number you don’t count “which person were they,” you look up their name.

From a single thing, to an ordered bunch of things, to a thing found by name. The same need (storing a piece of information) in three ever-stronger forms.

2. The program deciding and repeating

You held the information; now what does the program do with it? Usually two things: sometimes it makes a decision, sometimes it repeats the same work.

The decision part was the conditional. IF grade ≥ 50 THEN ... ELSE .... Passed, or failed? The path splits by the situation. The repeating part was the loop. Instead of copying the same lines fifty times, you said “repeat until this is done.” A loop is really just a decision asked over and over; that’s why it and the conditional are relatives.

3. Tidying up the mess

As a program grows, it starts to sprawl. The function was exactly what helped here: giving a group of steps a name and making them a single piece. We wrote average(list) once and then called it as often as we liked. We didn’t even need to know exactly what happened inside; hand it the list, take the average. A black box.

And how did we put all of this on paper? That was the job of the first three posts: we drew an algorithm as a flowchart and wrote it as pseudocode. Underneath it all was one simple idea: breaking a job into clear, ordered steps. Remember that tea-brewing example from the very beginning? That’s the one.

Let’s bring it all together

Now the fun part. Let’s take all the pieces we learned and gather them into one program.

Let’s make a little class report. We’ve got students and their grades; we’ll compute each one’s average, check whether they passed or failed, and at the end count how many passed. Sounds like a lot of work, but you already know how to do every bit of it:

FUNCTION average(list)
    total ← 0
    i ← 1
    WHILE i ≤ length(list) DO
        total ← total + list[i]
        i ← i + 1
    ENDWHILE
    RETURN total / length(list)
ENDFUNCTION

report ← { "Ada": [90, 85, 100], "Can": [40, 35, 45], "Ece": [70, 65, 80] }
passCount ← 0

FOR EACH student IN report
    avg ← average(report[student])
    IF avg ≥ 50 THEN
        status ← "Passed"
        passCount ← passCount + 1
    ELSE
        status ← "Failed"
    ENDIF
    PRINT student + ": average " + avg + " → " + status
ENDFOR

PRINT "Total passed: " + passCount

Run it and it prints:

Ada: average 91.67 → Passed
Can: average 40 → Failed
Ece: average 71.67 → Passed
Total passed: 2

Stop for a second and look at this. This tiny program has all nine topics of the series in it: a function (average), a dictionary (report), lists as values, a loop (for each student), a conditional (pass/fail), variables (avg, status, passCount), an accumulator (passCount), and PRINT throughout. Let’s see the same program as a flowchart too:

flowchart TD
    A(["Start: report dictionary ready, passCount ← 0"]) --> B{"Is there a<br/>next student?"}
    B -- Yes --> C["avg ← average(report[student])"]
    C --> D{"avg ≥ 50?"}
    D -- Yes --> E["status ← Passed<br/>passCount ← passCount + 1"]
    D -- No --> F["status ← Failed"]
    E --> G["PRINT student + status"]
    F --> G
    G --> B
    B -- No --> H(["PRINT Total passed<br/>Done"])

This is really what programming is. Small, simple pieces; on their own they don’t do much. But put them together the right way and, together, they handle a big job. And you can do this now.

Where to next?

Through this series we learned how a computer thinks, on paper. The next step is telling that same way of thinking to a real computer. Don’t worry, the hardest part is already behind you.

flowchart LR
    A["1–3<br/>Algorithm · Flowchart · Pseudocode"] --> B["4–6<br/>Variable · Conditional · Loop"]
    B --> C["7–9<br/>List · Function · Dictionary"]
    C --> D["10<br/>Final Steps"]
    D --> E["A real language<br/>Python / JavaScript"]

A small thank you

One last thing. Behind every idea we learned in this series there were real people, each of them once the first to think these things up. Let’s name a few:

• al-Khwarizmi, whose name we invoke when we say “algorithm” today, was a 9th century mathematician who also founded algebra.
• George Boole built the true/false logic of conditionals.
• Ada Lovelace wrote the first program back in 1843. Yes, the first programmer was a woman.
• Behind lists are the Fortran language and Dijkstra, who asked “why do we count from zero?”
• David Wheeler brought the idea of the function; Grace Hopper brought the idea of the “library” and the first compiler.
• That fast-lookup trick (hashing) behind the dictionary was Hans Peter Luhn’s work.

Summary