Steve's Preface (Chapter 0)

(as edited by Tom)


The best way, really the the only way, to learn to program is to write programs. Programming is a skill acquired through practice. The more you program, the better you will get at programming.

So let's write a program.

I hear you saying, wait a second I can't do that, I don't know anything about programming, how am I going to write a program.

In fact you DO know a lot about programming, you just don't know it. In fact you create programs every day. Don't believe it? Let me prove it to you.

Write down how you would make a peanut butter and jelly sandwich. Go ahead. Just write down the steps, then turn the page.

If this sounds stupid or childish, indulge me, because the steps necessary to make a PB&J are a sequence of actions, that you perform in order from first to last which is the essence of what a computer program is. You don't need to know a computer language to write a program (you need one to write a computer program of course) but programs that people execute (the words used when you do the steps) aren't any different from the programs that computer executes so we'll start by writing programs in the language you understand.


So go ahead and write your PB&J program (steps) and then turn the page.

Great. Here's my program for making a PB&J.

Spread the the PB on one piece of bread. (Like most people I use two pieces of bread for a sandwich).

Spread Jam on the other.

Put the two pieces together.

Now your program may not be the same as mine. First of all you might have spread the jam first. Our you might do an open faced PB&J.

Also my program makes lots of assumptions. Such as that I have PB and Jam and Bread, that all of these are on the counter and bread is on a plate (or if you are like me, on the counter). So let's flesh the program out a bit more.

Open pantry cabinet
Take out Jam
Take out PB
Take out Bread
Open Jam
Open PB
Open Bread
Open other cabinet
Take out plate
Open drawer
Take out knife
Take first piece of bread out of package
Put on plate
Take second piece of bread out of package
Put on plate
Spread jam on bread
Spread PB on bread
Put bread pieces together

Computer programs are a sequence of steps that the computer does (or executes) starting with the first and proceeding to the last.

At this point you are probably rolling your eyes and thinking that you can't believe you are reading this. It's so obvious. I want to learn something new, something I don't know and here I am having to write a fake program about making a PB&J. This is such a waste of time.

Indulge me because a sequence is the most fundamental concept of a computer. It doesn't matter how skilled you become or what languages you know it's all a set of steps and there is a lot more here than you might think. So let's take a minute to look.

We already know that the sequence goes from beginning to end. But what about the order? Does it matter?

Obviously you can't spread the jam if the jar isn't open or if it's still in the cabinet. But what if you spread the PB before the Jam instead of the Jam before the PB? Does that matter?

Or what if you take the Jam out of the cabinet, spread it, then take the PB out and spread that?

How about if you spread the jam before taking the bread out? Is that a problem?

A long time ago there was a television program called All In the Family. The father saw his son in law (who was living with them while he finished grad school), put on a sock then a shoe, then the other sock and then that shoe. He thought this was crazy. The son in law said it made perfect sense.

The answer, which I'm sure you've already figured out is that sometimes order doesn't matter at all (jam first vs PB first, sometimes the wrong order results in a bad outcome (spread before taking the bread out) and sometimes the outcome isn't bad, but perhaps not very efficient (going to the cabinet between spreading the PB and the Jam).

The other thing you may have noticed is that my program has a lot of loose ends, steps that have been glossed over. What if there were two flavors of jam? We need to choose. How did the jam and PB and bread get into the cabinet? What if we go to look for them and they aren't there?

It turns out that you not only create programs every day, and are probably very good at it, you write very complicated programs, and are very good at it, because you spend a lot of time doing stuff and doing stuff is basically going through a sequence of steps.

Believe it or not, you not only have just written your first program, you've also taken the first and most important step necessary to becoming a really good programmer: Taking a problem and breaking it down into a sequence of steps, then breaking each of those steps into a sequence of steps.

The concept of the sequence is one of only 5 basic concepts that are the basis for essentially every program language you would likely ever use (yes there are a few weird ones). So you are 20% of the way there.

So let's write another program.

Assume there are two jars of jam. Write a program to make a PBJ.

Then turn the page.

Here's my program.

Open cabinet
Decide which jam to use
(execute the rest of the existing program)

I'm very lazy. I try hard not to do any more work than is required as a result rather than write the rest of the program all over again I just said, go do what is already there. It turns out another thing about sequences is that if you are clever, and being clever makes you a good programmer, you spend a lot of time thinking about the sequences you write for your programs so they not only don't fail (Jam on the counter instead of on the bread) or are inefficient (two trips to the cabinet instead of one), but that they are organized so that you can use the sequences over and over. That is not something that will be easy to see how to do until you write a few programs and see what a difference it can make, so let's write another program.

Again indulge me. This may seem like baby stuff, but it isn't. The programs won't always be this easy. Pretty soon you'll have to spend a lot of time thinking about the problem and how to break it down into parts, but before you can do that, you need to know what the pieces should look like.

So let's talk about your choice of jam.

Let's suppose you are not a very impulsive person. Order makes you happy. I know you probably aren't like that but it's fun and makes for an interesting program.

You only eat PBJ on weekends. You only allow yourself one PBJ per weekend, but it can be either day. However if it's Saturday, you always use Strawberry Jam and if it's Sunday you always use, say, Peach.

Write the program. Go ahead. Then turn the page.

Here's mine.

If it's Saturday choose the Strawberry jam
If it's Sunday, choose the Peach
(do the rest of my program).

Not exactly rocket science huh? No, but the second fundemenatel concept that is a part of every computer language. You are making a decision, Strawberry or Peach. Walking down the street, go left or right (or maybe straight ahead).

We call this a conditional. Sequences get executed (meaning you do them remember) from top to bottom until you are done. The conditional allows you to choose different sequences to execute. Which one is deponent upon what something else, in this case what day it is.

If it's Saturday then choose Strawberry
If it's Sunday then choose peach.

Just like the way sequences can have a mistake where the result isn't what you intended (when you fail to bring the bread out before spreading the jam) so can conditionals.

Mine has just such a mistake. There are 7 days in the week. What I asked you to do is make my PBJ. My program tells you how to do it. But what if I ask you for a PBJ on Wednesday. The program doesn't tell you what to do. It's incomplete. You are a person and you come with a lot of knowledge built in so you'd say, but it's Wednesday, what do I do?

Computers don't come with built-in knowledge. You have to tell them everything. When you don't, and this will happen a lot, not only when you are starting to learn programming, but also after you have learned a lot.

If a computer were running my program, it wouldn't know what to do. There are a lot of ways programs wind up in a situation that they don't know what to do and there are programs that help you write programs that are very good at helping you avoid problems like this one and you will start using one of them very soon. Right now well just fix the problem with my program.

How about if you write a program that handles the fix. Assume I'm allowed a PBJ any day of the week and if it's anything other than Saturday or Sunday then I use Grape Jelly. Then turn the page.

If you wrote:

If it's Saturday choose the Strawberry jam
If it's Sunday, choose the Peach
If it's Monday...
If it's Tuesday...
(do the rest of my program)

Then good for you. But I'm lazy. And it turns out that computer languages just happen to be designed for lazy people so you will discover that the conditional has all kinds of options for us lazy folks one of which looks like this.

If it's Saturday choose the Strawberry jam
If it's Sunday, choose the Peach
If it's any other day then choose Grape
(do the rest of the program)

Conditionals are the second of the five basic components of every computer programming language. There are going to be lot of variations so that you can be lazy but write the exact kind of conditional you want with a minimum of fuss. Don't let all the variations that are available worry you. Just remember that your program is a sequence of steps. Whenever you want to execute a different sequence instead, you use a conditional. It's not different from when you decide to turn left going out of your house and take the route to school on weekdays but turn right to go see your friend on the weekend.

So lets write another program.

I'm sort of losing interest in PBJ. Maybe we'll come back to it. But let's eat breakfast. I like cereal so let's do that.

First we need to make breakfast and then we need to eat it. Break down the steps in your head. Remember this time you are going to write a program to make the breakfast and eat it. There is a bit more here to consider that the PBJ. Hint: There is something you do over and over. You don't just go through the sequence once, but go backwards and perform the same steps again and again until the task is complete. Hint: Not many of us down the whole bowl of cereal in one gulp.

Write the program then turn the page.

Did you get something that looks sort of like this? It's doesn't matter if your program has more or less steps than mine. Neither is supposed to be complete.

Remove milk from fridge
Remove cereal from cabinet
Take out spoon from drawer
Remove bowl from cabinet
Pour cereal into bowl
Pour milk into bowl
Dip spoon into bowl
Lift spoon to mouth
See if bowl is empty
If not, do it again.

In computer speak we have a word for this. Just like the list of steps you go through moving forward is called a sequence and when you choose to execute one set of sequences or another based upon something like what day it is, is called a conditional, going back and repeating a sequence over and over is called iteration.

Whether it's hitting a nail with a hammer until it's all the way in, sawing until a board is cut all the way through, or doing the same steps over and over until a task is complete, you use iteration all the time in your life, and so do computer programs.

How about you write a program -- anything you want, since writing programs you want to write is what this is all about -- that uses iteration. If you want to throw in a conditional that would be cool too. Then turn the page.

The thing to remember about conditionals and what makes them different is that with a conditional you are moving FORWARD through your sequence while Iteration moves you BACKWARD to do the same thing you just did again until the task if finished. Whenever you learn a computer language, including the first one you learn -- which we'll do shortly -- the easiest way to learn it is to figure out how how that language expresses each of the 5 basic components, of which you already know three.

Sequence, the steps in the proper (forward) order. Iteration, going back and doing the same steps again and again. Conditional, choosing to go either left or right, one or the other but not both.

Now there is a tiny little problem with my program. It isn't clear where in my iteration to go back to. That is a problem because computers are as we've said stupid and computer programs get very big, with lots of iteration and almost always iteration inside of other iterations and so it's necessary for iteration to be explicit where to go back to. There are lots of ways to accomplish this but I'll show you one of the most common that programs use, which is to mark the beginning (and end) of the iteration with special words that tell us that this is an iteration.

Remove milk from fridge
Remove cereal from cabinet
Take out spoon from drawer
Remove bowl from cabinet
Pour cereal into bowl
pour milk into bowl
Repeat the following steps:
Dip spoon into bowl
Lift spoon to mouth
See if bowl is empty
If not, do this iteration again

Note that I indented what I've written. The computer couldn't care less about that. It just does what it's told to do, but I'm a human and it's essential for me to be able to visualize what I'm telling the computer to do. Indenting is a good way to separate an iteration.

So what have you learned. Programming isn't some dark, unknowable act. It's something you do and have done all your life. Computers are just dumb as bricks, so you need to tell them everything about what to do, which means computer programs can have lots and lots of steps.

The good news is that lot of other people have written programs that you can use to build your programs just the way I used part of the program I wrote. So programming is really about breaking big tasks into littler tasks and the better you can do that the better your programs will be.

We'll start doing that very soon but first you have two more basic components you are going to need.

Try writing a program about what to do at a stoplight.

Then turn the page.

Here's my program.

What color is the light
If it is red, do next iteration
Else go

What makes programs useful is that they can take information in from us humans and give us information back. The information coming into this program is the color of the light. The information the program give back to us is whether to go or not.

We call this input/output (often abbreviated "I/O"). It's the fourth fundemantal concept common to all computer languages and the second to last you need to know. It is what the programmer -- that would be you -- or the computer does not know when you wrote the program.

Input is some data (values, numbers, text, whatever) that is provided to the program after it starts running. Nobody knows the color of the traffic light until you look. That's why it's input.

Output is something the program delivers back to the outside world, the result of a decision or computation, which is why you ran the program. When you ran the traffic light program, you didn't know when to go until the computer said to go. That's why it's output.

If you are writing a calculator program, the input would be the button pushes that are the number you want added, and then the Plus button. Output would be the calculated sum. If you write a game, input is what the human player does, output is the whole game environment, including what the computer AI played. Later in this workshop you will get to write one or both of these programs.

How about you write a (simple) program that uses input and output. Then turn the page.

Here's one I like, I got the idea from Vivian, our assistant last summer: the game rock-paper-scissors:

Repeat as many times as you want
Repeat 3 times
Pound fist on open hand to synchronize timing
Wait one second
Open fist into flat hand (paper), or two-finger "V" (scissors), or else leave it fist (rock) = output
Look at other player's hand = input
Decide who won (rock breaks scissors, scissors cuts paper, paper covers rock)
Count and show the score = output
Go back for another round

The distinctive thing about this program is that it has two iterations, one inside the other. One of the iterations sort of depends on input (but I didn't say so) to know when to stop, like when the other player gets tired of playing (the computer never gets tired), the other one is exactly three times, no more, no less.

There is only one more concept left to go and you will have everything you need. Actually, you already have it, it was in the very first programs we wrote, both PBJ and Breakfast.

People manipulate stuff -- peanut butter, jam, bread, cereal, plates, bowls, ideas, colors, numbers -- you name it, if you have a name for it, you can manipulate it, if not a physical object, then at least you can manipulate the name!

Computer programs manipulate information: numbers, names, groups of names and numbers representing physical objects or just ideas. In other words, stuff. In the traffic light example the information was what color the traffic light was and what you should do based on that. The information can be very simple, or very complex but it has to go somewhere, in your hand, in the fridge, on the counter, in the bowl, in your head, somewhere. The computer has millions of places to put numbers and names representing ideas and things and stuff. We call those places variables, because what you put there can vary from time to time, like the way the bowl started out with nothing in it, and then it had dry cereal, and then it also had milk, then after a while it had nothing again.

We have now covered everything you need to write any program you want. The ideas aren't new to you but what we've done is give each concept a name and a description of what it is and how it works. Using sequences, iteration, conditions, variables and input/output you can write complex and powerful programs that solve complex and difficult problems. In a moment you will begin writing your first program that a computer, rather than a person, will execute. It will be in a made up computer language that will make it easy to write your own programs and get good breaking down a problem into the 5 components.

There is however a problem. As programs get big, they get hard for humans to read. The computer doesn't have this problem. It just chugs along doing what you told it to do (even when what you told it to do isn't what you really meant, you just told it wrong). But when you tell it wrong, and you will, constantly, you are going to have to figure out what your mistake is. We call this debugging and usually debugging takes way longer than writing the program (especially if the program isn't well organized).

So in order to make is easier for humans to read their own programs programmers invented something where they bundle up a bunch of steps and variables for a task, say "make breakfast" or "make me a PBJ" that you can use. It's like asking somebody to do something for you. Originally in computers we called these subroutines. We use the routine, to describe something we do frequently. In gymnastics they use the same word for the steps that go into a performance. A subroutine is nothing but a whole lot of steps, including sequences, conditionals, variables, I/O that you can use.

So if I was writing a program called Morning it might look like this.

Get up
Go to School

Each of those would be a subroutine containing all the steps (and information) necessary to do that routine.

Write program for each one. Include stoplight, watching for cars, what if it is the weekend.

[Steve thinks you should write lots of programs in English right now. Here are the ideas he came up with:]

[Lots of programs in English now]

If you don't see any programs there you want to write, or when you get tired of writing programs in English instead of something the computer can run, turn the page.

<<Previous | ToC | Next >>

[2021 March 27]