Introduction to Algorithms, Programming, and Compilers

Overview

This is the first lesson of the course. Day 1 is unplugged: students write, draw, and reorder everyday algorithms (1.1.A). Day 2 moves to Java: students see where code is written, what the compiler does, and the three kinds of errors (1.1.B, 1.1.C). Students do not write Java of their own yet. Every program they see contains only System.out.println statements, plus a division by zero on Day 2 to cause a run-time error.

Keep one idea running through both days: a computer is a literal follower. It does exactly what is written, in the order written, and fills in nothing. The study guide uses the same phrase, so students who read it will recognize it. It is the guide’s name for the idea, not College Board vocabulary.

Ask each student to write, on blank paper, the steps for drawing a smiley face on the board. Give them three minutes. Collect three or four sets and follow each one at the board exactly as written, with a straight face. “Draw a circle” gets a tiny circle in a corner; “draw two eyes” gets two eyes anywhere, maybe outside the circle; a missing “pick up the marker” means you cannot start.

Then ask: “What went wrong, and whose fault was it: mine or the instructions’?” Steer students to two ideas you will name in a moment: the steps were not precise, and sometimes they were in the wrong order.

1. Goals (slide 3). Read the five goals aloud; the first three are today’s, the last two are Day 2’s.
2. Define algorithm (1.1.A.1, slides 4–5): a step-by-step process that completes a task or solves a problem. Ask for everyday examples: a recipe, directions to a house, getting ready for school, logging in to a website.
3. Precision (slide 5). Show only the vague smoothie steps first (“Add some fruit. Blend it. Serve.”). Ask, “What would a literal follower ask about each step?” Collect questions such as “How much?” and “For how long?”, then reveal the questions and precise rewrites in the table.
4. Two representations (1.1.A.1, slide 6). Show the login algorithm as a numbered list and as a flowchart side by side. Match them box by box. Point out that the ovals mark Start and Stop and are not steps, and that in a flowchart the arrows are the order.
5. Same algorithm or not? Ask: “If I swapped the username and password boxes in the flowchart, would it still be the same algorithm as the list?” No: what defines an algorithm is its steps and their order, not whether it is written in sentences or boxes.

Define sequencing (1.1.A.2, slides 7–8): the order in which steps are completed. Steps are completed one at a time, and each step happens in the situation the earlier steps left behind.

1. Show the cake algorithm on slide 8 in its original order (bake, cool, ice). Ask pairs to predict what happens if steps 2 and 3 swap before you reveal the right column: the icing melts on the hot cake. Same steps, worse result.
2. The swap test (slide 9). Ask pairs which two steps of the tea algorithm (cup, tea bag, bag in cup, hot water) can swap safely and which swap breaks it. Getting the cup and getting the tea bag can swap; putting the bag in the cup cannot come before getting the cup. Draw out the rule: order matters when a later step depends on what an earlier step did.
3. Have each pair write a four-step algorithm for a school routine (for example, checking out a library book) as a numbered list, then draw it as a flowchart. Call on two pairs to share and have the class check the order by asking of each step, “Is everything this step needs already done?”

Hand out the puzzle worksheet. Students work Part A questions 1–2: question 1 sorts steps into precise and vague, and question 2 matches a plant-watering flowchart to the written list that is the same algorithm. Circulate and look especially at the second half of question 2: students should say that choice A has the right steps in the wrong order, so it is a different algorithm.

Ask each student to finish this sentence on a sticky note or in their notes: “A computer needs precise, ordered steps because …” Look for two ideas: it is a literal follower (precision), and it does steps one at a time in order (sequencing).

Show GreetingReordered.java without running it. Ask students to write what it displays. Most will guess correctly from Day 1’s idea of sequencing; tell them that is exactly the point: Java statements run one at a time, top to bottom, in the order written. Run it to confirm.

1. From algorithm to program (slides 10–11). A programming language (Java) has strict rules so every instruction means exactly one thing. An algorithm written in it is a program; the text is source code. Each line inside main is a statement; Welcome.java on slide 11 has two, and they run one at a time, in order.
2. Where code is written (1.1.B.1, slide 11). Code is plain text, so any text editor can hold it. An IDE puts the tools to write, compile, and run code in one application. Switch to the IDE and show its editor, its error highlighting, and its run button.
3. Compile, then run (1.1.B.2, slide 12). The compiler checks the code for some errors, then translates it so the computer can run it. Running carries out the statements one at a time. Errors the compiler finds must be fixed before anything runs.
4. Live demo (slide 15 afterward). Run MissingSemicolon.java. Before you click run, ask: “Line 5 is missing a semicolon. Line 6 is fine. What will we see?” Many students predict “Good morning!” and then an error. Run it: only the compiler message appears. Slide 15 shows the same result with three class periods: one missing semicolon on the last line, and no line prints.
5. Syntax errors (1.1.C.1, slide 14): code that breaks the language’s rules; the compiler detects them. Use Poster.java on slide 14 to read a compiler message in three parts: file and line, what is wrong, and where the caret points. List the common syntax errors on the board (missing semicolon, missing closing quote, wrong capitalization, misspelled word) and stress that Java is case-sensitive.

1. Logic errors (1.1.C.2, slide 16). Show the scrambled-eggs program. It compiles and runs to the end, but it cooks the eggs before whisking them. Ask: “Did the compiler complain? Is the program right?” A logic error makes the program behave incorrectly or unexpectedly; the compiler cannot see it.
2. Testing (slide 16). Logic errors are found by testing: decide the expected outcome first, run the program with specific data, and compare. Point to the expected and actual columns on the slide. Then give a doubling example on the board: an algorithm that “adds 2” passes a test with 2 (2 + 2 = 2 × 2) but fails with 5 (expected 10, actual 7). One lucky test can hide a logic error.
3. Run-time errors and exceptions (1.1.C.3, 1.1.C.4, slide 17). Show Snack.java in the IDE and say that / means divide, as on a calculator (arithmetic is taught in Topic 1.3). Ask students to predict the output, then run it. The first line appears, then ArithmeticException: / by zero, and the last line never runs. Slide 17 shows the same pattern in a movie-night program. A run-time error happens while the program runs and usually makes it terminate abnormally. An exception is a run-time error the compiler did not catch; it interrupts the normal flow of the program.
4. Compare all three using the table on slide 18: does it compile, does it start running, how does it end, and who or what finds it.

Students type Greeting.java into the IDE and run it. Then, one at a time, they make each change below, predict what will happen, run it, record the result, and undo the change:

1. Delete the semicolon at the end of line 5.
2. Change System to system on line 6.
3. Swap lines 5 and 6.
4. Add System.out.println(10 / 0); between lines 5 and 6.

For each, students record: Did it compile? What was displayed? Which kind of error is it (syntax, logic, or run-time)? Debrief with the class: changes 1 and 2 are syntax errors (nothing displayed), change 3 is a logic error if the expected outcome was “Good morning!” first, and change 4 is a run-time error (one line, then the exception).

Puzzle worksheet questions 3–10 (be the compiler, code tiles, be the JVM, the match-up, the face-off, who am I, and two catch-the-mistake questions) are homework, about 25 minutes. Students who finish the IDE activity early can start them in class. Question 4 ends with a Think First prediction that question 6 settles, so ask students to work the questions in order.

Spend two minutes on slide 19 (Name that error): the class calls out syntax, run-time, or logic for each case and says how they can tell. Slide 20 lists the vocabulary, and slide 21’s sentence starter can be a quick pair-share if time allows. Then give the exit ticket (about five minutes). Score each question separately: question 1 checks algorithms and sequencing, question 2 the compile-then-run process, and question 3 the error types. Re-teach the weakest one at the start of Topic 1.2.