Outline for the day: * Administrivia * 211 or 212 * What 212 is "about" * A bit about Dylan * Several 212 mantras ADMINISTRIVIA CS212 course staff: Greg Morrisett, Prof Aleksey Nogin, TA Melissa Ho, ugrad TA David Liben-Nowell, ugrad TA (Possibly others -- will update when Morrisett is back) * Two lectures a week (Morrisett) - T/TH, 10:10, Hollister 110 * Two recitations a week (TAs) - M/W - section 1: 2:30-3:20 Upson 205 - section 2: 3:35-4:25 Hollister 320 - Cover - new material, - examples - Questions and Answers - No recitations this week - first one is Jan 26 * Six problems sets, worth about 40% of the grade * Two midterms, together worth about 30% of the grade * Final Exam, worth about 30% * Grading: last year about 1/3 A's, 1/2 B, 1/6 C or less. "Past performance is no guarantee of future results." WARNING: Problem sets count for a lot. Do them. * No lates (but, we return graded ones the next section). * Submitted on paper. We *may* ask you to submit on floppies, so we can run your code (later assignments) * Problem sets due about every 2 weeks, first one handed out next Tues * They will require *substantial* time (especially the last 2) Working together: up to two people may work together but if you do so you MUST hand in ONE joint assignment. You may *not* share code with anyone else. Cheating is the best way to get an F (or worse). ---------------------------------------------------------------------- ** All course materials and software are on the Web The URL is http://www.cs.cornell.edu/Info/Courses/Current/CS212 The software is a Java implementation of a Dylan interpreter, so any Java capable web browser will work, though Netscape is the preferred browser. (We've had trouble with Microsoft's IE.) Note: the lecture notes are to help you, but they are just notes (prepared for the lecturer), not a book. Perhaps they will be ready in advance (or perhaps not). They will be on the Web. Dylan and Netscape demos will be scheduled shortly. Office Hours and Consulting hours: Morrisett: Tuesdays, 11am-12noon TAs: To be announced on the Web. ---------------------------------------------------------------------- CS 211 or CS 212 CS 212 is more work (we cover more) and also more credit hrs CS 212 is recommended for CS majors You will get an opportunity to learn Java (take CS 112: transition to Java) Major pre-requisite is willingness to work and to think clearly You *dont* need to know how to program particularly (and, in fact, being a great programmer isn't a big advantage) We will assume a certain degree of mathematical sophistication Math: not calculus per se although we assume you know what a derivative/integral is. Best preparation is High School geometry! We cover: * Computational Problem Solving -- how to think computationally -- requires thinking *clearly* and *precisely* (see: geometry) -- experience with math can substitute for programming experience * Advanced programming techniques - Functional programming, OOP * Formal skills -- reasoning about programs - Most programs are wrong. [Can you name famous examples?] - ATT lost phone service in various cities for many hours due to a C error - Denver airport just recently opened after computers hurled baggage around - Pentium division bug, of course - European Rocket Consortium (boom!) Style of the course: * Mind-bending: - Lots of new concepts, like treating functions as if they were data. - Implementing Dylan -- in Dylan * Lots of work. Be prepared to put in some time, BUT you really need to learn how to put in "quality time", and less of it - Things start out pretty quickly, but unlike most other classes, it doesn't get any *worse*. * We try to have fun (Barney the purple dinosaur featured prominently in PS #5 in previous years). For example, on many of the problem sets, we'll have options for adding new components to the projects (i.e., new features for games). ---------------------------------------------------------------------- This course is called an INTRODUCTION TO COMPUTER SCIENCE. * That's a terrible name, actually. It's not about either one. - It's not really about computers per se; - They're our tools - You wouldn't call surgery ``Scalpel Science'', would you: - It's not a science - Not many disciplines with ``science'' in their name are sciences: - poultry science military science social sciences? - It's more like some combination of - mathematics - engineering - expressive art Names of disciplines are mostly misleading. * Geometry comes from ``Ghia Metra'', ``Geo Metry'', meaning ``Earth measure'' - In Egypt, the priesthood was charged with restoring boundaries of fields after the annual flood when all the boundary markers got swept away. - They invented geometry, more or less, to handle distances and angles and areas. - They weren't quite right, but good enough to run Egypt for a long time. * Geometers are not still measuring the earth -- not mostly anyways * The main contribution was FORMALIZING NOTIONS OF SPACE. Similarly, * We are using tools (computers, occasionally RNA and other gadgets) to do computation. * Our most lasting work is probably FORMALIZING NOTIONS OF COMPUTATION. Understanding what it means to compute. ---------------------------------------------------------------------- Most of 212 is * Building your skills in REASONING ABOUT COMPUTATION. 1. Writing programs: Bag of Tricks - functional programming - higher-order functions - generic operations - object-oriented programming 2. Understanding programs - Correctness - Resources: how much space and time your programs take 3. Better Problem Solving: - Faster - more Accurate Single most important mantra: a little bit of thinking is worth a lot of coding (or: don't hack - think!) Almost all exam questions, problem set questions have very short solutions. But that doesn't mean they're easy... ---------------------------------------------------------------------- There are two classes of high-power programmers: * Wizards * Experts Wizards do all kinds of amazing things, * Squeeze programs into far too little space * Get them to run amazingly fast * Write huge programs overnight, that mostly work. Experts do other kinds of amazing things: * Write huge programs over years, and keep them working right. * Write programs which other people can use, fix, adapt. * Work with other programmers (or be their boss) Never program behind a wizard. (You can't understand their code, or fix it.) You can be both: * Expert wizards are pretty rare, and *very* valuable. We can't quite train you to be a wizard. * If you are one, you might show it this semester. We can, and will, train you to be an expert. ---------------------------------------------------------------------- Later courses (and what CSists do) are *not* programming courses, mostly * Programming is a basic tool * Mathematicians don't spend all their time solving calculus problems. * But they know calculus, and solve calculus problems when they run into them. Computational Processes aren't quite mathematics, though: Comp. Proc: ALGORITHMIC (IMPERATIVE) knowledge. - *How* to do things Mathematics: DECLARATIVE knowledge - *What* is. Our goal is to help you develop some computational rigor: precise descriptions of how to compute something ---------------------------------------------------------------------- Declarative vs. Imperative: DECLARATIVE: sqrt(x) is the unique y such that y*y = x and y >= 0. This *defines* sqrt(x) -- at least for some x's -- * With a bit of mathematics, you can prove that if there are any y's like that, there's only one. * So, we can tell that, e.g., sqrt(9)=3 from the definition. But it doesn't tell you how to FIND sqrt(x), just check whether a given y is sqrt(x). Well, to compute sqrt(x) we could try all possible y's, compute y*y, and check if it's x. But that would take a long time. Observation: if g > sqrt(x), then x/g < sqrt(x) if g < sqrt(x), then x/g > sqrt(x) and when g = sqrt(x) !?! Proof: g > sqrt(x) -> 1/g < 1/sqrt(x) -> x/g < x/sqrt(x) ALGORITHMIC or COMPUTATIONAL knowledge: To find sqrt(x) -- or rather, a good enough approximation to it -- 1. Make a guess g, which should be nonnegative. 2. Improve the guess, by averaging g and x/g 3. Stop when the guess is good enough. How? When |g*g-x| is very small. This is one of the first ALGORITHMS (= METHODS OF COMPUTATION) * Heron of Alexandria, about 100 AD (Newton generalized it to cover almost everything, so it's called Newton's Method) It works quite well: * Take x = 2, * guess g=1, why not? * x/g = 2, so g := 3/2 = 1.5 * x/g = 4/3, so g := 17/12 = 1.4166666 * x/g = 24/17, so g := 557/408 = 1.4142156 which is off by 6e-6. ---------------------------------------------------------------------- A key idea of the course: ABSTRACTION: * Take a computational process * Give it a name * Give it a standard interface - That is, explain what its inputs and outputs are ** e.g., define sqrt(x) to be the result of doing Newton's method. x [------] sqrt(x) ------>[ SQRT ]---------> [------] ** Stereo connectors - Zillions of different kinds of boxes. - They all have the same set of connections and cables, and you can hook 'em up freely. ---------------------------------------------------------------------- We'll use the programming language Dylan * It's a DYnamic object-oriented LANguage - Overviewed in the handouts that are on the Web - Start today, cover in recitation and next lecture, - Then you'll know most of it. `know' is half a lie. * I could teach you the rules of chess in a day. * You won't be a good chess player so fast! * After a semester you'll be an expert though. First lie of many! (This course is successively lies, each a bit closer to the truth) (Ptolemy, Copernicus, Kepler, Newton, Einstein) ---------------------------------------------------------------------- Rules of Dylan: - Grammar (aka Syntax) * It's described as ``Prefix-order, fully parenthesized'' 1. The operation to perform comes *first* (prefix-order) 2. Every part of the program has parentheses around it, This has two effects: 1. The grammar is *very* simple - Never any question about what expressions mean - WHENEVER you write something, put the operator first. 2. It's kind of alien at first. It isn't "just like Pascal or C". Mantra: "Dylan is not C++/Pascal/C/Java". For example, the Pascal 4+5*2 [AMBIGUOUS] is the Dylan (+ 4 (* 5 2)) [NOT] Another example: in Pascal, IF false THEN IF true THEN x:=1 ELSE x:=2 does nothing. [Pascal's ambiguous, and there's a special rule which makes it read IF false THEN (IF true THEN x:=1 ELSE x:=2) ] In Dylan, the analogous code is never ambiguous. That doesn't mean it's always easy for humans to read it! Everything in Dylan is an EXPRESSION, which means that it has a value. The value of (+ 4 (* 5 2)) is 14. Mantra: Everything in Dylan is an expression, and has a value ---------------------------------------------------------------------- An expression is either * a PRIMITIVE or * a COMBINATION PRIMITIVES are variables and constants: sequence of characters not containing parentheses, spaces (There's a little more to it than that) 1 -31 "a string" x a-long-variable-name (dashes, not underscores -- underscores are gross and PASCAL-ish) + (note the last one! the name of a function is a variable just like any other) COMBINATION: is one or more expressions * Enclosed in parentheses * Separated by spaces: (+ 3 5) (gcd (+ 51 8) 6) The order of expressions in a combination is ALWAYS: (OPERATOR operand1 ... operandn) ^ thing to do ^ things to do it to Note that the definition of an EXPRESSION is recursive (really, inductive, it is a PRIMITIVE or COMBINATION, the latter of which is one or more EXPRESSIONs). First of many... ---------------------------------------------------------------------- For *almost* all operators, the value of a combination is determined by the following rule: To evaluate a combination: E. Evaluate the subexpressions. [[ THIS RULE IS RECURSIVE: ``to evaluate, evaluate''! ]] The 212 Mantra: Everything in 212 is recursive, including the 212 mantra! A. Do the specified operation (value of the first expression) to the operands (remaining expressions) Example: (* (+ 3 4) 2) E. Evaluate *. It comes out as `multiply.' E. Evaluate (+ 3 4) E. Evaluate +. It's `add' E. Evaluate 3. It's 3 E. Evaluate 4. It's 4 A. Add 3 and 4. It's 7 E. Evaluate 2. It's 2 A. Multiply 7 by 2. It's 14 Note that we're doing it inside-out. ---------------------------------------------------------------------- So far we have a fully-parenthesized 4-function calculator. * Big deal. They're free in cereal boxes. The same basic mechanism holds for all Dylan expressions * Except Special Forms -- BUT there are not many of these in the language ---------------------------------------------------------------------- One of the most powerful abstraction techniques is to give things names. * sqrt(x), not ``the unique y such that...'' This sounds kind of trivial, but it's very hard to get the right parts of a problem and give them the right names. Much of system DESIGN is thinking clearly about what the PARTS of something are, not just hacking, and naming things descriptively can help. The way to name a global variable in Dylan is using the special form define: (define (data ) (+ 9 4)) data is now 13 (define (add-up ) +) add-up is now the same function that + is (define (worf ) (add-up data 2)) worf is now 15 In general (define (name type) expr) defines the NAME to be of the given TYPE and assigns it the value that results from evaluating EXPR. The value of EXPR must match the given TYPE (more on types later, but and are two primitive types). The general evaluation rule given above wouldn't work for define: * We'd have to evaluate data, but we're trying to define it. So that doesn't work. Special forms have special rules. * define associates the VALUE of the third expression with the NAME given in the global (as long as the TYPE of the value matches the given type). ---------------------------------------------------------------------- MAIN POINTS: * Studying computational processes in a language (Dylan) Two parts: DECLARATIVE ("what is" description) ALGORITHMIC ("how to" description", may be code) * The language has simple, uniform evaluation rules (thing-to-do operand1 ... operandn), except for a few SPECIAL FORMS like DEFINE * One of the most important aspects of good program design is good abstraction, and a lot of that involves thinking clearly about complex things. This course is about techniques for doing that.