CS99, Fall 2002 Mon 9/2 Lecture 2 Reading: Chapman, chapter 1 ------------------------------------------------------------------------------- Objectives: (1) Introduce the course (2) Introduce the objectives as related to CS100 (how CS99 prepares for CS100) (3) Advice (4) Explain problem solving (5) Motivate need for programming (6) Overview of computers (7) Overview of the *process* of programming ------------------------------------------------------------------------------- (1) Introduce the course You are responsible for the policies and instructions in the syllabus, which is on-line. Do everything in "What To Do First"! Where is *this* file and other notes? See Lecture Notes. ------------------------------------------------------------------------------- (2) Course objectives See syllabus. CS100 expects students to acquire the following skills: + Use computer and Internet technology (web, USENET, CIT resources). + Develop and implement algorithms from verbal/written problems. + Develop programming skills to produce working code/software (design, test, trace, debug, document, demonstrate). + Categorize and apply a computer language (elements, syntax, semantics). + Build and use expressions with variables, operators, and other language elements. + Implement control structures (conditions, loops). + Use methods/functions to replace redundancy and improve modularity. + Know the meaning and applications of the fundamentals of object-oriented programming. (encapsulation, inheritance, polymorphism). + Use and apply arrays for situations with collections of data (one dimensional, multidimensional). + Perform text processing with characters and strings. + Search and sort information (linear search, binary search, select sort, insert sort). + Perform user and file input and output for text. + Plot numerical data. =================================== Page 01 =================================== (3) Advice Each semester, we seem to give the same advice to students. What follows i is our collective wisdom that course staff often passes along: + Follow the course procedures. With so many students, we generally do not bend the rules, to be fair to the majority that follow them. + Do not assume that because you have no experience that you will do "the worst." Sometimes inexperienced students have been first in the class. + If you have programmed before, do not assume that this class will be a "breeze." Sometimes an experienced person has developed bad habits, which we must break. + You will take tests without computers in front of you. So, you must learn how to develop your programs on paper first. (Guess what industry prefers?) Heed the programmers' creed, "The sooner to computer, the longer it takes." + Programming is a skill which you must practice, like sports and music. + Go to lecture: professors like to test what they teach! + Go to section: sometimes details are left for section. Plus, waiting to pick up work from Carpenter means that the consultants spend more time handing back work and not answering questions. + Seek out help when you are stuck lest you get even further behind. Likely you will need to spend some time catching up, but better now when you have the time, than later. "Save now--suffer later, or suffer now--suffer later." + Retrieve all graded work. If you suspect there's mistake in your grade, only the actual graded work will be your proof. + Letter Grade or S/U? If you take CS100 S/U, under no circumstance treat the course as a "cake walk." In the past even S/U students have had to drop out or fail because they did not practice. + Attend all classes! Not everything discussed in lecture and section is in the book or online. + Wait-and-cram studying techniques typically cause failure. You must practice! Non-technical majors (non-engineering, non-CS) are not at a disadvantage unless they do not practice. + Whatever is fuzzy before a test doesn't usually clarify during it. + When all else fails, the answer is usually "Carpenter." ------------------------------------------------------------------------------- (4) Problem solving + problems are physical and abstract + build models which are physical and abstract + who and how do we (or what) solves a problem? ------------------------------------------------------------------------------- (5) Motivate need for programming + why use a computer? + problems that are complicated, tedious, attractive...? + PROGRAMMING: automating problem solving =================================== Page 02 =================================== (6) Computer Rudiments + hardware: physical components of a computer + software: "the intelligence" that runs the hardware - create with programming (coming up!) + information: bits and bytes -- sequences of 1s and 0s (digits) that represent non-digital information + memory: "space" inside a computer to store information - software can "borrow" a portion to use - programming involves using memory + file: collection of information with a name + directory: collection of files + folder: same as directory + path: location of file or directory starting from the "uppermost" directory + ASCII/text: characters found on the keyboard - uses 8 bits to represent a character which is a byte - ASCII (or text) format is universal - can load into almost editor and wordprocessor - can edit files with programs called text editors + Program: file composed of instructions using a computer language - usually text because we need to type those instructions! - the process of telling the computer to activate commands in a program is called running or executing - information is passed from your text to the computer - computer activates each instruction in sequence + Interpreting: computer reads each line of code and acts up it before acting upon the next line + Compiling: process of converting code into an unreadable format - more bits and bytes, but condensed - can create "runnable" (executable) files that quickly run your programs + Input: - any information you supply to a program + Output: - any information reported by a program ------------------------------------------------------------------------------- (7) Process of Programming Really understated process: + start with problem + look for solution + write I'll be a bit more specific: (1) Gather data - figure out abstract and concrete "things" in problem (2) Gather processes - determine behaviors these "things" have (3) Algorithm - try to connect things and behaviors in a sequence of steps/instructions called an ALGORITHM There's a connection to the writing process: + brainstorm + research + outline + draft + rewrite + polish + review + repeat =================================== Page 03 =================================== (7 continued) Brainstorming + do NOT start writing the program! + think about the problem, jot ideas down, and let your mind wander... + skim problem and see what strikes you + "sooner to code, the longer it takes!" Researching + look for nouns: what will be input, what will be reported, features about the model + look for verbs: what the program is supposed to do, how each noun "behaves" + specifications: find out what client *really* wants and expects + your knowledge: do you need to learn a language/technique? also, find related work already done (that's legal to copy) Outlining + writing an algorithm: a collection of steps that solve a problem + this is the part that consumes a *lot* of programming! ==> How to write an algorithm: + break solution down into sequence of steps (each step is an instruction) + use PSEUDOCODE (langauge that resembles a computer language) terms: repeat, if, else, continue, return, stop, start, etc + avoid minutia and over-generality -- look for the middle... (often depends on task at hand!) + STEPWISE REFINEMENT: may have to keep breaking down steps + final algorithm is a program in "words" + example: think recipe - someone else wrote a sequence of instructions - used terms that are accepted and have known values/meanings - you, the human, act on the instructions - something is created and hopefully tastes good ==> Stepwise refinement: + the process of breaking a big problem into smaller problems, which are easier to solve + why? an algorithm is high-level, usually + eventually each sub-problem yields a smaller amount of code that is easier to program + ultimately will a collection of "sub-programs" that comprise the full program Other Steps (saving for later): Drafting: convert algorithms into code, test along the way! Rewriting: fix the bugs Polishing: ensure that the program works and add the bells and whistles Reviewing: does your client like the program? Repeating: fix what you missed.... =================================== Page 04 ===================================