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]
EXAM REVIEW SHEET [.doc]
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]
Matlab Hints
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)
Top 12 Things
Overheard of Klingon Programmers (a funny)
|
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. |