Lecture: Introduction to Computing & Computational Thinking
Lecture script · about 15–20 minutes spoken · Week 1
Opening
Think about the last time a machine did some work for you. Maybe your phone counted your steps on a walk across campus. Maybe a café register added up your order and printed a receipt. Somebody wrote down, in exact steps, what that machine should do, and the machine did precisely that.
That habit shows up wherever you end up. A biology major sorts lab data with a short program. A business student checks a spreadsheet's totals. Each of them breaks a task into exact steps and then checks what the computer really did.
This is the first week of the course, so we start at the foundation, and you need no experience at all. In this lecture I'll show you the difference between an algorithm and a program. Then we'll break a task into small steps, write and run a first line of Python, and predict what short lines print before we run them. After that we'll learn to read an error message from the bottom up, and we'll finish with a little history and the tools you'll use. Next, in Week 2, Variables, Data Types & Expressions, your values get names.
Here is the one sentence I want you to carry out of this lecture: the computer does exactly what you wrote, not what you meant.
1. Algorithms and programs
Imagine you hand a friend your pancake recipe. The card says to add the flour and then the milk. Your friend adds the flour, then pours in the whole carton of milk, because the card never said how much. The pancakes come out as soup. Your friend did exactly what the card said.
A computer is that friend, every single time. It never guesses and it never fills a gap with common sense.
So before we write any code, we write the steps in plain English. An algorithm is a finite, unambiguous list of steps that solves a whole class of problems, such as finding the larger of any two numbers rather than of one particular pair. A program is an algorithm written in a language a computer can run; the computer carries out its instructions literally and in order.
Let's build one together. The job is to find the larger of two numbers. Step one: look at the first number and the second number. Step two: ask whether the first number is bigger than the second. Step three: if it is, report the first number. Step four: otherwise, report the second number.
Now we trace it by hand on the numbers 3 and 7. The first number is 3 and the second is 7. Is 3 bigger than 7? No. So step three doesn't apply, and step four reports the second number, 7. That's the larger one, so the algorithm worked.
Nothing in those steps is vague. That's the test of a good algorithm: two strangers would carry it out the same way.
Pause and try this. Run the same algorithm on a tie, where both numbers are 7. Which step does the reporting, and what does it report?
Walk through the four steps once more before you decide.
Here's the answer. Step four reports the second number, 7. The first number isn't bigger than the second, so step three is skipped, and step four still gives a correct result for a tie.
So an algorithm is the plan in plain words, and a program is that same plan written so a machine can run it.
2. Breaking a task into steps
Let's move to the program that will grow with you through this course: a reading log. A reading log is a short record of what you read each day. Say you want the computer to make the very first entry in yours.
"Make a log entry" is too big for a single instruction. A machine needs it broken into pieces it can follow. Programmers call this way of working computational thinking: approaching a problem the way a programmer does, by breaking it into small steps a machine can follow literally and in order, then checking each step.
The central move has its own name. Decomposition means splitting one large task into smaller steps, each simple enough to carry out and check on its own, and putting them back in order.
Here's the first log entry, decomposed. First, decide what the entry should say: the words "Reading log" and the day number, 1. Second, decide exactly how the line of output should read: Reading log, a colon, then day 1. Third, write one instruction that shows that line. Fourth, run it. Fifth, compare what appeared with what you planned. If the last step shows a difference, you know exactly where to look: back at the instruction.
Order matters as much as the steps. Python runs a script from the top line to the bottom line, one line at a time. Picture a reading-log program with three lines. The first line shows the log's title. The second shows the goal, 300 pages. The third shows the pages read so far, 45. When you run it, those three lines appear in exactly that order: the title, then the goal, then the pages so far.
Pause and try this. Suppose you want the goal of 300 pages to appear before the title. What would you change about the program?
Think about the order Python reads the lines in.
Here's the answer. Move the goal line so it's the first line of the program. Python runs from the top down, so whatever you want shown first has to be written first.
Big task, small steps, right order. That's decomposition.
3. Your first program and the working loop
Think about sending a photo to a friend. You pick it, send it, and look at what arrived. If the wrong one went, you fix it and send again.
That loop is the edit, run, read the output, fix loop: the working cycle of programming. You change the code, run it, compare what it printed with what you predicted, and repair any difference before running again.
Your first program uses one word, print, which is Python's built-in function that displays its arguments as one line of output, with one space between each pair, and then ends the line. Inside the parentheses after print, you put a string, a piece of text inside quotation marks, which Python keeps exactly as typed instead of reading it as a number or a name.
Here's the reading log's first program, spoken out loud. It's the word print, an open parenthesis, a quotation mark, the words Reading log, a colon, the words day 1, a closing quotation mark, and a closing parenthesis. When you run it, the output reads Reading log, colon, day 1. The quotation marks don't appear. They only tell Python where the text starts and stops. What appears is the output, exactly what a program prints when it runs, shown in its own block under the label Output.
Now give print more than one thing to show. An argument is a value placed inside the parentheses of a function call, such as each comma-separated piece handed to print. Picture this line: print, then three arguments separated by commas. The first is the string Goal with a colon. The second is the number 300, with no quotation marks. The third is the string pages. Run it, and the output reads Goal, colon, 300 pages. Print put one space between each pair of arguments. You never typed those spaces.
Pause and try this. In that output line, Goal, colon, 300 pages, where did the spaces come from, and do the commas from the code show up?
Picture the three arguments sitting side by side.
Here's the answer. Print added one space between each pair of arguments, and the commas don't show up. A comma in the code only separates the arguments; if you want a comma in the output, it has to sit inside a string.
So the loop is edit, run, read the output, fix, and then go around again.
4. Predict, then run
Here's the habit that will carry you through this whole course. Before you run a line, say out loud what you expect it to print. Then run it. The gap between your guess and the real output is where the learning lives.
That's what a trace is: to read a program one line at a time and write down what each step does, so you can predict its output before you run it.
Let's trace a line that prints 2 plus 3 times 4. Many people read it left to right, like a sentence: 2 plus 3 is 5, and 5 times 4 is 20. Python doesn't do that. Python follows operator precedence, the rule that decides which operator Python works out first when an expression has several, such as multiplication before addition, with parentheses always going first. So Python works out 3 times 4 first, which is 12. Then it adds 2, and 12 plus 2 is 14. Run it, and the output is 14.
Now put parentheses around 2 plus 3, and then multiply by 4. The parentheses go first, so 2 plus 3 is 5, and 5 times 4 is 20. Run it, and the output is 20. Same numbers, same operators, and a different grouping gives a different result.
Here's one more surprise. Put quotation marks around the 2 and around the 3, and add them with a plus sign. Those aren't numbers anymore; they're two strings. A plus sign between two strings joins them end to end. So the output is 23, the character 2 followed by the character 3. Take the quotation marks away, and 2 plus 3 prints 5. The same plus sign adds numbers and joins strings, and the quotation marks decide which job it does.
And a preview of next week: a line that divides 10 by 2 prints 5.0, with a decimal point, not plain 5. That's not a mistake. Week 2 explains why division always gives a decimal number.
Pause and try this. A classmate says the line 2 plus 3 times 4 prints 20. What do you tell them, and how would you settle it?
Say your reasoning out loud before you go on.
Here's the answer. It prints 14, because Python multiplies before it adds. And the way to settle it isn't to argue: run the line and let the output decide.
Predict, then run. The run is the referee.
5. Reading an error message
When a dishwasher stops mid-cycle, it shows a code, and you look the code up. An error message works the same way.
An error message is the report Python prints when a program cannot go on; you read it from the bottom up, because its last line names the error type. You'll meet two types in this lecture, and they behave differently.
The first type comes from the parser, the part of Python that reads a program's text and checks that it follows the language's rules before any line runs. A SyntaxError is the error type Python reports when the parser refuses a program's text, so no line of that program runs at all.
The second type happens while the program is running. A NameError is the error type Python reports when a running program uses a name Python does not know, such as Print with a capital P or a word that needed quotation marks. That happens because Python is case-sensitive, treating capital and lowercase letters as different characters, so that to Python print and Print are two different names.
Here are two broken programs from the reading log. Each one has two lines. In the first program, line one is the correct print of Reading log, colon, day 1. Line two is the same kind of print, but somebody typed Print with a capital P. Run it, and the first line of output appears: Reading log, colon, day 1. Then the program stops, and the last line of the error message names NameError.
In the second program, line one is the same correct print. Line two forgets its closing parenthesis. Run it, and no output appears at all, not even line one. The last line of the error message names SyntaxError.
Pause and try this. In the second program, line one was perfectly correct. Why didn't it print?
Think about when the parser does its job.
Here's the answer. The parser checks the whole text before anything runs. It found the missing parenthesis on line two and refused the program, so line one never got its turn.
So here's the rule of thumb. If some lines printed before the error, the program was running when it hit trouble. If nothing printed at all, the parser said no before it began. Either way, read the last line first: a red message is a map to the bug, not a verdict on you.
6. Where it came from, and the tools you'll use
In 1843, Ada Lovelace published notes on a machine called the Analytical Engine, including the first published description of a stepwise sequence of operations for a machine to carry out. In 1936, Alan Turing published a paper describing an abstract machine and showing that some problems can't be decided by any algorithm at all. In 1952, Grace Hopper developed an early compiler, a program that translates code people write into instructions a machine can carry out. And in 1947, engineers found a moth in a relay of the Mark II computer and taped it into their log book. The word bug was already decades old, so the moth made the word famous rather than inventing it.
Python has its own dates. It was released to the public in 1991, Python 3.0 arrived in 2008, and Python 2 stopped being supported in 2020. This course uses Python 3 only.
Now the tools. You'll write and run code in a free browser-based Python runner, an online editor with no account and nothing to install. You'll step through programs in Python Tutor, which runs a program one step at a time and draws what happens. You'll look up rules in the official Python documentation. And you'll use one approved chatbot as a pair-programmer, a partner whose code and claims you run before you trust them.
Here's why that last part matters. Suppose you ask a chatbot what the line 2 plus 3 times 4 prints, and it answers 20, explaining that Python works left to right. It sounds confident. But a chatbot predicts likely text; it doesn't run your program. So you type the line into your runner and run it. The output is 14. The chatbot's explanation contradicted what the code prints, and you caught it by running the code.
Pause and try this. A chatbot tells you that dividing 10 by 2 in Python prints 5. What do you do with that claim, and what will the run show?
Remember what the division line printed earlier.
Here's the answer. Treat it as a guess and run it. The run prints 5.0, with a decimal point, so the chatbot left something out, and the run caught it.
The chatbot proposes, and the run decides.
Closing
Let me pull it together in the order we built it. An algorithm is a plan in plain words, and a program is that plan written so a machine can run it, like the larger-of-two steps that reported 7 for 3 and 7. Decomposition breaks a big task into small, ordered steps, and Python runs them from the top line down. The working loop is edit, run, read the output, fix, starting with a single print of Reading log, colon, day 1. Before you run a line, you predict it: 2 plus 3 times 4 is 14, the parentheses version is 20, and the two strings 2 and 3 join to 23. When something breaks, read the last line: a SyntaxError means nothing ran, and a NameError means an unknown name stopped a running program. And every claim about code, from a chatbot or from anyone, gets checked by a run.
Next in this module come the slide deck, the Readings and Resources page, the lecture tutorial, the practice set, the quiz, and the Coding Lab. Then, in Week 2, Variables, Data Types & Expressions, your values get names, and that surprising decimal from division finally gets its explanation.
Built with The Course Maker · samples.thecoursemaker.com