Welcome to Computer Science E1. My name is David Malin, and this is lecture 11, programming. So in a lecture about programming, clearly there will be just a discussion about programs, which begs the question, what is a program? You don't need that in the background, the whole lecture. A set of instructions. Good. So it's a set of instructions that tell a computer to do something or how to do something. And we visited this issue of software and programs back when. Lecture two, kind of, more so lecture three. And even in lecture three, we kind of cheated and just hit play on the VCR. But yeah, we had lecture three entitled software, whose focus was predominantly on operating systems. But we said after that lecture that operating systems are about a type of software or a type of program. They simply tell the computer what to do upon immediately starting up. Well, what does it mean then to write a program? To write that set of instructions. So yeah, as you might imagine, people who write such sets of instructions, people who write software are called programmers, otherwise known as software developers. And tonight's lecture is entirely about the role that such folks as these play in the world of information technology, the development of software, the writing of programs. Tonight's lecture is about programming. Now, as you know, you could take entire courses, whether at extension or at other universities, on programming. And we do not aspire to be so bold as to claim we will teach you programming in computer science E1 in but two hours of lecture and a couple of hours of section. But what you will have by the end of tonight's lecture, as well as if you attend locally the upcoming sections and workshop on programming, is a taste of what it means to write programs. And you'll have a sense of the vocabulary and the jargon that's relevant to this world of programming. And if nothing else, what I think you'll walk away is a sense of what could be in store for you if you decide to proceed, for instance, after you go on to something like an extension E50A, E50B, or really any programming course anywhere. You'll get a teaser tonight of what it's all about. But we're going to start tonight, as we often do in more real terms. To write a program means to tell a computer how to do something. Well, to write a program might similarly be to tell a robot how to do something, if you assume that a robot is, for all intents and purposes, some sort of computer. Or rather, you could program a human by feeding that human a set of instructions that tells that human what to do or how to do it. So I leave it to you to instruct me, tonight's robot or human, however you wish to view me tonight, how I would go about looking up Ray Diaz's phone number in a phone book. I am a blank slate. I will do exactly what you tell me. Tell me how to look up Ray Diaz's phone number in these white pages. Pick up phone book. All right? I'm sorry? Open a page. D, be more specific. Open a page to D. OK? The top of the D pages, OK? There you have it, the D pages. Go down. Search, I heard. Search for, go down what? Got to be more specific. DI, OK. So it's not there. It's not there. DIE, I think if we do DIE, we're going to go too far. Diaz. That's OK. DIA, we'll go with DIA, OK? So I'm at the DIAs now to the end of the line to get to Z and so forth. So that's a pretty good start to the program. Start at the Ds and then work your way forward page by page, maybe not being so dramatic as to rip the pages out. But page by page, stop once you hit DIAz. Well, that's pretty good. Let's see if we can't do better. What you essentially had me doing there was starting at the beginning, maybe the A's. Then I did jump in fairness to the Ds, but then you had me turning page after page after page, which would be called in the world of computer speak, a linear running time algorithm, linear being in the sense that we are checking each and every page as though we're following a line, page by page by page. Now, unfortunately, this phone book, for instance, has 1268 pages. So had you really had me start at the beginning, or even the beginnings of the Ds, that might have taken quite a while. It might have taken, if I was looking for not Ray Diaz, but someone whose name starts with a Z, that might have taken us 1200 steps, 1200 seconds, whatever the units of time are, depending on how quickly I count. So can we do better than that? Something better than this linear approach. OK, find a heading that might have R, I, or we did it again. OK, let's back up tonight. So our teaching fellow's name tonight is Ray Diaz. Now, I can understand if you might have goofed on the first name, since it is a little atypical. But Diaz is DI, AZ, yeah. Well, that's interesting. OK, so we need some sort of search mechanism. Among the key phrases I heard you just utter were split it in half. If I infer a bit more, maybe more of a divide and conquer strategy. Maybe in the most naive sense, I start off with my algorithm and I say, all right, let's see where we are. I seem to be in the Ms, which makes sense since I'm in halfway through the phone book. So what do I want to do next? Maybe a loop, this is clearly going to be a loop, because we are going to be repeating. And our goal, to be clear again, is to make more efficient this looping process. Rather than flipping every darn page, as many as 1,200 of them, can we loop more efficiently? So I heard something over here. When I'm at the Ms, what do I want to do? OK, go earlier. So look at now the left-hand side of this phone book. What do you want to have me do with respect to the left-hand side of the phone book? All right, so let's divide the problem again. Now I seem to be at the end of the C's. Well, good. C is less than D, so go back now to the right-hand side of the section I just split. And technically, I could have remembered where I was. So here's the right-hand side now, because I opened it to the C's, so I'm now going to go to the right at that pile, and what am I going to do with this part? OK, split it roughly in half again, maybe for simplicity. Now I've split it in half. Now I seem to be on the H's. So I went from the Ms to the C's to the H's. Which way do we want to go? Right, to the left, because H is after D, but C was before D. The goal of, of course, being D as, so I'm going to split this part in half. Now I'm on the F's. Which way would you have me go? OK, to the left, were there an equal number of names in the phone book incidentally starting with each of these letters of the alphabet, it would make more sense what letters were hitting. But it turns out that there were a lot of C's. Otherwise we might have hit D's from the get-go. OK, I've just split it again. And now we go from F's to D's. Specifically, we are at the DO names. Too far to the right, so I split to the left again. Now I'm at DA. This time I go to the right. So we're honing in on our goal. Now I'm at the DIC's. OK, so we're going to the left. OK, now we're too far back. We're at the DE's. So I'm going to go to the right, which brings me back to the DIA's, but it's D-I-A-M. So we're almost there. Two pages left. So now I open these two pages. I've got DIA's here and DIA's here. But the end of the second page is DIC again. So right DA's is presumably somewhere on this page. Now what would I do to finish up this problem? Maybe same exercise by line. Maybe start roughly in the middle. OK, it's not there. All right, let's look halfway in the page. Not there. Well, let's look halfway in that column, and so forth. In short, it would be naive, though correct, to start at the front of any phone book and flip page by page, line by line, to find the goal, when rather you can divide and conquer this kind of problem by split it in half, make a decision, split the problem in half, make a decision, split the problem in half, make a decision. And just to help you appreciate the ramifications of that sort of approach vis-a-vis this approach, which again, to be dramatic, was starting at the front, it's not on this page. Next page, it's not on this page. Not on this page. This could go on for 1,200 more pages. But appreciate what's going on now. In the second approach, we split it in half. And again, to be dramatic, what can we now do with this half of the problem? We're done with that, which means I have now whittled this problem down into something half is large, which means I can solve it, in theory now, twice as fast. Well, what did we next do? Well, we split it in half again. And we ended up, embarrassingly, at the Fs. But I've just whittled my problem down by yet another half of what it just was, meaning I've just doubled my performance yet again, and so forth, and so forth. In short, we seem to be going at a much faster clip this time. An interesting question then is, how much faster? To put it into more real terms, if you had a phone book with, say, roughly 1 million pages in it, and you were to employ the so-called linear search algorithm that we first applied, linear meaning walk along a straight line, just flipping page by page by page, in the very worst case, how many pages might you flip whilst looking for someone's number in a phone book? A million. Under what circumstances might you waste that much time looking for someone's number? If it's someone whose name starts with a z, but you, again, rather naively, though correctly, began at the front of the phone book. And I mean it's correct, though naive, because it will clearly get you the answer. But it's naive in the sense that it's terribly inefficient. So in the worst case, with a linear running time algorithm, and an algorithm, as an aside, it's just a procedure, a process, a program of sorts. So this, in a linear algorithm, might take some 1 million steps. Now here's the kicker. With the more intelligent algorithm that we employ just now, whereby we split the problem in half, and half, and half, in the worst case, how many pages will I look at in search of, say, Ray Diaz's phone number? Out of those million. 50? Even better. Think about what's happening. If you start with a million page phone book and split it in half, well, you've just thrown away 500,000 pages. So in the worst case, you're going to look through no more than 500,000 pages because you threw the others away. But we didn't stop there. We split those 500,000, according to this algorithm, into 250,000. We then split those 250,000 into 125. Repeat, repeat, repeat. So really, the question boils down to how many times can you split the initial value 1 million in half? 20. 20. So roughly 20, which is pretty mind-blowing. First of all, this is going to be a pretty thick phone book we're thinking about. But what I claim with an algorithm like this, you can split that problem and find Ray Diaz's phone number, even in a phone book, this high of 1 million pages by looking at just 20 or so of them, give or take. And then, of course, you might have to skim the whole page to find his specific number, but who cares? At that point, if you've only looked at 20 pages, you can afford the time to skim the book itself. So this is an example of design with respect to a program. It does not suffice when writing programs just to sit down and write a correct solution. Often important is to write a good solution. Consider after all the real-world ramifications. So Google indexes what? Several billion web pages these days? When you type in pink flamingos and hit Enter on Google, does it employ a linear search algorithm to scour those billion or so pages for pages mentioning pink flamingos? I mean, hopefully not. It would be correct to do so, because if there are pages about pink flamingos, would the algorithm find them? Well, absolutely. Eventually, it would examine every page in its database. But it'd be incredibly frustrating to the millions of users of Google, each of whom is now being made to wait while some billion odd pages are examined. So this is to say that in the real world, especially in problems like web searching that involve program design, just exercising even a modicum of intelligence when it comes to clever design tricks like we employed in this latter case have huge performance gains. Many of you have probably been frustrated, for instance, by the amount of time that it might take to spellcheck a document sometimes, particularly if your computer is somewhat slow. Or what other processes on a computer seem to take frustratingly long, even these days or in years past? OK, email sending receiving? So receiving email, I would attribute those kinds of slowness with email to something that's more based on bandwidth than algorithms. Because you can't really get too clever with downloading an email. Either you get it or you don't. If you were, for instance, searching huge emails, maybe you could exercise a bit of cleverness here. But emails are perhaps slightly outside of the context of this. Maybe some of you at work who deal with databases sometimes and have to perform queries or update databases. Maybe some of you who as consumers sometimes call Verizon or Comcast, or really any big company that maintains a user database. And you get this not unfamiliar apology from this representative on the other line saying, oh, I'm sorry, our systems are kind of slow today. Well, why are they slow? Well, one reason could, of course, be slow, old hardware. But another reason could simply be bad design. And this is not the only problem in the world that there's such a dichotomy between poor design and good design, but it's representative, certainly, of many different problems that sort of appear in the real world and in real systems. Absolutely. Absolutely. So the less work that your algorithm is predefined to do, the less expensive can be, the smaller can be, the resources that you throw at that problem as well. Absolutely. Well, let's just slap a term on the algorithm that we described here that was not one million steps, but rather closer to 20 steps. Mathematically, what do you call a function or an algorithm that involves splitting something in half again and again and again and again? Sorry. Not quite. It might not jump off the tongue.  So if you remember those things from school, logs or natural logs, these kinds of things, we're not going to get into the mathematics of this. But something that's logarithmic means that the relationship to the size of the original number is ultimately one in which you keep splitting that value again and again and again. And we'll leave it at that just to toss the buzzword at it. But what you've just seen is an example of a logarithmic running time, divide and conquer, splitting this thing in half, aka binary search. That was a binary search algorithm when I kept splitting the phone book in half, in half, binary. Why? I kept dividing the problem into two. Hence it's a binary search in contrast with the original linear search. Well, let's try it as more context sensitive question. If I wanted to count the number of students in attendance tonight, how would I do that?  How do I count the number of students in the room? I heard that.  Just point and count. That's perfectly true. So one, two, three, four, five. You tell me if there are n students in the room, how many steps is this counting algorithm going to take? n. Where have we seen something like that before? In the worst case, how long is that algorithm going to take? Well, n steps. In fact, in every case, unless I want to ignore certain people in the room, but that means it's just what? Another linear running time algorithm. Can we do better? Can you count students faster in the room than I can? OK, so we could count by two. So I could say two, four, six, eight, 10. Absolutely. So we've sort of doubled our running time there. Can we do even better than that? Well, don't cheat and say start counting in three's or four's, because that starts to get hard. We could absolutely. Can we do fundamentally better than that? Can we maybe achieve something that's logarithmic, which was a huge gain over something linear? Just add one to the number. OK, so that's sort of the same as the original algorithm. To add one to the number, because I start with one, then I just say plus one, plus one, plus one. It's sort of the same, because that's in effect what I was doing by just saying one, two, three, four. So if I know something about the size of the classroom, and therefore I can view how many seats are empty as opposed to occupied, that would be a trick too. It might end up taking longer in a class, perhaps like tonight, where we have a bigger lecture hall than we need. But it's certainly an alternative approach, yeah? So divide the class in four groups. Oh, interesting. So in short, maybe ask the audience to help. What a perfect segue. Hey, I hope you'll humor me for just a moment. Let's keep the camera pointed at the board for this. But what I'd like you to do is rise to your feet for just a moment and help me collectively execute this more efficient algorithm. So it's now your turn to be treated as the so-called robots or humans, if you will. The algorithm that you are about to be fed is the following.  So already we're doing quite well. Step two, assign yourself the number one. So think to yourself, I hold the number one. Step three, find someone else that is standing up. And if no one else is standing, you're just going to remain standing. But clearly now there's someone else who's standing up, so make a friend. Once you've found a buddy, you might have to cross the room if you were too slow to befriend the person next to you. Step four, add your number to that person's number. The total is your new number. So let's do a sanity check. What number should everybody have in their room? So everybody, except maybe one person, for reasons I'll leave as an at-home exercise, should have the number two. So now we're at step five.  Clearly erased. The first person to sit down feels less awkward. See someone running to their seat over here. So half of you should now be sitting, and we've affected a sort of loop. Step six, this person still standing should go back to step three.  So go ahead and repeat from step three. Remember, the challenge was to do better than I could. There could not be more reluctance in the room. OK, so you are the last one officially standing. So in theory now, what number should you have at the top of your head? The total, hopefully, since everyone essentially kept handing you their counts. What is our total count tonight? The first time in six years, the count is actually correct. Congratulations. Honestly, this is usually just an embarrassing show of numbers that we have more students than we should fewer, but it actually worked. And that's good, because the program is correct, and it was executed correctly. Now, granted, it felt a little slow, but in theory, should that algorithm have run more efficiently than mine? And mine, again, was this very linear one, two, three. Well, think about it in the context of our phone book problem, on each iteration of your algorithm, of this algorithm. And by iteration, I mean one pass through it. Now, granted, you have multiple steps in each pass or in each loop. But for simplicity, let's just consider those to be just one operation. You can just do them quite quickly. So just as my hand falls down is one operation, so is your doing one loop, one operation. So with that said, in one loop of your algorithm, what happens in real terms in the room? Half of the people, by the end of the iteration, have sat down, which means you're already, in theory, ahead of me, because after one iteration of my algorithm, how many people out of n remain? Well, in my algorithm, n minus one. Once I've plucked one person off and said, one, I still have n minus one steps left to go. But how many steps do you have, maximally? Half of n, because half of you have already sat down, which means half of you are no longer participating. Well, on the second iteration of mine, I count two. How many steps remain for me? n minus two, still a whole lot. It's practically the original size of the problem. What about for you? One fourth of the original number of people. Now, granted, we're taking some liberties tonight by saying, you can execute one loop of this all at once. But take my word for it when I say, when it comes to actually programming, and when it comes to theoretical computer science, that's actually a reasonable assumption to make, that you can do, or that you can treat these several steps as just one operation. And with that assumption, then, in place, in the end, how many steps do you have to perform in order to count yourselves, as compared to me? I have to count n, or I have to perform n operations. How many operations do you need to perform? So let's say there was 21 of you, so we can split that in half, so that gives us like 10 and a half of you. Let's keep it simple. We'll say 10 of you. Then it's a five, then it's a two and a half, which kind of means three of you. That means then one and a half, which is kind of like two of you, and then one of you remains. So it's roughly, ignoring our rounding issues, five steps, as opposed to my 21 steps. And so fundamentally, your design was more clever, was less naive than mine, both correct, but yours would be deemed more efficient. Well, let me task you now with a new challenge, if I may. Now we'll move our focus from efficiency and the rapidity with which you can execute algorithms to the correctness, because the two algorithms I've just fed you in terms of linear search and binary search were both correct. We've now realized that this is also correct for counting students. Well, now let's see if we can't focus on the difficulty that exists in the world of programming or specification of sets of instructions when it comes to their correctness. And we'll worry less about efficiency. The problem I would like to task you with for the next couple of minutes is on a scrap of paper that you don't mind handing over to us, I would like you to write, without looking at your lecture notes, an algorithm, which means step by step by step, maybe six steps, 10 steps, whatever you feel is appropriate, that instructs a new parent how to change a baby's diaper. In short, the task at hand is on a blank piece of paper. I want you step by step from one to however many you need, tell a new parent how to change their baby's diaper. Don't worry about efficiency. Get it right, though. You can assume that the child is, let's say, wearing their clothes, wearing their baby clothes, and it's time to change the diaper. That's the initial starting point. And you can skip such steps as might be inappropriate to discuss in class. We are back. The task at hand, before we faded out on camera there, was to write a correct, though however inefficient, algorithm with which to change a baby's diaper. What I'd like you in the audience to bear in mind as we do the following is think back to your algorithm and see if you, in retrospect, can't find fault from what you recall writing in your own algorithm. So what I've chosen here are two algorithms that were just crafted in class, one from a student who has never changed a baby's diaper before. And I thought we would collectively analyze their correctness. And I've asked Ray to be our spokesperson here. Why don't we go ahead and start with the person who has never changed a baby's diaper, which is this one. And what I'm going to ask Ray to do is step by step tell me what this algorithm was, and we will then determine if it was correct. Want to start with step one? Find baby. Find baby. OK, it's funny you should say that.  But I do have a baby, so some concerns of looks in the crowd. Baby seems to have gotten a highlighter on him or her over the years, but we'll ignore that for the moment. So here we have baby. Baby is found, so thus far our algorithm seems pretty correct. How about here? Is that a little better? OK, so baby found. Step one, correct? Seems pretty good. All right, step two. Remove outer garments and existing diaper. OK, remove outer garments and existing diaper. So I gave you the wrong assumptions. But our little baby here, which is, for lack of a better name, La Baby tonight, we have some clothes, and we have some new diapers. So we'll assume that the clothes were already on and that we've just removed them. And we'll assume that the diaper was on and we've removed that. OK, pretty good so far. Find diaper. OK, find diaper. So presumably find not the old diaper, but new diaper. So let's redress that ambiguity. Here's a new diaper found. Open diaper and place underneath baby by lifting baby's legs. OK, so open diaper and place beneath baby by lifting baby's legs. So I've opened the diaper and again, precision, correctness are now the metrics at hand. And what, can you repeat that step? Place underneath baby by lifting baby's legs. OK, I am doing what I was instructed to do by this student, hold baby's legs in left hand with right hand seal tape at each side of diaper. We always get an email or two after this lecture. I'm sorry? With right hand, seal tape at each side of diaper. So I think we're beginning to experience the imprecision of the algorithm. It would seem correct then to seal the tape. Replace outer garments. All right, so let's move on to the real parent whose algorithm begins as follows. Not bad. We were on a roll at first for someone who hadn't done this before, so in fairness. Step one, place baby on soft flat surface. OK, here's the third email for the evening. Say it again. Place baby on soft flat surface. Well, it said place and I did place, no? There was no place gently. There was no lower to the table. All right, so I'm a little histrionic tonight. Step two, remove baby's clothing. OK, we'll assume that's done. Give baby rattle to occupy himself. I don't have a rattle. OK, you beat us there. OK, next step, take pampers out of box. OK, that we can do. Take pampers out of box. Oh, I would take more than one. Well, OK, but you don't really say pamper. But that's OK. We're trying to poke holes in this tonight, so here we go. Take pampers out of box. Release tapes from side of pampers. OK, we'll take some liberties there. And let's, proficiency, we'll put those aside. All right, released. Clean baby toss out old diaper. Pretend that step happened. And the old diaper, I guess, goes over there. Place pampers on floor. Oh, wait, I'm sorry. Place the pampers on the floor. Put baby on top of diaper so that diaper extends under baby's bottom and below legs. I hear a put baby. How would you like me to interpret put? Why are we doing this on the floor? OK, put baby, all right, say that again. Put baby on top of diaper so that diaper extends under baby's bottom and below legs. All right. I'm sorry, I can't read this word. Fold over portion below legs over the front of baby. OK. Secure the tapes in front. Press to secure. OK, so here too. So secure, say it again, secure tape. Secure the tapes in front. Press to secure. How do I say it? That's pretty ambiguous, right? Like pressing them onto the back. Pressing them onto the baby. Done. OK, so better, but perhaps not perfect. And the point here, of course, was to have a bit of fun with this, but also to emphasize that computers can't make inferences and computers can't exercise judgment. And this is why when programmers make mistakes, the computer does literally what it was told to do. Now, for instance, there are algorithms we haven't tripped over any tonight that have mistakes that aren't so much logical in nature, like these. These were somewhat ambiguous or we made mistakes. It's still unclear to me why the baby went from the table to the floor. But there are also errors of a complete accident, if you will. Ones that induce programs that don't just behave incorrectly, they seem to go on forever. I mean, how many of you have had the experience of doing something on macOS or Windows? And for some reason, your whole machine, all of a sudden, gets incredibly slow or it starts to get unresponsive. And it hasn't crashed. It hasn't frozen, because the processor is clearly doing something. Maybe the little lights are blinking. But if you try to move Windows, it's just incredibly slow, as though the computer is really, really doing something, but never stopping. That was a very long question. But the question began with how many of you experienced the following. So we probably all have. What that's often the result of is what's called an infinite loop, whereby a program has a mistake. And those mistakes in the world of IT are usually called bugs, denoting just a mistake in a program. And certain bugs can induce infinite loops. If, for instance, you tell the computer to do something again and again and again, but you don't tell the computer when to stop. And this is usually because some programmer has made an obscure or a silly mistake in their program. This is an algorithm that was excerpted long ago from a Better Homes magazine of Sword, where they, for whatever reason, enumerated the steps in a baby-changing algorithm. And we put them up here because often we'll simply debug the program at hand. And I think now, after our little exercise there, you can certainly come up with some errors of precision or some ambiguities in this program that would probably not bode well for the child.  But again, computers don't have that. Computers are machines. And though they might seem smarter than us, though they might be faster than us, they are fundamentally only capable of doing what we ourselves have told them how to do. And as such, complicated as computers might have seemed to you before lecture one, or maybe even as complicated as they, to some extent, still seem to you now, they are so much less complicated fundamentally I would wager than, say, a human being or, certainly, any living creature of our scale, which is of much greater complexity and of much greater fundamental ability. Now with that said, let's try to formalize some of the constructs that we've been playing around with tonight. Because thus far, we've pretty much been saying a program is a set of instructions. A set of instructions is just a series of steps. One, two, three, four, five, six. Maybe you have a loop in there by means of a line that says, go back to step three. But let's see if we can't now move a little bit away from the English, the pseudo code, if you will, approach of programming, which we've been doing thus far tonight, putting up programs that are kind of like programs, but they're clearly written in English, aka pseudo code, which is like an English-like programming language, something that's a bit more formal. And then we'll segue after break to an actual programming language JavaScript and show you how you might actually make use of it in your own web pages and your own programs. Well, here is a more formalized algorithm. I've numbered the lines again for the sake of discussion, but I've also indented things this time so that it's clear what parts of the program belong to what constructs. And I'll say what a construct is in a moment. Moreover, I've tried to use certain key words that even though this program for sock donning is written in English, or pseudo code, if you will, it is nonetheless reminiscent of the computer programs we'll see in just a little bit. So sock donning algorithm is clearly about writing. Sock donning algorithm is clearly about putting on socks. We have, in semester's past, asked for a volunteer from the teaching staff. We could do this tonight, but perhaps we're demoed out. I'll put it to a vote. Would we like to execute this or simply discuss this tonight? Oh, I heard execute. Ray has already partaken in the activity, which means I need either Roman or Dan, if they would. Roman has bravely volunteered. Oh, you're the note taker. So Roman has bravely volunteered Dan, if Dan does not mind. I think we'll have to put him here, if that's all right. Yet more reluctance in the room tonight. So here we go. So here is a more formalized algorithm. It's for sock donning. So let socks on feet equals zero. So what is this saying? Well, this again is representative of the syntax we'll see later tonight. So we're going to describe, as Dan prepares, if you wouldn't mind, initializing for this algorithm, to put some jargon at these constructs. So line one, first step in the program, says let socks on feet. Well, socks on feet, which notice is just one word, because we're using underscores to represent, say, space characters, is what we would generally call a variable. A variable very similar in sense to what is used in, say, algebra, x, y, and z. Those were all variables from middle school and high school when you tinkered with algebra. So computers similarly support variables, which are like placeholders for actual values. So we've just executed the first line of this program. We have initialized our variable, socks on feet, to zero. Because now, clearly, Dan has no socks on feet. So the variable is zero. So step two, while socks on feet, and this is a bit of syntax I've borrowed from JavaScript 2, what do you think it means to say exclamation point equals? Yeah? Does not equal the following. So when you see in a programming language the exclamation point, like in line two, equals, that doesn't mean it equals, but rather it doesn't equal. The bang, as it's called, or the exclamation point means not. So the second line says, while socks on feet is not equal to two, do the following. Now, how do I know what to do with the following? Well, this is where indentation is often important. Notice that every line from three to 17 is indented beneath line two. What that means is, when I say in line two, while socks on feet does not equal to, what it means is do everything below that's indented by one tab character. So what does this keyword while suggest to you this thing is between lines three and 17? It's not an if, as long as, yeah, let's throw a word at that. It's a loop. So you used this word earlier tonight to describe a repetitive process, and here is, in more formal terms, a loop being induced by a keyword while. And we'll see that keyword in JavaScript as well. Well, step three, open sock drawer. So we'll ask Dan to role play if he could here. He's opened the sock drawer. That's a pretty simple statement. In programming speak, we might say that Dan just called a function or a method. A function or a method is just like a mini program that achieves some predefined result. So when I say open sock drawer, it's written in English, but in a sense, that's like Dan has just called an operation that's predefined, because we all know what it means, and we'll assume someone else has implemented that. So we executed this function called open sock drawer. Step five commands him to look for sock. I'm sorry, step four, look for sock. Now we get to step five, which is an example of another construct. It's not a loop, but we can see a new keyword named if. If you find a sock then, and notice the indentation, what follows the word then is everything that's beneath it that's further indented. But let's slap a name on this construct as well. We've seen a looping construct in line two induced. In line five, we have an if. What terms might you have heard in the past that would describe this if construct? A condition, a statement would be something like line three or four, which are just right to the point. But we could call line five an instance of a condition or we could call it a branch two. Two roads diverged in a wood. And I took the one less traveled by. That's a fork in the road, a branch in the road. It's a condition. Either go this way or go that way. So we have a branching construct or a condition. Dan has, yes, found a sock or no, not found a sock? Yes, so we proceed to step six, which says put on sock. And a little ambiguous, because we're not worried so much about correctness or efficiency this time, but rather the constructs involved. We seem to have succeeded, so we're now in line seven. What do you think line seven means? Socks on feet plus plus. Yeah, this is programming shorthand for saying increment a variable. So when you see plus plus after some variable name, that means take that variable's value and increment it by one, add one to it. So what is the value of that variable at the end of line seven? One, because it was initialized to zero, we incremented it with plus plus. So now Dan, clearly consistent with reality, has one sock on his feet. We're now up to now line eight. Look for matching sock. So Dan executes this statement or function, and he finds it. In line nine, we see if you find a matching sock, then, so what's this another example of? It's another condition, it's another branch. So is this a matching sock? Hopefully, since he took them off earlier tonight. So yes, he has found a matching sock, and line 10 put on matching sock. Line 11, sock's on feet plus plus, so the value of that variable is now two. Finally, step 12, close sock drawer. He closes the sock drawer. Now, what is the next line to execute? After line 12, close sock drawer. Yeah. OK, so I have one proposal that the next line is this one, because we do, in fact, skip this else, because this condition was true. And notice the importance of indentation. When I said earlier a condition is like a branch or a fork, well, we took the left-hand fork, if you will. When Dan found a matching sock, then he did this. Had he not found a matching sock, the indentation suggests that he else would have done that. And by that, I mean these two lines, because this else belongs to this if. And that's how you tease apart what the two directions are that you might go in. So as you know, we are not going to execute rather 14 or 15 or 17. We don't execute 17, because 17 is only executed when? If you don't find a sock, because notice this else in 16 lines up with the if in line 5, but we took the left-hand branch, if you will. We did this, which means we don't do this. And so after Dan, coming back to the question at hand, executes closed sock drawer, what happens next? So it seems like that's it, but we kind of, to be fully correct, need to check one thing, because what was induced in line 2? So line 2 was our so-called a loop. Now we are finished, but we don't know we're finished until we check this condition again. So what really happens if we were to feed this or something like it to a real computer, we would go from line 12, closed sock drawer, back to line 2, and then in line 2 we would again say, while socks on feet does not equal 2, but wait a minute, what is the value of socks on feet now? It's equal to 2, which means now the program ends, because lines 3 and through 17 no longer are appropriate, because line 2 implicitly said, don't do this once socks on feet equals 2. Yeah, good question. Don't you need some kind of instruction, like we saw in the student counting algorithm that explicitly said go back to step 3, or in this case, go back to line 2, or more specifically, go check socks on feet again. In conceptually, yes, but as you'll see in JavaScript, what happens by nature with most programming languages is that loops will always loop back to the beginning. You'll check the looping condition again, which is the socks on feet not equaling 2, and then the program will decide to continue the iterations or to stop. Is that because of the second check? Yes. Yes, implicitly, you can think of this situation as there being a line 18 that says go back to line 2 and check, but as we'll see again in JavaScript and in most programming languages, that notion of going back and checking the looping condition is implicit. And so notice, I think someone did, in fact, call line 2 a condition before. And it is. That is fair to say it's a condition, but it's a looping condition. Do the following so long as this is true. This is a condition as well, as was this, but they're branching conditions, if you will. Yeah? So what is left? Well, in this case, once the loop has finished executing once, you don't go back to the true beginning. You go back to the beginning of the loop, which would be line 2. So the line 1, which only executes 1, so the very start of the program, you can literally think about it in the English terms. Let this thing equal 0. It's an initialization. It's an assignment of a value to a variable. It's like saying, but not explicitly, if I were writing some algebra statement for a homework, if I say, I have just let x equal 3, that's all. I've allowed x to equal 3. Now, before we can put Dan out of his misery, we should probably just bug check this thing, just proofread it, and see if there are conditions in which Dan might end up executing something infinitely. Are there situations in which Dan, or someone else, running this algorithm to put their socks in the morning, might get stuck in an infinite loop? Let's go back here first, but that's good. OK. OK. OK. Which means the second sentence and second sentence is 2, the second condition is 2, because he had three socks on which is not equal to 2. So he's going to execute all the lower steps. Correct. So if, by some flaw of reality, the person had three socks on already, or if the program were hard-coded to say in line 1, not equal 0, but rather equal 3, we would immediately have a flaw, a bug in the program. Because as you note, clearly 3 does not equal 2. So in line 2, we would begin executing the loop. Dan would try putting yet more socks on if he finds matching socks. The condition would then be checked again in line 2. His number of socks on his feet would still not equal 2, because now he had 5 on his feet, and that would induce an infinite loop. So sure, a bit of a stretch of reality. But if Dan did, in fact, have three socks on his feet, or any number other than, or if that number were initialized to anything other than 0 or 1, we would have a problem. Or 0, we would have a problem. What else? How about with the algorithm as written? Are there situations in which this algorithm might be flawed? If he didn't own any matching socks? Well, let's consider what might happen. If in reality, we start again, just conceptually, with Dan having zero socks on his feet, he's got a drawer of socks to his right. Well, we then proceed, as we did before, from lines 1 down through 5. Well, he finds a sock, let's say, because he does have a drawer of socks, but suppose it's one of every color. Well, he puts on the black sock. Well, then we proceed to step 7 and then 8 in line, rather. Step 9, what we find is that we don't find a matching sock, because all the other socks in the drawer are blue, green, gray, red, anything other than black. So what line executes if Dan does not find a matching sock? So we go down to 14. 14 says, else, execute this. So what does Dan do? Takes off that first black sock and decrements, minus, minus, means subtract one from the value. So socks on feet after this line now equals zero. Do we execute these two lines? Those weren't relevant, because you only do those if you don't even find any socks. So we go from this line back to line 2. The condition in line 2 says, while socks on feet not equal to 2, well, that's true. He's got zero socks still on his feet. So we re-execute. Well, maybe this time he pulls out the red sock, but he's not going to find a matching red sock. Maybe the next time he pulls out the green sock, doesn't find a matching green sock. The next time he pulls out the gray sock, doesn't find an infinite loop, because there are situations in which, even if they're unlikely, they are absolutely possible, and this may have happened to you. It certainly happens to me near the end of the laundry cycle, where I might have a few loose socks, but none of them should I wear out together. That would be an example of a programming bug that leads to an infinite loop. I think, especially since I didn't think to ask him beforehand, Dan deserves a big round of applause, if we could. And with that said, let's take a five minute break, and we're back. So we have a few exciting things coming up on the agenda, not the least of which I'm sure is exam 2, which is in lieu of the first hour of lecture next week. I know, but it will be followed by a great lecture by a fellow named Omri Trab, who founded a company a few years ago called Transformus, LLC. This was one of the companies, one of the few companies, you might say, that did quite well during the so-called dot com era. What Omri will be chatting with us about is his experience running and starting that startup. And what you'll find is that his story will be the upside of that era, with the downside of which we will look at in lecture 13, when we return from winter break and have our second of two movie nights in E1, whereby in addition to popcorn and soda again, you will be treated to a great documentary called startup.com. And as I said in the first lecture, and I know documentary never sounds exciting, but this was a movie that came out a few years ago on DVD and in the theaters that was literally made by a couple of guys, bold guys, brash guys if you will, who decided that it would be a good idea to document on camcorders their experience starting this company from the so-called dorm room or hotel room all the way up to their big breakout. Unfortunately, the cameras did follow their experience running a company called govworks.com as it did better and better and better, and then it also, they kept the cameras rolling as it eventually disappeared, like many of the companies in the dot com era. But it's a wonderful film if only because you truly see the emotions and the egos and the experiences boasted by a whole bunch of young tech people a few years ago, and it will be, again, the counterbalance to Omri's story of triumph and goodness. And it will have popcorn and soda. With that said, we have coming up this weekend, workshop, which involves extra help with XHTML. If you'd like to have some more controlled lab time with the teaching fellows working on XHTML, whether for the homework assignment or for your own edification, coming up in this week's slate of sections for local students, we have more on website development, specifically the use of CSS, cascading style sheets, and server side includes in your web pages. So this will be the next follow up to XHTML where you begin to take your skills one step further and actually make them a little prettier, a little more dynamic, a little more stylized. And of course tonight, a vote will be taken for Fall 2005's mouse pad design. So clearly we're using lecture material verbally too.  Each of these candidates has been labeled A, B, C, and so on. And you, the lucky attendees, and those students who have emailed us prior to this class, will now proceed to vote for this year's design. As I said in lecture one or in a recent lecture, what you will have in your hands at the final lecture is a souvenir of sorts from E1, the winning mouse pad design from tonight's vote. We will put onto actual half inch mouse pads to keep on your desk after this course is finished. So with that said, let's peruse the designs. If you haven't glanced at them already and we'll proceed to the vote. So this is candidate design A. Give you a moment to look this over. So again, the theme was, of course, I survived computer science E1 moving back. This is design B. This is design C. Needless to say, when you see one you really like, make a mental note of what letter it was. And I survived CSCI E1. This is example D. This is candidate E. This is candidate F. Now when I looked at this design for the first time, I was thinking, oh god, now the tables have been turned. We now have to translate this. And it turns out that the binary does, in fact, translate to I survived CSCI E1. So quite clever indeed. A little play on the matrix. Design G, design H, design I, and finally design J. So again, in a moment you will vote on the design that will be immortalized on our website and on the computer desks of everyone enrolled in the class this semester. If is there any design you would like to see again, do you want me to flip through them quickly, or do you have in mind who you'd like to vote for? Well, with that silence, why don't we go ahead and do this? We're going to do it the old fashioned way. We'll do two or more rounds of voting just so that we whittle it down into the vote of highest confidence. Ray is going to vote in proxy for those students who emailed us before tonight by raising as many hands as is necessary. What we will then do is in turn go through verbally consideration. And I'll say who would like to vote for A. And then we'll just do a quick raise of the hands. The TFs and I will count. We'll then do that for the other letters. We'll then put to a vote maybe the top two or top three that come out of that.  So even there's some awkward faces there. So what we'll simply do is for the final vote do it on a secret ballot so that in fairness you're not making or breaking that winning design at the very end publicly. So with that said, and if Ray and the TFs could help me count, let's go ahead and put some numbers to the designs. And of course, to any of the designs that do not win tonight you're all H-I. Everybody's a winner simply for having submitted.  So this is just icing on the cake. So any hands who vote just once in the following iteration of votes. So anyone who would like to vote for A, and don't look around at who else is voting, just look straight ahead.  Hi. You can put your hands down. We'll proceed to B, which is this. Any hands up for this design? Looking around. We're going to go to C. Looking around. Teaching fellows, I count three. Moving on to D. Teaching fellows. Looking around, I see four. A retraction. Yes, four. OK, I see four. OK, four. And we have next candidate E. Again, vote just once, because we do know that there are 21 votes tonight. Oh, that's true. That's true. All right. Any for E, E. OK. Moving on to F. Any votes for F? I count seven. Maybe hands still up, just so we can confirm? Confirming? Seven. OK. Candidate G, I count three, four. Yeah? OK. Candidate H. OK, any? OK. Candidate I. OK, I see one. One by proxy, so total of two. And candidate J. Candidate J. All right, zero. So it looks like our top votes were for F, for G, and for D. So let's go ahead and have one final vote you should have received during break, a blank piece of paper, a blank scrap of paper, in which I'd like you to do, and I'll quickly flip through these three final candidates, is just write the letter in clear, bold text on the slip of paper, your vote. And then go ahead, and if you would pass it to the IELTS, the teaching fellows, if they wouldn't mind, will retrieve them, and then at the very end of lecture, we'll have counted them up and provided you with a mind-blowing announcement. So that you know what you could vote for, we have just three candidates left. D, which was this. This again is D. F, which is this. Again, this is F. And finally, G, which is this. On your piece of paper, put down one letter, D, F, or G, for each of those three designs. Stay tuned as we tally the votes. All right. Is this a program? Well, what is a program? It's a sequence of instructions that tells a computer how to do something. In our previous example, though, we introduced some formal constructs. Those constructs to review were what? Oh, sorry? Constructions. Well, constructs. So we saw a couple of the key words. Ifs, which were branches or conditions. We saw while, which was an example of a loop. We talked about these things called functions, which were like mini programs, statements that get executed. We looked at ELTS, which was the other branch, for instance, or the other fork in the road for something like a branch. Conditions, which just must be true if the program is going to go this way or that way, or if the loop is going to repeat. So even based on your limited knowledge of XHTML, have you seen these constructs, looping constructs, or conditions in XHTML? Not really. Most people would say that XHTML or HTML are not programming languages. After all, what does XHTML stand for? Hypertext markup language. And that's more closer in spirit to what they really are. You are marking up content. You are marking up words and texts like Hello World, but you're not really programming in the most agreed upon sense because you don't really have full control over the computer. You can only do, for instance, what a web browser allows you to do within the confines of it. It's a much more limited language than something like the following that we'll next see. This is a language, too, but it is a programming language. So whereas XHTML is a markup language, this is an example of a programming language. This is the programming language known as C. So if you've ever heard of a few programming languages, this is that known as, quite simply, C. Well, what does it have? Well, this is an example of a function in C. It's the main function, which means it's the essence, the body of the program, just like the body tag or body element in XHTML is like the essence of a web page. Well, take a guess. What do you think this program, if I run it, is going to do? It's just going to print Hello World and then exit. It's just going to exit. Now, granted, there's some more syntax here. There's semicolons. There's the number zero. There's this thing, argv, and argc, char, and int, all of which are keywords and syntax specific to the C programming language, but even to you, the non-programmer, the non-C programmer, you can kind of infer what this very simple program does. Well, on FAS, in tonight's examples, we do have this same file. It happens to be called hello.c. This is the very same file, the very same program.  So what you just saw above is what's known as source code. This is what a human being. This is what a programmer, a software developer, would write. However, computers do not understand syntax. However English-like it is like this. Rather, computers only understand what language. Binary, zeros and ones. And so what you need to do with a programming language like C is to, quote, unquote, compile it into languages that computers do understand. And computers understand the language of zeros and ones. And so what this arrow here implies is that, yes, a programmer would write code like this. But then that programmer has to run a special program called a compiler on his or her source code. And what that compiler does is, given source code as input, it produces what's called object code. As output, object code. And object code is nothing more than zeros and ones. So you have, quite simply, this situation. Source code written in something like C, you run this through a program called a compiler. And what you get out, again, is called object code. And object code is just zeros and ones. And it's those zeros and ones that a computer's CPU is hard-coded to understand. So recall in lecture one and two, we talked about computers understanding certain instructions, like add, and subtract, and multiply. Well, what does it mean to understand those instructions? Well, in essence, each of these zeros and ones, all of these zeros and ones, have been broken up into groups of how many bits? Just looking at a single row. Eight. It's no accident that it's eight bits because they're typically broken up into bytes. Maybe one byte, two byte, three bytes, four bytes max. But they're viewed as sequences of bits known as bytes. So a computer, a computer's CPU, like the Pentium 4 or the PowerPC CPU, is designed at the factory to know that, for instance, speaking hypothetically, the sequence of bits 1-0-0-0-0-1-1 means to add. What should it add? Well, this CPU might be predefined to add the numbers that follow it. That, in essence, is how you tell a computer to do something. You give it a sequence of bits that represent the instruction, add, subtract, multiply. And you provide that instruction with arguments. That is pieces of data. Think back to lecture one when we talked about a calculator. Well, when you hit a button, what you essentially were doing was telling the calculator to perform the add function. But the add function was hard-coded to look in two pieces of memory, which were called registers. Similarly, as a computer, CPU, which is nothing more than a smarter, faster, more expensive calculator, designed to know that if it sees a certain pattern of bits signifying add, it should then add the next sequence of bits together that follow it, for instance. Now, there's a lot of classes that can be taken at a university between this step and this step. This red arrow is kind of assuming a lot. But in essence, that's what's happening. It's compilers converting the human readable source code into the true language that a computer understands. Who writes the compiler? Well, usually a relatively few number of people in the world, companies, software products, exist as compilers that most programmers use. You might have heard the word visual studio, or visual C plus plus, or GCC, or G plus plus. These are just the names of popular compilers written by UNIX folks and people in the windows world as well. So if you are a software developer, if you are a programmer, at some point in your life, you or your company will have bought one or more compilers so that whatever language you're programming in, you can then convert that in effect to the language that the actual computer understands. Consider the alternative. If you did not have compilers, how would you program computers? Binary, zeros and ones. Think back, even if you've never seen them, to the idea of punch cards, which were one of the earliest forms of mechanisms for providing input to a computer. You literally had these hard pieces of paper that you would punch holes in, effectively representing zeros and ones. You would then feed those cards into a computer, which was the size of a room. And that card effectively contained the codes that represented instructions and data. It's not a huge leap from simply typing into a keyboard, zeros and ones entirely. It's not a very fun, a very easy, a very efficient way of programming. And so over the years, humans have come up with what are called higher level languages like C and Java, if you've heard of it, C-sharp, C++, which are a little more human comprehensible. They allow you to do much more by writing commands that are much more like English than they are like binary. Now by contrast, XHTML is what's known as an interpreted language. It's not a programming language, but it is a language. It's a markup language, but it's interpreted. By that, I mean at no point during your tinkerings with XHTML over the past few days have you compiled your XHTML. It suffices to save your text file, .html, and then pull it up in a web browser. But what is that web browser doing? Well, it retrieves via HTTP, your HTML file, but then it proceeds to read it line by line. And when it sees a font tag, effectively, the browser says, oh, hey, this means the following text, the following content, should be blue, or should be size seven, or should be some other font face. And then as soon as it sees slash font in another tag, it says, oh, now I stop. In short, a browser just interprets the markup language that it is fed. It doesn't convert it to zeros and ones per se. Rather, it just interprets each of the tags that it's provided with and then acts accordingly, behaves according to the predefined behavior for all of those tags. That's why, after all, you can't just invent your own XHTML tags or attributes. If the browser doesn't know about them, how can it interpret them? It can't figure it out. It can't assume. It can't make human judgments like we did earlier with the law baby. It has to know in advance how to interpret certain statements, certain tags. Well, here's another example of a compiled language. What do you think this program does when run? It's ever so slightly different from the previous example in syntax. But what does it do, do you think? It also says hello world. Let's take a look. So I pulled up this FAS window before, and I said that this is hello.c, the first example. I mentioned earlier a compiler called GCC. You won't have to do this in class. This is something more reserved for an actual programming class, but if you wanted to compile the source code called hello.c, you would run a program like Visual C++, Visual Studio on a Windows computer, or on a Linux computer, a program called GCC. What that, by default, creates is a program called a.out, silly name, but it's the default name for the program that results. It's like an exe that we now have. And if I run that at the command by simply writing its name and hitting enter, hello world. It's a little confusing because my prompt immediately came after, but it did behave as you predicted. It prints hello world. G++ is another compiler. If I compile this example, which is just slightly different but still contains this phrase hello world, and then run it, same exact example, but a slightly improved. Because this new example actually includes the end of a line, if you will, because I use this little trick. Again, not something that we'll use in this class, because it's better taught in a class on programming, or in books on programming, but in spirit that's all programming is, writing sets of instructions, two instructions in this case, running it through a compiler, if it's a compiled language like C or C++, and then running the program. So among the other languages in this world that are popular today, you have C, C++, Java is another. What are other programming languages you've heard of? Perl is another language. Perl is an interpreted language. And we'll just make a quick list here. This is compiled. This is compiled. This is compiled. This is interpreted. C-sharp is another. GCC is the compiler. It's not a language. Sorry? Dotnet is actually more of a marketing term than anything specific, frankly. As part of dotnet, there are other programming languages, but C-sharp is perhaps one of the most popular ones used with the dotnet framework. CLR is another one, but it's a different type of language. But it's relevant, certainly, to this discussion. PHP, a number of websites use PHP. It's an interpreted language. And what do I mean by interpreted here? Well, we said XHTML was an interpreted programming language, which means that a browser reads it line by line and then behaves accordingly. Well, these other languages, too, like Perl and PHP, which are interpreted, Python is another one, are interpreted in the sense that you don't view them with a browser outright, but you use an interpreter, a program that executes your source code line by line. It's a subtle distinction that's better explored in more depth than other courses. But in short, interpreted languages are not manually compiled by you, the human, with a compiler, which makes them typically platform independent. When you compile, programs written in C or C++, and most programs running on your PC today were written in C++, so that's gradually shifting toward things like C-sharp, but C++ is perhaps still one of the most popularly used languages to write Windows software. Well, that object code that a compiler spits out to be clear is specific to a certain CPU.  If you take that same Windows-specific shrink-thwrap software and try to run it on your Mac, it won't work because what CPU is inside of a Mac? The power PC line of processors, the G3, the G4, and so forth. Well, bear in mind that when we output these zeros and ones, as we discussed slightly in our hardware lectures, these zeros and ones are specific to the CPU they're gonna be run on, which means that these compiled languages, though they produce very fast programs in theory, those programs can only be run on a certain CPU, which is why you can't borrow a Mac user software and run it on your PC, or vice versa. Suffice it to say for tonight, that interpreted languages are more flexible. You can run programs written in them on Macs, PCs, Linux, UNIX computers alike, but you often pay a penalty in that they are slower performing because you have to interpret them line by line. Think of it in the real world. If you spoke a language like Spanish with a native Spanish speaker, that can be a very rapid conversation, very efficient. But if you don't speak Spanish and you wanna speak with a native Spanish speaker, what do you need in between you? An interpreter, just intuitively in the real world, that's a slower process. It's almost twice as slow because you have to wait for the person to hear you and then they need to translate it to Spanish. Similar in spirit in the world of programming. Interpreted languages tend to be slower because of this step of interpretation. Question? Okay. Yes. There do exist products that allow you to on a PC run Mac software and possibly on a Mac to run PC software. Those programs, one of which is called Virtual PC, another of which is called VMware and there exist other products as well. These are example of what are called virtual machines or emulators really. It is software that's designed to pretend like it is the Power PC CPU or conversely the Pentium processor. So yes, you can sometimes buy software that allows you on a Mac to run Windows software and vice versa. Typically though, it's not I would say a fun experience because converting one platform to another, essentially emulating one as the other, is a slow process because they're essentially like interpreters for one CPU on another. But they do exist. But frankly, computer hardware is so cheap these days that I would go so far as to say you are better off not spending $50 or $100 on the software but rather $200, $300 on just a separate computer so that you have a Mac and a PC maybe with one monitor keyboard with a switch toggling between them, simply for performance reasons. I'm sorry. Because of the speed. I mean, I use these products in my research just because it's easier than getting 10 computers together in the same room. We can simply run multiple. What these programs essentially allow you to do if you double click their icon, if you install the virtual PC on a PC and then double click its icon, what you get in a window is the recreation of an actual computer. You'll see a fake BIOS. You will see Windows booting up in this window or you'll see Mac OS booting up in this window. You'll then see a Mac OS or Windows desktop in this window. So it's useful in research, say, in another context so that you can, in effect, run multiple computers on one computer but it tends to be slower. It's not an ideal solution to the idea of running software on multiple machines, on multiple platforms. Java is another popular language. It, too, is compiled. Here is an example of a Java program that achieves yet again the same Hello World result. This, too, is ultimately outputted as zeros and ones but just so that you know, have the jar again at your disposal, a Java compiler outputs something slightly different known as byte codes. And suffice it to say for tonight that Java is in spirit cross-platform as well in that programs written in Java can be run on Macs and PCs alike because byte codes are not specific to the processor that you'll run the program on.  That virtual machine is running again on something like a PowerPC computer or an Intel-based computer, Pentium, and so forth. So what that suggests is that to run Java programs, you need this special intermediary. You can't just double-click a Java program and have it run in reality. You need to first run a Java virtual machine, as it's called, which is just a piece of software that allows you to interpret in effect these byte codes. But more on that to an offline discussion if you're curious. That would come up in a programming class. Yeah. Other languages can be compiled down to this intermediate step. The whole .NET framework actually allows you to compile C-sharp code, for instance, down into programming language called CLR, Common Language Runtime, I believe, which is similar in spirit. I don't think they use the same jargon, most likely because it's out of Microsoft, but there are certainly other languages that achieve this same goal. Simply Java is one of the more popular ones these days. So with that said, because I can see some of the information going this way and some of the eyes glazing over, let's make things more real and a little more fun. Here finally is JavaScript. JavaScript is the language that we choose to teach in this course to a limited extent. You probably should not put on your CVs after E1 that you are JavaScript programmers since you will just get a taste of this language, but enough of a taste that you can do some neat things with it even for your final project or in your own websites. With that said, here's an example of a webpage that is written not only in XHTML, but has some JavaScript nested inside of it. So JavaScript is a programming language, though it sounds like Java, it is not at all related to Java. It is an interpreted language and it tends to be used almost always inside of webpages. It is sort of the programming language of choice for client-side programming in webpages. Well, what do I mean by that? Well, think back to last week's discussion of server-side includes. Server-side includes SSIs allows you to have sort of dynamic behavior in your website. We could dynamically output someone's IP address or their browser type or the current date and time, and that was a useful trick seeing the last modification time of a file. But where were those tokens being executed? Think about what SSI means on the server. So if you were to view those webpages from last week that had the SSI tokens in them, view them with your webpage and you went to IAE's view source option, you would get a notepad window with your source code, but would you see the SSI tokens? No, and you can try this just to convince yourselves of this. If you open the files in Pico, you do see the SSI tokens, but insofar as SSI tokens are server-side included. What that means is the web server before transmitting by HTTP, your HTML or XHTML, it first executes those tokens and replaces those tokens with, for instance, the user's IP address or browser type or the current date and time, and so what your browser receives is only XHTML. By contrast, JavaScript essentially allows you to write programs that don't get executed server-side but get transmitted in the XHTML to the user's PC or Mac and then they get executed client-side. Your own computer executes JavaScript, which means if you view source on a page that has JavaScript, you will see that JavaScript. Those of you who visited around Halloween, the course's website, and had we had those flying bats, that was achieved by something called DHTML, Dynamic HTML, which we said I think last week is nothing more than the simultaneous use of XHTML and CSS and, take a guess, JavaScript. And that kind of makes intuitive sense. You essentially, if you saw them, we had these bats fluttering around the webpage. They were kind of looping back and forth, fluttering. Well, they were just images and they were looping back and forth because there was a JavaScript program embedded in the course's website that one day that essentially, like we saw today, had some looping constructs that said fly over here, then over here, then over here, then over here. You can only achieve that not just with XHTML, but with a language like JavaScript that lets you specify the sets of instructions that achieve that aesthetic. So here's an example of a webpage. It's a little small to see up here, but you do have it in your lecture notes and you can download it off the course's website. Any most JavaScript programs appear in a webpage by being flanked in this new, as of tonight, script tag. If you want to include some JavaScript in your webpage, usually you would write script, language equals JavaScript, type equals text slash JavaScript. You would then write your lines of code. The comment signs here simply exist in well-written JavaScript, I would say, just in case someone with an old browser visits your page and their browser doesn't understand JavaScript, this XHTML comment, if you haven't come across it before, is essentially a way of ensuring that even old browsers don't choke on JavaScript, even if they don't understand it, because a comment is by definition ignored by a browser, at least if it's XHTML. If you didn't quite follow that, that's okay, we'll focus tonight on these two lines here. So let's see what these two lines are doing. Var name equals something. Well, what do you think var means? Variable, but JavaScript requires, and this is something you simply have to know or remember or look up. When you wanna use a variable in JavaScript, you must say var and then the variable's name. Equals, just like in algebra as assignment, X equals three, well rather, name equals this. Well, what is this? Well, prompt is a statement of sorts, but it's more precisely a function. It's like a mini program that is built into JavaScript that as you might guess, prompts the user with a window. What is inside of that window? Well, specifically, the following sentence. Please enter your name. A function can therefore take some input and I'll run this in a moment so you see what I mean. A function can take input and it can also produce output. How do you get its output? You simply use an equal sign before it and say whatever this function returns, as they say, whatever it spits out, store it in this variable and we'll see what that means in a moment. This is another function call here, write. If you write document.write and then something in quotes like that, you will write to the webpage whatever that parenthetical content is. Now it's a little cryptic because you've never seen this syntax before probably but we seem to be outputting a title tag followed by welcome comma plus, looks a little strange here but think of this as concatenation. It means output this plus this. So what do you think we're gonna be outputting in the end? What is the title tag going to contain? Welcome comma David, exclamation point or whatever the name is that happens to be provided at that prompt. Later in the webpage in the body, notice again we have some JavaScript. This time it's in an H1 tag which was that big header heading tag that we looked at briefly last week. Then we have welcome comma and then this JavaScript. This time we're not using prompt, we're not declaring a new variable, what are we doing at this point in the body? We're simply writing to the document, what? Just the name. I promise this is about to make more sense when you see it in action. If I go to these examples which are in interpreted and pull up this was name.html, this is just a webpage that I'm now pulling up from our account, notice what happens. In the top of the screen, I'll move it to the middle is a prompt. You've probably seen these prompts before on other webpages, usually there are nuisance because it's some kind of pop up telling you to vote for our site or something like that. Well in this case, it's actually asking you a question, please enter your name. David, now I'm gonna click okay and notice the webpage dynamically says welcome David. Notice the title of the page, what's the title say? So www.people.fas.harvard.edu, what's the title after that? Welcome comma David. Well wait a minute, this webpage did not on the server have my name, let's view source. It's a little small I know but do you see my name anywhere in the source? No. It's entirely dynamic. My computer, the PC, ran this JavaScript program locally on this client. Use the prompt function to ask me a question stored in that variable, whatever I typed in and then displayed it into locations. We can run it again. If I refresh, this time I'll say gray DS, okay. Now we get a webpage with Ray's name in it. Again, dynamism executed its client side. Dynamic HTML is just a buzzword that describes the simultaneous use again of JavaScript, XHTML and CSS. It is really little more than a marketing term than anything technical. All right, so let's just look a little closer at this example and see what more we can do with it. If I go into this file that we've been playing with, notice that after this prompt function, there's a comma blinking there. In quotes to the left of that comma were the question I was prompting the user with. But after that comma, notice in purple here tonight, there are two more quotes with nothing in them. Well, that would allow you, because I know JavaScript or I've read the manual and I know how the prompt function is defined to work, I could put something like John Doe in quotes there. I'm gonna save my file, reload this page and notice the difference. Clearly, the prompt function is designed to take as they say two arguments. Arguments get separated by commas and by definition, arguments control the behavior of a function. Clearly, if we've read about the prompt function in a book or in some online tutorial, it's designed to take two arguments, the first of which controls the behavior of the prompt itself and the question it shows, the second argument is clearly what? How does it affect the behavior of the prompt? It gives a default value in the box. Notice it says, please enter your name. Well, we can be a little more rude if we wanted. We could say, hey, your name, let's now save, refresh and now notice we've again changed the behavior of the prompt function just by changing the argument we passed to it. Again, how do you know what arguments you can pass and what functions you can call? Well, this is why you take a course in programming or this is why you read a book or some online reference or teach yourself by examples like these. Well, what else can you do with JavaScript? You can do things that are a little prettier than just changing the text dynamically. Here's an example of another webpage. It uses another XHTML element which some of these details I'll gloss over quickly because it's no fun to learn this stuff by hearing someone talk about it. I think you'll find it more fun to play in section or workshop or at home with this stuff. But notice there's a new element tonight called form that should conjure up visions of Google and any web pages that have forms that you fill out. Well, we're using the form here in sort of a cheating type way because I just want to have a bunch of buttons on my page. And this is an example of using JavaScript in the value of attributes. Usually you would write big programs in between those script tags, the open script and the closed script tag. But if you want to just achieve some one liner, some neat little effect using JavaScript, you can sometimes like here just put it in double quotes and say JavaScript colon and then the line of code you want to execute. Let's infer from example what this is doing. This is saying create, hey browser create in form here. Hey browser create an input type here of type button. In other words, put a button here in the page. On click. Well that means when the user clicks this button, do what? Well, take a guess. Change the background color to red with similar behavior for other features, the value of the button that is what's printed on it is gonna be R, G or B. Well, let's take a look at this page. It's called colors.html. It's available online for you to play with. It's a very ugly or simple web page, but look what it's got. Three buttons whose labels or values are R, G and B. If I click on R, on clicking this, what's gonna happen? G, B. Again, if I view source, it's the exact same code you saw above. You might wonder, well, great, this is nice and pretty, but why would I care to have the user change the background color? But it's just meant to be a simple example, the hints at the sorts of things you can do with JavaScript and the syntax with which you can do it. Here's a looping construct. If I view this page, my browser is gonna download this xhtml via HTTP. It's going to see that there's a script tag, which means, oh, I need to execute this client-side program. The program's gonna execute what is the resulting page going to look like to me, the user. Sorry? I, in this case, is going to be a variable. So think of it as x or y or z, but I called it I. Well, we see. Put in some number. We're not gonna prompt the user, but there is a loop, and what's the final word that's gonna be printed as a hint? It's gonna count down from 10 to the word blast-off. We'll look back at this in a second, but let's look at the results now, blast-off.html. I click it. 10, nine, eight, seven, zero, blast-off. Notice, let's view source. Do you anywhere see the number nine or eight or seven or no? You could certainly create this webpage right now on a piece of paper, probably an xhtml, right? 10, open br for a line break slash close bracket, nine, same thing, eight, right? But why do that if you have a programming language that allows you to, with a simpler construct, just change the code and generate it dynamically. It makes it even easier, for instance, to change it not to 10, but suppose we wanted to get a little crazier and really save ourselves the time and have this thing start from 100. I refresh, it's automatically changed. If I view the source, there's gonna be no mention of 17 or 18 or 19. It's all generated dynamically. This is an example, again, of a looping construct, but here you have a loop written in a specific programming language. And dare say the most frustrating experience you will have over the next week or two when tinkering with JavaScript for your final project or the assignment or in section or workshop is going to be, honestly, the stupid things. Where you'll accidentally, in a program like this, forget a semicolon, which, as you'll learn in section or in online tutorials, is important. It might seem silly, right? No human is going to trip over a missing period or comma or semicolon in a sentence, but a computer can't assume that it should be there. It's not gonna make inferences. It's not going to be forgiving. You will usually get, with errors like this, let's make it even worse, forget the parenthesis, save that, reload my blast off page, and now nothing seems to have happened. And it's really hard to fix something when all you're getting back is nothing. And so the best, the most useful lesson I can provide you tonight verbally is that when you are writing JavaScript in sections, problem sets and so forth, you've got to get used to looking for the simple things. And it's probably the most frustrating thing for a new programmer to realize, but even one single character can cost you 15 minutes or more of your life. And so when in doubt, I would say, check the simple things first. I'll give you one final example. This is a much more involved example that'll let you pull over if you wish at home or perhaps in section or workshop, but it involves not only the XHTML constructs and the script constructs that we've looked at, but also the notion of branches. This program called clock one yields the following kind of webpage, my first clock. It's terribly simple. You can get perfect way to end the class, right? Your class will end in 30 seconds. I'm gonna steal a couple extra seconds of your time because what you're gonna notice in a moment is that the counter, when it gets to 59, you would hope would go to what value? Yeah, and probably to be pretty, most clocks would say zero, zero, and then zero, one, zero, two, but this clock in just a moment is not going to behave as that. Moreover, we're using 24-hour time here. Wouldn't it be nice to be able to change this clock to read seven, 30, and then maybe even toss a PM in there? So in a way, we have one bug because that counting from one, two, three looks a little strange. And also, what if I want a 12-hour time? Well, if you look over this code at home, you'll notice that clock two achieves those fixes. And I won't keep you here an extra 50 seconds, but you will see if you play with this at home that we fix the second problem as well. So with that said, I give you JavaScript and I give you to this week's sections and workshops. Good luck.  In our big climactic ending to tonight's fall 2005 mousepad vote, I give you the winning design based on tonight's tally from proxy votes and local students, good night.


This study investigates the relationship between internet use, family burden, emotional support, and mental health, depression, and suicidal addition among patients with gastrointestinal cancer, GIC. The findings indicate a substantial negative correlation between mental health and suicidal addition. Patients who completed their treatment had lower median scores for suicidal addition and demonstrated a stronger correlation between emotional support and mental health compared to those still undergoing treatment. Age was found to moderate the mental health suicidal addition link significantly, while internet usage for health-related information was inversely correlated with mental health and suicidal addition. Family burden emerged as a significant negative influence on mental health, while emotional support positively impacted mental health. The study contributes towards a deeper understanding of suicide risk factors in GIC patients, potentially shaping more effective preventive strategies. This article was authored by Abhishek Choudhury and Yekin Shasava. We are article.tv, links in the description below.