$Id: lecture01.txt 75 2006-06-04 23:10:36Z phf $ Original notes by Joseph Vidalis and Rami Subramaniam. Edited by Peter Froehlich. I took out things that are covered on or available from the course website already: http://www.cs.jhu.edu/~phf/2006/summer/cs107/ Please report any kind of error you find to me, I'd like to keepimproving these notes for the future. ----- Formally: Dr. Peter H. Froehlich. But please just call me "Peter"! The course focuses on *programming* primarily, that we're using Java is more or less an accident. Other languages would be much better for teaching this stuff, but we're stuck with this one. Aside from showing up to lectures, you're expected to read (and fight with!) the text book; feel free to do problems from the book on your own; I'll assign different things, and you're of course expected to do those assignments. Come with questions on the stuff you read, there's time at the beginng of each lecture to discuss the readings. Expect one assignment for each class meeting. That's a lot of assignments in very little time, so keep up. I won't accept late assignments, that should help. :-) Make sure that you send *plain* text emails to the discussion list, not fancy HTML emails with colors and bold and all that. The list may decide not to accept things it doesn't like, but it likes plain text for sure. Not my problem if you miss points because of this. ----- Computer Science is a debatable term. We'll use it for what we do, but really it's neither about computers nor is it strictly speaking a science. "Computer Science is about computers much like Astronomy is about telescopes." - Hal Abelson (?) Aside from "science" in the sense of "building theories" there is also a lot of "art" and "engineering" involved. Art because we want to write "beautiful programs" and engineering because there are many practical concerns about the limits of our ability as humans to deal with complexity. And software gets *really* complicated *really* fast. Programming is a somewhat frustrating activity at first since the machine is really dumb. You have to specify every little thing, you can't say "Well, it's like this, just try!" to it. Try to write down exactly how to tie shoelaces to see what this need for explicity detail really means. On the upside: "If you want to understand something, you have to teach it; if you *really* want to understand something, you have to teach it to a computer" - Donald Knuth Being forced to be explicit about every little thing turns some computer science people (for example me) into fans of what you could call "pedantics". If I read a lease for a house and there is one or more sentence in there that's not completely clear, I will try to get the contract changed until it's as unambiguous as possible. That costs me leases... :-) ----- Let's distinguish three things to start with: Languages, Programs, and Machines. A language gives you a bunch of symbols that mean certain things and a bunch of ways to form longer symbols out of the given ones. Yes, you can think "English" here. But you can also think "Architecture" or "Electricty" or "Digital Logic" (which is useful as an example here). The language of "Digital Logic" talks about two levels of currents in a circuit: High and low, meaning 1 and 0. The language also has "wires" that allow you to connect things and "gates" that allow you to combine currents in various ways. For example an NOT gate switches things around: If you send in "1" you get out "0" and vice verse. An AND gate takes two inputs; if they are both "1" it outputs "1" as well; otherwise it outputs "0". And there are OR gates, which also take two inputs; if they are both "0" it outputs "0" as well; otherwise it outputs "1". A program is a sentence in a given language. It is formed accordings to the rules of the language, and it means some combination of what the parts of the sentence mean. If we stay with "Digital Logic" a program is, for example, a sketch of how we "wire together" various gates. Note that I said "plan" here, I didn't say that we actually wire anything together. But we could, and if we do then we're building a machine that will "execute" our program: it will "behave" as we designed it (well, at least we hope so). It is possible, for example, to design a program and then build it in actual hardware to produce the following machine: n1 +-----+ --->| | | ADD |---> n1+n2 --->| | n2 +-----+ We're not showing the implemented program here, that's hidden inside the "ADD" box. But there is a way to wire together AND, OR, and NOT gates in such a way to allow two numbers to be added. The numbers will be encoded in binary, i.e. instead of adding 3 and 4 to get 7 we need to add 11 and 100 to get 111. But the thing still adds. What's cool about Computer Science is that language, program, and machine are all the same. We'll see this again and again in the course. Nifty. :-) BTW, we made a brief excursion into adding in binary notation, so here for reference it is again. Let's say I want to add the two binary numbers 101 and 11001. What I do is simpy what you would do for decimal numbers: write one under the other, and start adding "digits" from the right. However, in binary we only have 0 and 1, which means that adding two digits is always one of four cases: 0 + 0 = 0 no carry 0 + 1 = 1 no carry 1 + 0 = 1 no carry 1 + 1 = 0 and a carry to the next place Thus, working from right to left, we get: X 101 Y 11001 C 000010 --------- S 11110 ----- From "very far away" a Java program looks like this: Packages > Classes > Methods > Instructions + Expressions > Interfaces > Messages Packages are used to organize related pieces of a program in various ways. Packages contain classes and interfaces. Classes are a second form of organizing related pieces of a program. They are also "cookie cutters" for "objects" which is where that whole "object-oriented programming" thing is from. We'll see that later. Classes contain (among several other things) methods. Methods make stuff happen. The "main" method we'll see in a bit is an example, it's where your program starts. Another example is the "println" method we'll see in a bit which can be used to "output" various things to the screen. Methods, in turn, contain instructions and expressions. Instructions make stuff happen as well, for example when we say "println" inside our "main" method that's an instruction. Methods can be used to "group" a sequence of instructions together and give it a name, that way we don't have to write similar sequences over and over again. Expressions are parts of instructions that do some actual computation. We'll see a lot of these today, but addition or division are two simple examples you all know. Expressions yield a result, a value. Instructions don't yield results, they *just* do stuff. Interfaces and messages are around for a reason as well. To be brief at this point: It's sometimes useful to describe a set of operations in a general way. The operations, for example "ADD" are described in forms of input and output, and in terms of what the operation "means" for a program. However, interfaces and messages don't define *how* something is done, they just describe *what* is to be done. Right now that's all just gibberish I'm sure, but I wanted to mention all the big pieces now so that you can "place them" in the bigger picture as we go along in the course and cover them. ----- The book makes a big deal about distinguishing what is hardware and what is software. Yes, there is a difference: hardware is a physical reality, software is not. Hardware is "fixed" and can't easily be changed once manufactured while software is "mallable" and can be adapted in certain ways. Examples: Hardware Software - Mouse - OS X - CPU - Device Driver - Motherboard - Office Suite ... ... You could also say that hardware is like your body, while software is like your emotions: They are potentially fleeting and change often, especially in computer science courses. :-) What's much more important is (a) how we "bridge the gap" from software to hardware and (b) how we can "ignore" hardware from a certain perspective. Let's start with a piece of hardware, a PowerPC processor for example. That's a complex machine, capable of running programs written in PowerPC machine language (which is a mess of zeros and ones that nobody really wants to deal with). We write our programs in Java, which is certainly not what the processor understands. There are two things we can do, and both involve software. We can use a "compiler" which is a machine (in software) that can *translate* sentences written in Java into sentences written in PowerPC machine language. What we do is write out Java program, run the compiler, out comes a PowerPC program, which is what we can toss on the hardware to run. Alternatively we can use an "interpreter" which is a machine (in software) that *pretends* to be some other machine. For example, we could write an interpreter in PowerPC machine language that understands how to run Java programs. Then we'd write our Java programs and hand them to that machine, which in turn runs on the PowerPC. Building these pieces of software is not trivial, but it's of course possible. We'll actually use both of these things at the same time since Sun decided to have a compiler as well as an interpreter. The Java compiler translates from Java to the language of what's called the "Java Virtual Machine". The JVM is an interpreter that runs on the actual hardware machine. BTW, we could call the PowerPC processor itself an "interpreter" as well, and of course it is possible to describe the processor as a complex program in some language. Full circle. :-) ----- We briefly introduced some "development environments" such as jGRASP and Eclipse; there are lots of others, such as BlueJ and Jcreator. These make certain programming tasks easier, at least they claim to, but they don't make programming itself any easier. And that hard part is what we're here to learn. ----- The "magic" you just have to "accept" for now, until we get to the point where each piece can be explained in detail: public class Hello { public static void main( String[] arguments ) { // we'll play here for a while before going elsewhere... :-) } } ----- EOL -----