Lec 1 | MIT 6.00 Introduction to Computer Science and Programming, Fall 2008

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseware continue to offer high-quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseware, at ocw.mit.edu. Good morning teacher. Try it again. Good day. STUDENTS: Good morning. TEACHER: Thank you. It's 6:00, also known as Introduction to Computing and Programming. My name is Eric Grimson, I have Professor John Guttag here and we are going to teach the course this quarter. I want to warn you; You're getting some serious firepower this quarter. John was head of department for ten years, it felt like a century, and in the sixth form, I am the current head of department in the sixth form.

John has been lecturing for approximately thirty years. Okay, I'm the young one, I've only been lecturing for twenty-five years. It shows that I have less gray hair than him. What I'm trying to tell you is that we take this course very seriously. We hope you do too. But we think it's very important for the department to help everyone learn about computing, and that's what this course is about. What I want to do today is three things: I'm going to start... actually, I shouldn't say start, I'm going to do a little bit of administration, the kind of stuff you need to know about how we're going to run the course.

I want to talk about the goal of the course, what you'll be able to do at the end of this course when you finish it, and then I want to start talking about the concepts and tools of computational thinking, which is what we're going to mainly focus on here. We'll try to help you learn to think like a

computer

scientist and we'll start talking about that towards the end of this lecture and of course during the rest of the subsequent lectures. Well, let's start with the objectives. I'm going to give you goals on two levels. The strategic objectives are as follows: we want to help prepare first- and second-year students who are interested in specializing in the sixth form so that they can easily enter the department, especially for those students who do not have much prior

programming

experience .

If you are in that category, don't panic, you will get it. We will help you get started and you will surely be able to start the course six syllabus and do well and still finish on target. We don't expect everyone to major in course six, contrary to popular opinion, so for those who aren't in that category, the second thing we want to do is help students who don't plan to major in the course. six to feel justifiably confident in their ability to write and read small pieces of code. For all students, what we want to do is give them an understanding of the role that computing can and cannot play in addressing technical problems.

So you'll get an idea of ​​what you can do, what you can't do, and what kinds of things you should use to tackle complex problems. And finally, we want to position all students so that they can, if they want, easily compete for things like their office and summer jobs. Because you will have an appropriate level of confidence and competence in your ability to solve computational problems. Those are the strategic objectives. Now, this course is primarily aimed at students who have little or no prior

programming

experience. As a result, we believe that no student here is underqualified for this course: you are all MIT students, you are all qualified to be here.

But we also hope that there are no students here who are overqualified for this course. And what do I mean by that? If you've done a lot of programming before, this probably isn't the best course for you, and if you're in that category, I encourage you to talk to John or me after class about what your goals are, what kind of experience you have, and How can we find you a course that best suits your objectives. The second reason we don't want overqualified students in the class, it sounds a little unpleasant, but the second reason is an overqualified student, someone who, I don't know, has been programming for Google for the last five years.

You'll have an easy time in this course, but we don't want a student like that to accidentally intimidate the rest of you. We don't want you to feel inadequate when you simply have no experience. Therefore, it is really a course aimed at students with little or no prior programming experience. And again, if you're not in that category, talk to John or me after class and we'll help you figure out where you want to go. OK. Those are the high-level objectives of the course. Let's talk on a more tactical level about what we want you to know in this course.

What do we want you to be able to do when you finish this course? These are the skills we would like you to acquire. Well, the first skill we want you to acquire is to be able to use the basic tools of computational thinking to write small-scale programs. I'll keep coming back to that idea, but I'll call it computational thinking. And that's so you can write little pieces of code. And, by the way, small is not derogatory here, it simply indicates the size of the things you will be able to do. The second skill we want you to have at the end of this course is the ability to use a vocabulary of computational tools in order to understand programs written by others.

Then you can write, you can read. This last skill, by the way, is incredibly valuable. Because you won't want to make everything from scratch, you'll want to be able to see what someone else is creating and understand what's inside, if it works correctly, and how you can build on it. This is one of the few places where plagiarism is okay. It's not bad, if you want, to learn from the skills of others in order to create something you want to write. Although later we will return to plagiarism as something bad. The third thing we want you to do is understand the fundamental capabilities and limitations of the calculations and the costs associated with them.

And this last statement sounds funny: you don't think that calculations have limits, but they do. There are some things that cannot be calculated. We want you to understand where those limits are. Then you will be able to understand the abilities and limits. And then finally, the last tactical skill that you will gain from this course is that you will have the ability to map scientific problems into a computational framework. Then you can take a description of a problem and map it to something computational. Now if you think about it, boy, it sounds like elementary school. We are going to teach you to read, we are going to teach you to write, we are going to teach you to understand what you can and cannot do and, most importantly, we are going to try to give you the beginning of the ability to take a description of a problem from some other domain and figure out how to map it to that compute domain so you can do whatever reading and writing you want.

Well, in a few minutes we'll start talking about what computing is, how we're going to start building those tools, but that's what you need to learn, that's what you're going to gain from this course by the time you're done. Now, let me take a break for about five minutes to talk about the administration of the course, the administration, the things that we're going to do in the course, so you know what the rules are. Okay, so the class is two hours of lecture a week. You obviously know where and when, because you are here. Tuesday and Thursday at 11:00 a.m.

One hour of recitation a week, on Fridays, and we'll come back to how you'll prepare for that in a second. And nine hours a week of work outside of class. Those nine hours will be primarily working on problem sets, and all problem sets will involve programming in Python, which is the language we will use in this term. Now, one of the things you'll see is that the first few problem sets are pretty easy. Actually, that's probably wrong, John, right? They are very easy. And we are going to increase. By the time you get to the end of the quarter, you're going to have to deal with some pretty complex things, so one of the things you'll see is that we'll be making heavy use of libraries, or code written by others.

It will allow you to tackle interesting problems. I'll have to write from scratch, but it means that this skill here will be really valuable. You need to be able to read and understand that code, as well as write your own. OK. Two questionnaires. During the legislature the dates have already been scheduled. John, I forgot to look for them, I think it's October 2nd and November 4th, it will be on the course website. What I mean is, check out the course website, which is right there by the way. If so, if you know you have a conflict with one of those testing dates now, please contact John or me immediately.

We will arrange something in advance. But if... The reason I say this is that you know that you are getting married that day, for example, we will excuse you from the questionnaire to get married. By the way, we hope you come back soon to take the quiz, but the... Wow, tough people. Alright. If you have any conflicts, please let us know. The second thing is that if you have a special need documented by MIT to take quizzes, please contact John or me well in advance. At least two weeks before the exam. Again, we will take care of this, but you must give us enough notice so we can take care of it.

Well, the questionnaires are open book. This course is not about memory. It's not about how well you can memorize facts: in fact, I think both John and I are a little sensitive to memory tests, given our ages, right John? It's not about how you memorize things, but how you think. So they are open notes, open books. It will really test your ability to think. Course grades will be assigned roughly, and I use the word roughly because we reserve the right to move these numbers around a bit, but basically in the following percentages: 55% of your grade comes from problem sets, rest 45% comes from the questionnaires.

And I should have said that there are two tests and a final exam. I forgot, that final exam during final period. So the test percentages are 10%, 15% and 20%. Which constitutes the other 45%. OK. Other administrations. Let me check my list here. The first problem set, problem set zero, has already been published. This one is really easy. We intend for it to be a really simple set of problems. It's basically for you to load Python on your machine and make sure you understand how to interact with it. The first set of problems will be published shortly, it's also quite boring, kind of like my lectures but not John's, and that means we want you to get to work.

Don't worry, we'll make them more interesting as you go. However, I want to emphasize that none of these problem sets are intended to be lethal. We don't use them to eliminate you, we use them to help you learn. So if you run into a set of problems that you just don't understand, okay? Seek help. It could be psychiatric help, it could be a technical assistant. I recommend the TA. What I mean is come and talk to someone. The problems are set up so that if you start down the right path, it should be pretty easy to solve.

If you start down a plausible but incorrect path, sometimes you can find yourself stuck in the weeds somewhere, and we want to bring you back. So, part of the goal here is that this shouldn't be a grueling, exhausting task, it's really something that should help you learn the material. If you need help, ask John, me, or the TAs. That's what we are here for. OK. We're going to be dealing primarily with a paperless topic, which is why the website is there. Please check it out, that's where everything you need to know will be posted. In particular, go to it today, you will find a form that you need to fill out to register or, rather, register for a recitation.

The recitations are on Fridays. Right now we have them scheduled at 9:00, 10:00, 11:00, 12:00, 1:00 and 2:00. Maybe we'll eliminate one of the recitations, depending on the size of the class, okay? Therefore, we unfortunately reserve the right to have to move it. I'm guessing 9:00 won't be a wildly popular time, but you might surprise me. However, come in and register. We will allow you to sign up for any recitation that makes sense to you. Again, we reserve the right to move people if necessary, just to balance the load, but we want you to find something that fits your schedule and not ours.

OK. Other things. No text required. If you feel exposed without a textbook, you really have to have a textbook, you will find a recommended one. In fact, I'm going to reuse that word, John, at least suggest it, on the course website. I don't think any of us are excited about the text, it's probably the best we've found for Python, okay. If you need it, it's there. But basically we will not rely on any specific text. Good. Related to that: attendance here is obviously not mandatory. You're not in high school anymore. I think we would both love to see your smiling faces, orat least your faces, even if you don't smile at us every day.

However, what I want to highlight about this is that we are going to cover a lot of material that is not in the assigned readings, and we do have assigned readings associated with each of these lectures. If you choose not to show up today, or I'm sorry, you chose to show up today, if you choose not to show up on future days, we will understand, but also understand that the attending attendees will not have much patience with you if you ask a question about something that was covered in the readings. or at the conference and it's pretty simple.

Alright? We expect you to behave responsibly and we will too. Alright. I think the last thing I want to say is that we will not be handing out class notes. Now this sounds like a draconian measure; Let me tell you why. Every study I know of, and I suspect every one John knows of, on learning emphasizes that students learn best when they take notes. Ironically, even if they never look at them. OK. The writing process exercises both halves of the brain and actually helps you learn, so taking notes is really valuable. Therefore we are not going to distribute notes.

What we will distribute for most conferences is a handout that mainly contains code examples that we are going to do. Turns out I don't have one today because we're not going to be doing much coding. We will do it in the future. I guess those notes won't make sense outside of the conference, okay? So it's not just, you can stop by at 11:04 and grab a copy and go to sleep some more. What we recommend is that you use those notes to make your own notes to help you understand what is going on, but we will not provide class notes.

We want you to take your own notes to help you, if you wish, to boost your own learning process. Alright. And finally, I want to emphasize that John, I, and the entire staff, our job is to help you learn. That's what we are here for. That's what excites us. If you're stuck, if you're struggling, if you're not sure about something, ask. We are not mind readers, we cannot know when you are having problems, other than seeing the expression on your face, we need your help to identify that. But all the TAs, many of whom are sitting here in the front row, are here to help, so come and ask.

At the same time, remember that they are students too. And if you come and ask a question that you could have easily answered by reading, attending a conference, or using Google, they will have less patience. But helping them understand things that are really conceptually difficult is what they're here for and what we're here for, so come and talk to us. OK. That takes care of the administrative preamble. John, things we added? PROFESSOR GUTTAG: Two more quick things. This semester, your class will be video recorded for OpenCourseware. If any of you do not want your image to be recorded and published on the web, he is supposed to sit in the last three rows.

PROFESSOR GRIMSON: Oh, thank you. I forgot. PROFESSOR GUTTAG: --Because the camera can pan. I think you are all very handsome and give MIT a good image, so please feel free to be filmed. PROFESSOR GRIMSON: I'll turn around, so if you want to, you know, move back, I won't see who's moving. Good. Excellent. Thanks John. PROFESSOR GUTTAG: The other thing I want to mention is that the recitations are also very important. We will cover material in recitations that is not in the lectures, nor in the reading, and we hope that you will attend the recitations. PROFESSOR GRIMSON: Great.

Thanks, John. Any questions about administration? I know it's boring, but we have to do it so you know what the ground rules are. Good. OK. Let's talk about computing. As I said, our strategic goal, our tactical goals, are to help you think like a

computer

scientist. Another way to say it is that we want to give you the ability to make the computer do what you want it to do. And we hope that at the end of the class, every time you face some technical problem, one of your first instincts is: "How do I write the piece of code that will help me solve it?" That's why we want to help you think like a computer scientist.

Alright. And that's an interesting statement. What does it mean to think like a computer scientist? Well, let's see. The main knowledge that you will learn from this course is this notion of computational problem solving, this ability to think in computational ways of thinking. And unlike many introductory courses, having the ability to memorize won't help you as a result. It's really learning those notions of the tools you want to use. What does it mean to say computational mode of thinking? It sounds like a trivial phrase you use when you're trying to persuade a VC to fund you.

Good. So to answer this, we really have to ask a different question, a related question; So what is computing? It's kind of a strange statement, right? What is computing? And part of the reason for presenting it is that I want, to the extent possible, to answer that question by separating the mechanism, which is the computer, from computational thinking. Good. The artifact shouldn't be what drives this. It should be the notion of "What does it mean to do calculations?" Now, to answer that, I'll go back one more level. And I'm going to pose what seems like a philosophical question: "What is knowledge?" And you'll see in about two minutes why I'm going to do this.

But I am going to suggest that I can divide knowledge into at least two categories. Well, what is knowledge? And the two categories that I'm going to divide them into are declarative and imperative knowledge. Good. What is declarative knowledge? Think of them as statements of fact. They are truth statements. Wow, in this political season, that's a really dangerous phrase to use, right? But it is a statement of fact. I will stay away from political comments. Let me give you an example of this. Good. Here is a declarative statement. The square root of x is y such that y squared is equal to x, and y is positive.

You all know it. But what I want you to see here is that it is a statement of fact. It's a definition. It is an axiom. It doesn't help you find square roots. If I say x is 2, I want to know what the square root of 2 is, well if you're geeky enough you'll say 1.41529 or whatever, but in general, this doesn't help. you find the square root. The closest thing it does is that it would allow you to take the test. You know, if you're walking through Harvard Square and you see an unemployed Harvard graduate, they're handing you examples of square roots, they'll give you an example and you can test it to see, is it the square root of 2, 1.41529 or whatever? be.

I don't even laugh at Harvard jokes, John, I'll stop here in a second, okay? Alright, what am I trying to say here? It's not like that... yes, exactly. We'll stay away from that, very quickly, especially with the cameras rolling. Alright. What am I trying to say? It tells you how you can try something, but it doesn't tell you how to do it. And that is what imperative knowledge is. Imperative knowledge is a description of how to deduce something. So let me give you an example of imperative knowledge. Okay, this is actually very ancient imperative knowledge for calculating square roots, it is attributed to Heron of Alexandria, although I think it is suspected that the Babylonians knew this beforehand.

But there is an imperative knowledge here. Alright? I'm going to start with a guess, I'll call it g. And then I'm going to say, if g squared is close to x, stop. And return g. It's a good enough answer. Otherwise I'll get a new guess by taking g, x over g, adding them and dividing by two. Then you take the average of g and x over g. Don't worry about how it happened, Heron found out about this. But that gives me a new assumption and I'm going to repeat it. That's a recipe. That is a description of a set of steps.

Look at what it has, it has a lot of nice things that we want to use, right? It is a sequence of specific instructions that I do in order. Along the way I have some tests and depending on the value of that test, I can change where I am in that sequence of instructions. And it has a final test, something that tells me when I'm done and what the answer is. This tells you how to find square roots. It is practical knowledge. It is imperative knowledge. Alright. That's basically what computing is all about. We want to have ways to capture this process.

Well, that now brings us to an interesting question, which would be: "How do I build a mechanical process to capture that set of calculations?" So I'm going to suggest that there is an easy way to do it. I realized I made the plates in the wrong order. One of the ways you could do it is, you could imagine building a little circuit to do this. . If you had a couple of stored value elements, had some wires to move things around, had a little thing to do the addition, a little thing to do the division, and something to do the testing, you could build a little circuit that would actually do this calculation.

OK. This, oddly enough, is actually an example of early computers, because early computers were what we call fixed-program computers, meaning they had a circuit designed to perform a specific calculation. And that's what they would do: they would make that specific calculation. You've seen them a lot, right? A good example of this: the calculator. It is basically an example of a fixed program computer. He does arithmetic. If you want to play video games, good luck. If you want to process word, good luck. It is designed to do a specific thing. It is a fixed program computer. In fact, a lot of the really interesting early ones have this similar flavor, to give an example: I Never Know How to Pronounce This, Atanasoff, 1941.

One of the first computational things was something designed by a guy called Atanasoff, and it basically solved linear equations. Something useful if you're doing 1801, okay, or 1806, or whatever you want to do those things. However, all he could do was solve those equations. One of my favorite examples of an early computer was created by Alan Turing, one of the great computer scientists of all time, called bombe, which was designed to crack codes. In fact, it was used during World War II to crack the German Enigma codes. And what it was designed to do was solve that specific problem.

What I'm trying to point out is that we started with fixed program computers, but they don't really get us where we would like to be. We want to capture this idea of ​​problem solving. So let's see how we get there. So even within this framework, given a description of a calculation as a set of steps, with the idea that you could build a circuit to do it, let me suggest what would be a wonderful circuit to build. Suppose you can construct a circuit with the following property: The input to this circuit would be any other circuit diagram.

Give it a circuit diagram for some calculation, give it to the circuit and that circuit will reconfigure itself beautifully to act as the circuit diagram. Which would mean it could act as a calculator. Or it could act like the Turing bomb. Or it could act as a square root machine. So what would that circuit be like? You can imagine these little robots wandering around, right? Pulling cables and removing components and stacking them. How would you build a circuit that could incorporate a circuit diagram and make a machine act like that circuit? It sounds like a big challenge.

Let me change the game a little. Suppose I want a machine that can take a recipe, the description of a sequence of steps, take it as input and then that machine will act as described in that recipe. Reconfigure it, emulate it, however you want to use the words, it will change the way you do the calculation. That would be great. And that exists. It's called an interpreter. It is the basic heart of every computer. What you are doing is saying: changing the game. This is now an example of a stored program computer. What that means, on a computer with stored programs, is that I can provide the computer with a sequence of instructions that describe the process I want it to execute.

And inside the machine, and things we'll talk about, there is a process that will allow that sequence to run as described in that recipe, so it can behave like anything you might describe in one of those recipes. Alright. It actually looks like a really nice thing to have, so let me show you what it would basically look like. Inside a computer with stored programs, we would have the following: we have a memory, it is connected to two things; control unit, in what's called an ALU, an arithmetic logic unit, and this can take inputs and spit out outputs, and inside this stored program computer, excuse me, you have the following: you have a sequence of instructions.

And all of these are stored there. Notice the difference. The recipe, the sequence of instructions, is actually read and treated as if it were data. It's inside the machine's memory, which means we have access to it, we can change it, we can use it to build new pieces of code, and we can alsointerpret it. Another piece that goes inside this computer. I never remember where to put the PC, John, the controller? ALU? Separate? I'll put it separately: you have something called a program counter. And here is the basis of the calculation. That program counter points to some location in memory, usually the first instruction in the sequence.

And those instructions, by the way, are very simple: they're things like, take the value from two places in memory, and pass it through the multiplier here, a little circuit, and put it back somewhere in memory. Or take this value out of memory, execute it through some other simple operation, and put it back in memory. Having executed this instruction, that counter goes up one and we move on to the next one. We execute that instruction, we move on to the next one. Oh yes, it looks a lot like that. Some of those instructions will involve testing: they will say, is something true?

And if the test is true, it will change the value of this program counter to point to some other place in memory, some other point in that sequence of instructions, and you continue processing. Hopefully, you'll eventually stop, spit out a value, and that's it. That is the heart of a computer. That's a small mistake. The process of controlling it is intriguing and interesting, but the heart of the computer is simply this notion that we build our descriptions, our recipes, on a sequence of primitive instructions. And then we have a flow of control. And that flow of control is what I just described.

It moves through a sequence of instructions, occasionally changing where we are as we move. OK. What I want you to learn from this, then, is to think of this as, if you will, a recipe. And that's really what a program is. It is a sequence of instructions. Now, one of the things I left up in the air is that I said, Okay, build it from primitives. So one of the questions is, well, what are the right primitives to use? And one of the things that was useful here is that we actually know that the set of primitives that we want to use is very simple.

Okay, but before we do that, let me clarify this idea of ​​why this is a recipe. Assuming I have a set of primitive instructions with which I can describe everything, I want to know what I can build. Well, I'm going to make the same analogy with a real recipe. So, real recipe. I don't know. Separate six eggs. Do something. Beat until... sorry, beat the egg whites until stiff. Do something until a final test is true. Take the yolks and mix them with the sugar and water... No. I guess sugar and flour is probably what I want, sugar and water aren't going to do anything interesting for me here... mix them with something else .

Make a sequence of things. In reality, a traditional recipe is based on a small set of primitives, and a good chef with that set of primitives, or a good cook, I should say, can create an unlimited number of excellent dishes. The same goes for programming. Good. Given a fixed set of primitives, a good programmer can program anything. And by this I mean that anything that can be described in one of these processes, can be captured in that set of primitives. Alright, the question is, as I started to say, "What are the correct primitives?" So here's a little bit, a little piece of history, if you will.

In 1936, that same guy, Alan Turing, showed that with six simple primitives, anything that could be described in a mechanical process, actually algorithmically, could be programmed simply using those six primitives. Think about that for a second. That is an incredible statement. He says that with six primitives I can rule the world. With six primitives I can program anything. A couple of really interesting consequences of this, by the way, one of them is, he says, anything you can do in one programming language, you can do in another programming language. And there's no programming language that's better... well, actually, that's not entirely true, there are some better ones for doing certain types of things... but there's nothing you can do in C that you can't do. in Fortran.

It's called Turing compatibility. Everything you can do with one, you can do with another, is based on that fundamental result. OK. Now, fortunately we're not going to start with the six Turing primitives, this would be really painful programming, because they're at the level of "take this value and write it to this tape". First of all, we don't have tapes in computers anymore, and even if we did, you don't want to program at that level. What we will see with the programming language is that we will use higher level summaries. A broader set of primitives, but nonetheless the same fundamental remains.

With those six primitives, you can do it. OK. So where are we here? What we're saying is that, to do calculations, we want to describe recipes, we want to describe this sequence of steps built on some primitives, and we want to describe the control flow that goes through that sequence of steps as we continue. So the last thing we need before we start talking about actual programming is to describe those recipes. Very good, and to describe the recipes, we are going to need a language. We need to know not only what the primitives are, but also how we make things have meaning in that language.

Language. Here we go. Alright. Now it turns out there are... I don't know, John, hundreds? Thousands? Of programming languages? At least hundreds of programming languages ​​available. PROFESSOR JOHN GUTTAG: PROFESSOR ERIC GRIMSON: True. Thank you. You know, they all have, you know, their advantages and disadvantages. I have to admit, in my career here, I think I've taught in at least three languages, I suspect you've taught more, five or six, John? We have probably both programmed in more than that number of languages, at least we have programmed that many, since we teach in those languages. One of the things to realize is that there is no best language.

At least I would say that, I think John would agree. We could both agree that we have our own nominees for worst language, there are a few of those. There is no best language. Alright? They all describe different things. That said, some of them are better suited for some things than others. Has anyone here heard of MATLAB? Maybe programmed in MATLAB? It's great for doing things with vectors and matrices and things that are easily captured in that framework. But there are some things that are really difficult to do in MATLAB. So MATLAB is great for that kind of thing.

C is a great language for programming things that control data networks, for example. Turns out I am, and John makes fun of me regularly, I'm an old-time Lisp programmer and that's how I was trained. And I happen to like Lisp and Scheme, it's a great language when you're trying to deal with problems where you have arbitrarily structured data sets. He's particularly good at it. So what I want to point out here is that there is no particularly better language. What we are going to do is simply use language that helps us understand. So in this course, the language we will use is Python.

It is a fairly new language, it is gaining popularity, it has many elements of other languages ​​because it is more recent, it inherits things from its pregenitors, so to speak. But one of the things I want to emphasize is that this course is not about Python. Strange statement. You need to know how to use it, but it's not about the details of where semicolons go in Python. Alright? It's about using it to think. And what you should learn from this course is having learned how to design recipes, how to structure recipes, how to do things in modes in Python.

Those same tools transfer easily to any other language. You can learn another language in a week, a couple of weeks at most, once you know how to use Python. OK. To talk about Python and languages, I want to do one last thing to set the stage for what we're going to do here, and that's talk about the different dimensions of a language. And there are three I want to deal with. The first is whether it is a high-level or low-level language. It basically says: how close are you to the heart of the machine? A low-level language, we used to call it assembly programming, you're at the level of, your primitives literally move pieces of data from one memory location to another, through a very simple operation.

A high-level language, the designer has created a much richer set of primitives. In a high-level language, the square root might just be a primitive that you can use, rather than having to go through and code it. And there are trade-offs between the two. The second dimension is whether it is general or specific language. And by this I mean, does the set of primitives support a wide range of applications or is it really targeted at a very specific set of applications? I would say that MATLAB is basically a language aimed at matrices and vectors and things like that.

And the third thing I want to point out is whether it is an interpreted or compiled language. What it basically says is this: in an interpreted language, you take what is called the source code, what you write, it can go through a simple verifier but basically it goes to the interpreter, that thing inside the machine that is going to control the flow to follow each of the instructions and give you a result. So the interpreter simply operates directly on your code at runtime. In a compiled language, there is an intermediate step, where you take the source code, run it through what is called a checker or a compiler or both, and create what is called object code.

And that does two things: one, it helps detect errors in your code, and second, it often turns it into a more efficient sequence of instructions before executing it. Alright? And there are trade-offs between the two. I mean, an interpreted language is usually easier to debug because you can still see the raw code there, but it's not always as fast. A compiled language is usually much faster in terms of execution. And it's one of the things you might want to negotiate. Good. In the case of Python, it is a high-level language. I would say, I think John would agree with me, that it's basically a general purpose language.

It turns out that it's better suited for manipulating strings than numbers, for example, but it's actually a general-purpose language. And it's mainly... I shouldn't say mainly, it's an interpreted language. OK? As a result, it's not as good as helping you debug, but it allows you to... sorry, that's the wrong way to say it, it's not as good at detecting some things before you run them, at times it's easier to debug. as you move forward on the fly. OK. So what does Python look like? To talk about Python (in fact, I'll do it this way), we need to talk about how to write things in Python.

Once again, you have to let me back up a little and set the stage. Our goal is to build recipes. You will all be great chefs when you finish here. Alright? Our goal is to take problems and break them down into these computational steps, this sequence of instructions that will allow us to capture that process. To do that, we need to describe not only what the primitives are, but also how we legally capture things in that language and interact with the computer. And for that we need a language. We're about to start talking about the elements of language, but to do so, we also need to draw out one last distinction.

As with a natural language, we are going to separate the syntax from the semantics. So what is syntax? The syntax basically says, what are the legal expressions in this language? Wow, my handwriting is atrocious, isn't it? There is a sequence of words in English. It's not since then syntactically correct, is it? It's not a phrase. There's no verb anywhere, it's just a sequence of nouns. The same in our languages. We have to describe how legally formed expressions come together. OK? And as we add constructs to the language, we'll talk about it. The second thing we want to talk about very briefly as we move forward is the semantics of the language.

And here we are going to divide two pieces; Static semantics and complete semantics. Static semantics basically say which programs are meaningful. What expressions make sense. Here is a phrase in English. It is syntactically correct. Good? Noun phrase, verb, noun phrase. I'm not sure it means anything unless you're in the habit of giving personal names to your furniture. What is the point? Again, you can have things that are syntactically legal but not semantically meaningful, and static semantics will be a way to help us decide which expressions, which pieces of code, actually have real meaning. Alright? The last part is that in addition to having static semantics, we have a kind of complete semantics.

That is, what does the program mean? Or, put another way, what will happen when you run it? That is the meaning of the expression. Is that what you want. Alright? Do you want to know what is the meaning of this code snippet? When I run it, what is going to happen? That's what I want to build. The reason for bringing this up is that what you'll see is that in most languages, and certainly in Python(we get a lot of help here), alright, Python comes built in with something that will check your static, sorry, syntax for you.

And in fact, as a sidebar, if you turn in a problem set that isn't syntactically correct, there's a simple button you press that will check your syntax. If you have delivered a program that is not syntactically correct, TAs give you a zero. Because it said you didn't even take the time to make sure the syntax is correct. The system will help you find it. In Python, you'll find it, I think one bug at a time, right John? He finds one syntax error at a time, so you have to be a little patient doing it, but you can check that the syntax is correct.

You'll see here we get help on static semantics, and I'll do an example in a second, which means some system languages ​​are better than others, but I'll try to help. you detect some things that are not semantically correct statically. In the case of Python, I think it does everything at runtime. I'm looking at you again, John, I think there are no prior checks. I'm sorry? PROFESSOR JOHN GUTTAG: PROFESSOR ERIC GRIMSON: There are some. OK. However, I think most of them are detected primarily at runtime and it's a little annoying because you don't see it until you run the code, and there are some, in fact we'll look at an example, I think in a second, where you find it, but you get some help there.

The problem is that the things you detect here are actually the least worrying errors. They are easy to spot, you can't run the program with them there, so you won't get strange responses. Not everything will be caught up in checking static semantics. Some things are going to go unnoticed, and that's actually a hassle. It's a problem. Because it says your program will still give you a value, but it may not be the one you intended and you can't always know that, and that can propagate through a bunch of other calculations before it causes some catastrophic failure. .

Actually, the problem with static semantics is that you'd like it to catch everything, but you don't always get it. Unfortunately we don't get much help here. Which is where we would like. But that's part of your job. OK. What if you actually have something that is syntactically correct and appears to have correct static semantics and you run it? It could run and give you the right answer, it could fail, it could repeat forever, it could run and apparently give you the right answer. And you won't always be able to know. Well, you'll know when it fails, that doesn't help you much, but you can't always tell if something is stuck in an infinite loop or if it's just taking too long to calculate.

You would love to have a system that detects that for you, but it's not possible. And to deal with the latter, it is necessary to develop style. Alright? That is, we're going to try to help you develop a good programming style, but you need to write in a way that makes it easy for you to spot the places that cause those semantic errors to occur. Alright. If this seems like a very long preamble, it is. Let's start with Python. But again, my goal here is to let you see what computing is all about, why we need to do it.

I'll remind you one last time that our goal is to be able to have a set of primitives that we combine into complexes. expressions, which we can then abstract to treat as primitives, and we want to use that sequence of instructions in this control computing flow, to deduce new information. That imperative knowledge we talked about right there. So I'm going to start today, I think we have about five or ten minutes left in order... sorry, five minutes left... to do this with some Python principles, and we're going to choose This obviously, next time, so; Simple Python Parts.

To create any type of expression, we will need values. Primitive data elements. And in Python, to start we have two; we have numbers and we have strings. Numbers are what you would expect. There is a number. There is another number. Alright? Strings are captured in Python with an open quote and a sequence of characters followed by a closed quote. Associated with each data type in Python is a type, which identifies the type of thing it is. Some of them are obvious. Strings are just a type in themselves. But for numbers, for example, we can have a variety of types.

This is something we would call an integer or INT. And this is something we would call floating point or float. Or if you want to think of it as a real number. And there are some others that we can see. We'll elaborate on this taxonomy if you want, but the reason it's relevant is that associated with each of those types is a set of operators that wait for certain types of input to do their job. And given those types of input, you will get results. Alright. To fix this, let me show you an example and hope it comes up, great.

What I have here is a Python shell and I'm just going to show you some simple examples of how we start building expressions. And this will lead to what you will see next time and what you will do tomorrow. So. Starting with the shell, I can write expressions. In fact, let me go back and do this on video. I can type a number, I get a number, I can type a string, I get the string. Strings, by the way, can have spaces, they can have other characters, it's just a sequence of things, and notice, by the way, that the string five...

I'm sorry, the digit five digit two in the string is different from the number 52. The quotes are around them to make that distinction. We'll see why in a second. By the way, what I'm doing here is simply writing expressions in that interpreter. You are using your ruleset to deduce the value and reprint it. What I would like to do here is I would like to do combinations of things with these. That is why we have associated a set of operations with simple things. So for numbers, we have the things you would expect: arithmetic. And let me show you some examples of that.

And in fact, I'm going to make another distinction here. What I wrote, things like... well, let me start this way... there is an expression. And in Python the expression is operand, operator, operand, when we do simple expressions like this, and if I give it to the interpreter, it returns exactly what you would expect, which is that value. OK? The distinction I'm going to make is that that is an expression. The performer will get value for it. When we start developing code, we will use commands. Or statements. Which are actually things that take a value and ask the computer to do something with it.

So I can do this in a similar way, which will look strange because it will return the same value, but it actually did something slightly different. And by the way, notice that when I wrote it, the print appeared in a different color. That's the Python saying, it's a command, it's a specific command to get the value of the expression and print it again. When we start writing code, you'll see that difference, but for now, don't worry, I just want to plant that idea. OK. Once we have that, we can certainly do things like this. Notice the quotes around it.

And it treats it as a string, it simply returns the value of that string, 52 by 7, instead of the value of it. Now, once we have that, we can start doing things. And I'm going to use print here... if I could write, to get into it, I can't write, here we go... to get into the habit. I can print a string. I can print-- Ah!-- Here's a first example of something catching one of my things. This is a static semantic error. So what happened here? I gave him an expression that had an operand in there. I was expecting arithmetic types.

But I gave two threads. And then he complains to me, saying: you can't do this. I don't know how to take two threads and multiply them. Unfortunately, John, you may not agree with me on this point; Unfortunately, in Python you can, however, do things like this. What do you think that will do? Does it look legal? Is the string three times the number three? Well, it turns out that he gives me three threes in a row. I hate this. Sorry, John, I hate this. Because this is overloading that multiplication operator with two different tasks. He's saying, if you give me two numbers, I'll do the right thing.

If you give me a number and a string, I'll concatenate them, they're really different operations, but anyway, that's what it will do. STUDENT: PROFESSOR ERIC GRIMSON: There you have it. You know, there will be a rebuttal phase a little later, just like with political debates, and he likes it as a feature, I don't like it, you can tell he's not a Lisp programmer and I am. He's fine. I want to do just a couple more quick examples. Here's another one. Ah ha! Give you an example of a syntax error. Because 52A doesn't make sense. And you might say, wait a minute, isn't that a string?

And the answer is no, I didn't say it's a string by putting it in quotes. And notice how the machine responds differently. In this case he says it's a syntax error and actually highlights where it came from so you can go back and fix it. Alright. Let's do a couple of other simple examples. Alright? I can do multiplications. I've already seen that. I can do sums. Three plus five. I can take something to a power, double star, it is enough to take three to the fifth power. I can do division, right? Oh. Good? Is three divided by five zero?

Maybe in the Bush economy... no, I'm not going to make any political comments today, I'm not going to say that, okay? What happened? Well, this is one of the places where you have to be careful. He is doing integer division. So three divided by five is zero and the remainder is three. So this is the correct answer. If you wanted to get a real, complete split, you would have to make one of them a float. And yes, you can look at that and say, is that right? Well, up to a certain level of precision, yes, that's 0.6 is what I would like to get.

Alright. I can do other things. In particular, I have similar operations on strings. Well, I can certainly print strings, but I can actually add strings and, as you saw, I can multiply strings, you can guess what this is going to do. It will merge them into one thing. I want to... I know I'm going over it a little bit, I want to do one last example, I also want to be able to have variables to store things. And to do that, in this it says, if I have a value, I want to hold it, to do that, I can do things like this.

What does that statement do? It says, create a name for a variable, which I just did there, in fact, let me write it in: mystring, with an equal sign, which says, assigns or binds to that name the value of the following expression. . As a consequence, I can now refer to it only by its name. If I get the value of mystring, there it is, or if I say, take mystring and add the string to it, mylastname, and print it again. So this is the first beginning of this. What have we done? We have values, numbers and strings.

We have operations to partner with them. I just threw up a couple here. You'll have a chance to explore them and you'll see that not only are there standard numbers for strings, but there are also things like length or plus or other things you can do with them. And once I have values, I want to control them so I can give them names. And that's what I just did when I tied it up. I said, use the name mystring to be bound or have the value of Eric, so you can reference it anywhere else you want to use it.

And I apologize for taking over you, we will come back to this next time, go to the website to register for tomorrow's recitation.