1. Overview

What is programming? It is a particular way for us humans to give instructions to a computer to interpret, to calculate and to present things. It should not be approached as something totally new, but instead it should be thought of as an extension of the basic, pen-and-paper mathematics and physics you have learned from elementary school, high school, and onwards. In this course, we will try to convince you that you know a lot more programming than you think you do already. Counting is an example, as is flipping a coin or decision making. If you can take the function , calculate some values of it and plot an approximate curve, then you are already doing a fair amount of programming.

An algorithm is a set of step-by-step commands to take some set of inputs and produce something, like output(s) or a new state. We implement algorithms in a code (or program, or script), so that the steps can be understood by another human or by a computer using a particular language. When we look at pre-existing codes, they might look complicated and hard to understand at first, but all programs are made up of small pieces assembled together. After you have learned how to make the smaller pieces, it is much easier to understand how the program works, and how to build your own program. You might be surprised what a few small pieces of code can accomplish together! Ideally, programming should help you with problem-solving or displaying data, and even allow you to express your creative side.

To communicate our expressions to the computer successfully, we have to learn the correct ways to form our statements, equations and expressions. Just as vocabulary and grammar form the way we speak and understand everyday language, so keywords and syntax respectively form the basis of the expressions used in a programming language. When communicating with other people, we can be approximate, or assume knowledge, or make grammatical mistakes, and our meaning might still come across OK to the other person. However, computers are much more limited than people, and we have to use very specific phrasing and terms in most cases. We will spend a lot of time here learning these syntaxes, and we need to be precise when programming. We also need to learn how to correct our programs (or debug them) if we make a mistake in them.

We will introduce technical terms throughout these notes. The sooner you bring these into your own vocabulary, the better. Using technical terms will ultimately speed up the process of building comprehension, asking questions, reading help files and interpreting (and fixing!) error messages. At the same time it is a good idea to develop your own general/conceptual understanding of the pieces of programming: how do you envision these pieces in your mind? This is something that everybody must do on their own, typically through lots of practice and perhaps asking questions. Trial-and-error helps helps delineate things---it OK (and even useful) to make mistakes and to learn from them.

On that note, we emphasize that error messages are nothing to be afraid of while programming. You should not feel bad about seeing them. Everyone gets them. The Python interpreter is merely trying to help point out where it is having trouble understanding you---so let it, and work with it! Part of programming is gaining experience with interpreting error messages. We try to point out common mistakes and resulting error messages throughout these notes: learning to interpret these messages is one key to being successful in programming.

In fact, it is worse to not see error messages sometimes. Subtle mistakes that don't cause warning flag are much, much worse than syntax errors, since they are much harder to find. The only way to find these kinds of errors is to test the code by producing known results (e.g., something we can calculate by hand, or know from some other background knowledge). Don't just trust an output because your program did not crash! The more you know about what you should be getting from a code, the more likely you are to prevent errors from creeping in. Ironically, using a program to solve a problem still requires us to know a lot about it with good ol' pen and paper.

There is more "art" and flexibility to writing a program than many people think. It is a bit like writing a story: multiple authors can narrate the same plot, but the way a story is organized and developed makes a big difference in how we evaluate it. We will cover some good habits to incorporate into your own programming style, which should really will help you. Even within this loose framework, there is also freedom to develop your own style that works for you. Try out some ideas in a code, and then redo them later. But remember: you are often programming for your future self, so be kind to that person, and try to keep things as clear as possible. When you give a speech, you try to choose clear, elegant phrasing and meaningful words; why should programming be any different?

In summary:

• "Programming" is not something totally new or alien: it is essentially a dialect of mathematics and physics. In fact, here we approach programming as translating math/physics from paper to a computer. With this outlook, many of the syntaxes should start to look familiar and helpful---and they were actively designed to be so!

• The most important part of programming takes place before you even sit at a computer: it is formulating the problem, and any steps/algorithm to address it, clearly on paper.

• Don't be afraid of error/debugging messages: read them and remember them, and after a while they become just small speedbumps in your programming, rather than roadblocks.

• The only way to get better at programming is with practice, so please do follow along with the examples in these notes. Try the practice problems. When something isn't clear, investigate more and ask questions.

• We hope programming can be enjoyable and creative. Hopefully solving problems, making plots and presenting data can be interesting. Feel free to expand any question and explore programming further.