Summer 1999
Course Staff (including consulting and office hours)
Handouts
General Information
Syllabus
Lecture Notes
Review Session (July 30) [.doc]
Lecture 20 [.ppt]
Lecture 21 [.ppt]
Lecture 22 [.ppt]
Lecture 23 [.ppt]
Assignments
Assignment P4 [.doc]
Assignment P5 [.doc]
Extra Credit Assignment (in .doc format)
Quizzes
Quiz 1 [.doc] [answers]
Quiz 2 [.doc] [answers]
Quiz 3 [.doc] [answers]
Quiz 4 [.doc] [answers]
Quiz 5 [.doc] [answers]
Quiz 6 [.doc] [answers]
CS 100 Notes on Java Programming Style (from CS100 Fall 1998)
Guide to CodeWarrior (from CS100 Fall 1998)
Debugging with CodeWarrior (from CS100 Fall 1998)
Errata (minor corrections with respect to the review session on Friday the 9)
Welcome to the CS 100 website!
CS 100 is a 4 credit course that introduces fundamental computer programming and problem-solving concepts. Programming projects are written in Java. Some assignments will also use Matlab. CS 100 assumes no prior knowledge of computing and has no prerequisite computer science courses. (However, a majority of the students in recent years have had some programming experience prior to taking CS100.)
This year, the summer version of this course runs from June 28 until August 10, meeting Monday through Friday, 10:00--11:15 AM in Olin 155.
Latebreaking news:
SUNDAY NIGHT REVIEW SESSION: 6PM - 8PM, Phillips 101.
Reminder: FINAL GRADES will be posted on the door of 5141 Upson Wednesday morning. See Lyn before 2PM on Wednesday if you have any questions.
FINAL EXAM: August 10, 8AM-10AM, Olin 155. To see the university summer session exam schedule, click here.
A note on Object-Oriented Programming received via NewsScan:
WORTH THINKING ABOUT: WHAT IS OOP? Conceived originally by software pioneer Alan Kay, "object oriented programming" (OOP) has been one of the greatest developments in this history of computing. So just what exactly does is it mean for a program to be "object oriented"? Here's a good explanation of the term, found in Bruce Eckel's book, "Thinking In Java":
"The progress of abstraction: All programming languages provide abstractions. It can be argued that the complexity of the problems you can solve is directly related to the kind and quality of abstraction. By 'kind' I mean: what is it that you are abstracting? Assembly language is a small abstraction of the underlying machine. Many so-called 'imperative' languages that followed (such as Fortran, Basic, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the 'solution space') and the model of the problem that is actually being solved (in the 'problem space'). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire 'programming methods' industry.
"The alternative to modeling the machine is to model the problem you're trying to solve. Early languages such as Lisp and APL chose particular views of the world ('all problems are ultimately lists' or ' all problems are algorithmic'). Prolog casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches is a good solution to the particular class of problem they're designed to solve, but when you step outside of that domain they become awkward.
"The object-oriented approach takes a step farther by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as 'objects.' (Of course, you will also need other objects that don't have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you're reading words that also express the problem. This is a more flexible and powerful language abstraction than what we've had before. Thus OOP allows you to describe the problem in terms of the problem, rather than in the terms of the solution. There's still a connection back to the computer, though. Each object looks quite a bit like a little computer; it has a state, and it has operations you can ask it to perform. However, this doesn't seem like such a bad analogy to objects in the real world; they all have characteristics and behaviors."
[From Bruce Eckel, "Thinking In Java," first published on the Web and still available free that way http://www.bruceEckel.com; it is also available in commercial CD-ROM and print versions.]
Fun Quotes to Ponder
Good programming is 99% sweat and 1% coffee.
Life is too short for long for loops!
This time it will surely run.
Beware of programmers who carry screwdrivers.
Bug? That's not a bug, that's a feature.
Caffeine: The ultimate debugging tool.
Hardware : The parts of a computer system that can be kicked.
I'd love to change the world, but they won't give me the source code!
Any non-trivial program contains at least one bug.
I love deadlines; I love the whooshing sound they make as they fly by.
Last updated: Wednesday, August 23, 2000