OOP-FINAL EXAM REVIEWER.docx - Lesson1 Programming Basics...

This preview shows page 1 out of 423 pages.

Unformatted text preview: Lesson1: Programming Basics A.What is Programming? So what exactly is programming? Well, you may have heard a phrase like this before. A computer program is a set of instructions. Here is the problem. This sounds like one of those phrases that might be technically true and is kind of useless, like the human brain is 80% water. Because you hear this phrase but then you see a complex program like Photoshop or Flash or something playing high-definition video or a 3D game and you think, "Yeah but that can't just be a set of instructions." But that's exactly what these are, all of them. Every computer program is a series of instructions. A sequence of separate small commands, one after the other. Now there maybe five instructions contained in a program, maybe 5,000, maybe 5 million. Each instruction is telling the computer to do something very small, but very specific and the art of programming is to take a larger idea and break it apart into these individual steps. And the wonderful thing is everyone can already do this. Let's imagine that you're sitting in your house in the suburbs waiting for a visit from a friend. Your phone rings, it's her, and she's asking for directions. She tells you she's at a nearby gas station and you know it. You pass it every day, it's on your way home. So that journey point A to point B drops into your head as one piece, but you instantly know you can't communicate the journey the way you understand it. You have to break it down into simpler parts and you have to think about it to break it down because it's so natural to you. So you start to pull this apart and "You say you are going to need to turn right, then drive one mile, then you will turn left on Acacia Avenue, then you'll take the second right and then it's the fourth house on the left." Specific, individual, simple, clear, self-contained instructions. Now you know that sequence here is vitally important. You mix these up, you will get very different results. "Turn right, drive 1 mile" takes you to quite a different place from "drive 1 mile, and turn right." But this same level of simple instructions, turn right, turn left, go straight, could take you around the corner or it could take you on a five-year trip around the world visiting every Starbucks along the way. You'd still have instructions like turn right and left. You'd just need a lot more of them. So with programming we are giving directions to the computer. It's breaking apart a more complex idea, a more complex task, into its smallest individual instructions and then using a programming language to write those instructions. Now, of course if you have never programmed, it's not clear right now what those instructions might be. You know it's probably not turn right and turn left. So what are those basic fundamental instruction you give a computer? Well, they are often very basic. They are things like add two numbers together, or display a letter on the screen, check to see if the user just hit the spacebar, change the color of one individual pixel. But as with driving directions, you string together enough computer instructions that will get you very far indeed. So when it might seem difficult to see how you get from basic examples you see when beginning programming to complex games or applications, well that's what you get when you have a hundred people writing these instructions for sixty hours a week for several years, combined with the ability of the computer to process them mind-bogglingly fast, means that we could, if we wanted to, write the set of instructions that could calculate every single individual pixel on the screen thirty times a second. Now think about that level of speed and think about why your instructions better be right. Because getting them wrong is like giving wrong directions to your friend when her car only has two speeds: 0 and 5000 miles an hour. You get those directions wrong, and the next call you get is her asking why she followed your instructions to the letter, but her car is now in the middle of a forest crashed into a tree. Computers will do exactly what you tell them, so the instructions you give them better make sense. In programming languages we write these instructions by writing what are called statements. Statements in programming languages are kind of like sentences in English. They use words, numbers, and punctuation to express one thought, one individual piece. Most programming statements are pretty short, just a few words. Now, exactly what words, numbers, and punctuation you use depends on the programming language. Some languages want each of your statements to end with a semicolon, like ending a sentence in English with a period, and others don't. You just go to the next line and start writing the next statement. Some languages are all uppercase, some languages are all lowercase, some languages just don't care. Now, understanding the rules of each language is understanding the syntax of a programming language. So programming is the ability to take this idea in your head, break it apart into its individual pieces, and know how to write those pieces in the programming language you are using at the time, writing your statements in the right order, using the right syntax. But what language? Well, sometimes you get to pick a language and sometimes it's kind of picked for you. We will talk about that in a moment. B. What is a Programming Language? There have been hundreds of programming languages since the start of computing. But at any given time there are perhaps a dozen or so that are popular and by popular I simply mean that language is used in a lot of current software, it's used by large numbers of people, and there is an active community and a significant job market for that language. Now as the years go by, different languages wax and wane in popularity. New languages do come along. Some are big hit but most of them aren't. So this list changes, but it changes slowly. Now most programmers will learn and use many languages over the course of their career. Once you have got the basics down, additional languages do become easier to pick up. A little later in this course we will dive deeper into the most popular languages, but if you're new to this, you might think why, why are there so many languages? If all we're doing is writing simple instructions for computer, why isn't there just one computer language? Well actually that language does exist, but it isn't any of these. You see the CPU, the chip, the central processing unit that is the brain of any computer, desktop, laptop, server, phone, game console, well it doesn't understand any of these languages. We might informally say when we are programming that we're writing code the computer understands, but we are not. Not really. You see the only thing that chip understands his called machine code or machine language. Now these are the real instructions that run directly on your computer hardware. So the question is why don't we just write machine code? Well because it's almost impossible to do. It's numerical operations, tiny instructions that work on the smallest pieces of memory inside your computer and even if you could write it, it's basically unreadable by anybody else. This is for the machine. It's not for a human being. And because machine code works of the level of the CPU, it would be different machine code for different models of CPU. Writing a full program in machine code would be like digging a tunnel through a mountain with only teaspoons. It's theoretically possible, but it would take you so long and so tedious that you wouldn't even try. So all of these languages, the popular ones and the others, are in fact a compromise. They are invented languages. They are just trying to bridge the gap between us as human beings and the computer hardware. Now, some of the languages are actually quite close to machine code. The closest is something known as assembly language. In general the closer a language is to machine code the more difficult it is to write and the more you have to know about the actual hardware. And this what's called a low-level language. Now as you move away from the CPU into what are called higher-level languages you worry less about the hardware. Now this code is often easier to write and to share even across different platforms, but it can be slower when running because these languages aren't necessarily optimized directly down to the CPU level. Having said that, these days speed differences are minimal and we will be focusing on the high-level languages in this course. But whatever we write has to be converted down to machine code before it can run. So while this machine code piece seems like the most important piece, we are not really interested in machine code. Sure we do need to know that that's what runs, but programming for us is all about the source code. That's what we call the statements we write, Java, C++, Ruby, Python whenever. We write the source code that will at some point be translated then into machine code, so it can run on the computer. When I say I'm writing code, it’s source code, and when I say programming or I am coding, I mean the same thing. So to start writing any of these programming languages, writing these statements, writing our source code, we need to understand three things: 1) how to write it, literally where do we actually start typing this, 2) to understand how that source code will be converted to machine code, and 3) how do we actually run it, how do we execute our program? And some of this does depend on the language that we pick, but let's begin with how to actually start writing these statements. C. Writing Source Codes? Programming language source code is written in plain text. You can open up a simple text editor that comes with your operating system like Notepad on the PC or TextEdit on the Mac, and they work just fine to write any programming language. There's nothing magical about source code itself. It's just text. And that's plain text, not rich text. So here for example is a text editor with some JavaScript in it and here is one with some Perl and here is one with some Ruby and here is one with some Groovy. And yes, Groovy is a language. Now right now don't worry at all about trying to memorize any of these. That comes later. Just observe them. It's common to see different file extensions being used like .js for JavaScript and .groovy for Groovy files but they are no different from .txt regular text files. But what you don't want is a word processor. If you're writing code in a program where you see a formatting bar with bold and italic options, you are probably in the wrong place. Programming language source code does not need to be bolded or underlined or italicized or justified. So say if you're using a program like TextEdit on a Mac that can work in the either rich text or plain text modes, you want Plain Text. Now programs don't actually have to be much more than this. In fact these would all be considered very simple but technically complete programs in these languages. Just one statement, one instruction that outputs the words Hello, world on to the screen. Now Hello, world is the classic example of this simplest program imaginable in any language. So let me show you a few more. So this is a one statement program written in a language called ALGOL 68 and by 68 here I mean 1968 which is when this language was released. ALGOL 68 is not a language you're ever going to need to know, but on the other hand you might want to know Python. So this is a one statement program written in Python 3 released in December 2008, and this is a one statement program written in a language called Lua. Yes, this particular statement is the same in all of them and in a few more languages besides. You see many languages share a common history and they are often more alike than they are different. Now just because this statement is the same in these languages does not mean these languages are identical. Far from it, but there are often significant similarities between languages. Now, some languages do need a little more than one single statement to be considered a full program. Many languages like to be given explicit starting and ending points. An older version of ALGOL, ALGOL 60, was written in all caps and actually required the words BEGIN an END to mark out your program. Languages like C and other languages based on C like C#, C++ and Java, they require what can first seem like intimidating amounts of curly braces and weird esoteric keywords just to get something simple to happen like the words, Hello, world! Now you might think, okay so am I supposed to remember all of this to write just the simplest program? Well, no, not really. You see just because you can work in a plain text editor and it is useful from time to time, doesn't mean you have to and you probably won't want to. Because with a basic text editor you're completely on your own writing the stuff and there are other applications that can actually help you write this code and make your life easier. First we have programmer's text editors. These are plain text editors with some extra features added on and there are many of them available on every platform. Some are free and some are commercial. Typical features of these involved simple things like line numbers, more powerful Find and Replace. They often have color-coding. This is not the same as formatting. Color coding happens automatically and it helps you read and recognize different parts of the language. They often have syntax checking, kind of like spell checking in a word processor. Syntax checking will let you know if it finds something wrong with your code as you're actually typing it. Some of these text editors are oriented towards a particular language, say just Java, and some others might have support for several dozen languages. Now if you do any web development you might find that your chosen web development application is also a usable programmer's text editor. And then we have Integrated Development Environments or IDEs. These are large programs and include a good programmer's text editor, but usually add on a whole bunch of features for professional development. Examples of IDEs would be Apple's Xcode on the Mac or Microsoft's Visual Studio or Eclipse, which is a crossplatform. Now in this course we are not going to worry about IDEs. You'll get into those when you start concentrating on a particular area of development. So while you don't need a special program to write your code you'll probably end up wanting one. However, once we start to write this code we then need to understand how it will be turned into machine code so it can run on the computer itself. D. Compiled and Interpreted Language So we need to get our source code converted into machine code somehow before it can run and there are two main ways of doing this: what's called compiling the source code and what's called interpreting the source code. Now luckily, this is not a big decision you have to worry about. Most languages you'll deal with will naturally fall into one or the other, but it is worth knowing the difference. So let's have a simple scenario. Let's say it's just you and me. You have your computer and I have my computer and you're going to write a program that you want me to run. Now, with a compiled language, what happens is you write your source code and then you have a program called a compiler that will go through that source code and create a separate file that contains the machine code, and you just give me that file. This end result is sometimes referred to as an executable or an executable file because I can directly execute it. I can now just run your program. You keep your source code and I never see it. Now, with an interpreted language on the other hand, you don't compile your source code beforehand. You just give me a copy of it. So I'll need my machine to interpret it whenever I want to run your program. Now, interpreter is different to a compiler. It does this on-the-fly. We can think of it as going through your source code line by line and processing it on the spot. It does not save it as a separate machine code file. Now, you've used interpreted languages even if you don't know it. Whenever you've looked at a webpage with JavaScript, which if you've surfed the web for more than two minutes in your lifetime you have, this is what's been happening. The JavaScript has been sent to you over the web along with a bunch of other files like webpages and images and it's been sent as source code onto your machine, and your web browser has just interpreted that JavaScript so it can run that code. So which one is best? Well, they both have their good and their bad points. Benefits of compiled code. Once it's compiled, it's immediately ready to run and you could send it to 100 or 1,000 or 100,000 different people. It's ready to go. It can be optimized for a CPU, so it can actually be faster and you don't have to send your source code to everybody, which might be a good thing. However, the downsides are if I compile it on a PC, that executable file won't work on a Mac. In fact, it often needs to be compiled separately for different kinds of CPU even on the same platform, and when you're writing code to compile is an extra step that you have to take every time you want to test your program. Now, with interpreted code, the big benefits are I don't really care what kind of machine is on the other end, because we don't provide machine code. We just send the source code and we let the other side take care of it. So it can be more portable and more flexible across platforms. It's also a little easier when testing because you just write your source code and then run it, letting the interpreter take care of converting it. There is no in-between compile step. It can be easier to debug when things go wrong because you always have access to all the source code. However, it has its down sides too, because everyone who needs to run that program on their machine has to have an interpreter for that language on their machine. It also can be slower because you have to interpret it every time the program is run, and the source code is effectively public because you're sending it to everyone who needs to run that program. Now, because there are good things about compiled languages and good things about interpreted languages, there is also a third way of doing this which is a bit of both. Instead of the compiled model where all the work is done upfront but can be a little bit inflexible or the interpreted model where all the work is done on the receiving end but can be a little bit slower, we kind of do half-and-half. Upfront, we compile it part of the way to what's called an intermediate language, which takes it as far along the way to machine code as it can get while still being portable often across platforms. You then distribute this, sending it to the people who need to run it, and each person who runs it takes it the last step to take it to machine code on their computers. This is sometimes referred to as Just-In-Time or JIT compilation. Now, this intermediate language sometimes also goes by the name of bytecode. So this process has to happen somehow. It's just how much of it happens on your machine and how much of it happens on mine. Now, while theoretically all computer languages could use any of these methods, the normal usage of any one language tends to be one or the other. So for example, C, C++, and Objective-C, these are typically found as compiled languages, so you need a compiler. Now the compiler can be downloaded for free but they're often built into integrated development environment applications. Now, languages like PHP and JavaScript and indeed most languages with the word script at the end are usually interpreted, and languages like Java, C#, VB.NET, and Python use this intermediate hybrid approach. Now, whethe...
View Full Document

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture