Computer Science 60
Principles of Computer Science
Syllabus, Fall 2009

Is This Course for You?

Overall Course Aims and Objectives

• Aim 1: To give you a broad understanding of computer science as a discipline. Specifically:
  • Program in many different programming language styles and languages, e.g, Rex, Java, Prolog, JFlap
  • Construct finite state automata and Turing machines, show what they can and cannot compute, and understand the significance of these results
  • Describe how different programming styles lead to different approaches to problems.
  
  
• Aim 2: To help you design and develop programs to solve more sophisticated problems than those previously encountered. Specifically:
  • Understand the difference between data structures and abstract data types (ADTs) and build several data structures for a variety of ADTs
  • Design, implement, and test user-interactive programs in various languages.

Course Mission Statement

CS 60, Principles of Computer Science, provides the student with a broad overview of the science of computer science, at the same time providing sufficient depth in a number of key conceptual areas that are intended to serve both majors and non-majors well. These concepts include:

• Ways of thinking about solving computational problems
• Ways of creating computational solutions to problems relevant to a variety of disciplines
• How to think abstractly about problems, and how problems are solved by development of appropriate abstractions
• Views of information and data, how these are structured in the computer, and how they are manipulated to achieve desired ends
• Structural disciplines appropriate to computational problem solving, such as decomposition into sub-parts, iteration, and recursion
• Basics of logic applied to computation
• How to create a specification for a program and establish its correctness
• How programming languages are chosen for suitability to solving particular problem classes
• How layers of abstraction are developed in both hardware and software to make computational problem solving intellectually manageable

All of these concepts are important in both computer science and engineering. Programming in a variety of languages is used as a vehicle to demonstrate concepts. Language choice is not specifically made to match the often-changing demands of industry (though Java doesn't hurt!). Instead, we hope that each student gains experience in as wide a range of programming practices as possible. Underneath each assignment's language are conceptual points that are language-independent.

The overarching goal is that, at the end of CS60, you'll feel comfortable programming in any language -- even one you've never seen before! That is, you will be a savvy computational thinker, not dependent on any particular technology.

The choice of material in CS 60 is based on a combination of utility and accessibility. We want to serve non-majors with a deeper and broader course that builds from CS 5 with skills that will directly benefit the pursuit of any discipline. In addition, this course is a launching point for more serious study in the CS major itself. For example, CS 60 is a prerequisite for courses such as

• Computability and logic (CS 81)
• Program development and data structures (CS 70)
• Computer systems (CS 105)

Logistics

Class Times and Place:

• Section One Tuesday and Thursday, 1:15-2:30pm, Room TBA
• Section Two Tuesday and Thursday, 2:45-4:00pm, Room TBA

Course Homepage: http://www.cs.hmc.edu/courses/2009/fall/cs60

Instructor: Christine Alvarado
Office: Olin 1241
Phone: 909-607-0443
E-mail: alvarado AT cs DOT hmc DOT edu
Office hours: TBA, or by appointment (just send me an email--I usually can schedule something the same day)

Graders/Tutors (aka "Grutors") There are several grutors for this course whose mission in life (at least some of the time) is to help convey the wonder of CS 60! They will be holding regular hours in the Beckman CS labs in B102 and B105 (the link below has specific hours). They will also be grading your assignments (but not the exams). A complete schedule of tutoring hours can be found at http://www.cs.hmc.edu/courses/2009/fall/tutorhours.html

Help via E-mail: You can send e-mail to cs60help AT cs DOT hmc DOT edu with short questions related to homework. The grutors and instructors will be checking this e-mail address frequently, so it is a fast way to get your questions answered. For general questions, there are advantages to using cs60help, rather than sending e-mail to individuals directly: it's often quicker and it ensures that the entire course staff sees the question and subsequent answer, allowing us to be consistent about the way we answer questions.

Of course, if you have a question for one of us in particular, please do email us individually!

For more extensive help, please see Christine or a grutor in person. In particular, for help with the submission system (a forgotten password, for example), email Christine. For help with the computing system you're using -- your machine or one of the lab machines, your best bet is to seek out one of the many Mudders who know the system well!

Attendance

Optional Text

Assignments and Exams

You have three late days or "CS 60 Euros" that you may use at your discretion -- you don't need to tell us in advance. A late day allows you to turn in an assignment 24 hours late with no penalty. You may not use two late days on the same assignment. Late homeworks will not be accepted once these late days have been used. In cases of illness or emergency, you should contact Dean Cardenas to arrange an extension and have her contact one of us. CS 60 does not drop any of the assignment scores, however: assignments are by far the most important vehicle for learning the skills and concepts in the course!

In addition to weekly assignments, there will be one midterm exam and a final exam. See the exam schedule page for up-to-date details.

Grading

The weekly assignments will involve programming and, especially later in the course, some "paper and pencil" problems.

We will use guidelines in grading the programming assignments which will be approximately as follows:

• 70% of the points will be given for a program that meets the exact specifications of the assignment.
• 30% of the points will be given for good design, style, testing and robustness. Good design and style means, for example, that your program is divided into small logical functions, new classes are defined and used when appropriate, and the program uses efficient algorithms and data structures. Your program should also be robust in the sense that it handles minor aberrations in user input, though extensive input error-checking is not required unless so specified. Finally, the code must be readable and well-documented.

Your final grade will be a weighted average of your grades on each course component. Components will be weighted as follows:

• Weekly assignments: 60%
• Exams: 30% (10% for midterm, 20% for final)
• Participation: 10%

(define (score p)
 (cond
 ((>= p 0.95) "A")
 ((>= p 0.90) "A-")
 ((>= p 0.87) "B+")
 ((>= p 0.83) "B")
 ((>= p 0.80) "B-")
 ((>= p 0.70) "C range")
 ((>= p 0.60) "passing range")
 (else "we hope not to have to use this condition")))

Collaboration Policy/Pair Programming

• Both members of the pair must be at the same computer together while collaborating. One student will be the "driver" who controls the keyboard and mouse.  The other is the "navigator" who observes, asks questions, suggests solutinos, and thinks about sligthly longer-term strategies.  It is not permissible for one member of the pair to work on the code while his or her partner is not there participating actively.  
• The person typing at the keyboard must be swapped every 30 minutes. Please be vigilant about this.
• You must work with the same partner for the entire assignment.  You may switch partners between assignments.  (Sometimes this is required.  See below.)
• Only one partner needs to submit a pair programming file.  That file should include a comment on top of each submitted file that indicates that this was a pair effort and should give the names of both members of the pair. This will help ensure that the graders know where all of the files are. 
• Periodically, we will announce that its time to switch partners (sort of like in square dancing!). At that point, you may choose a different partner but may never go back to program with an earlier partner.
• To “learn the do’s and don’ts” of pair programming and to see pairs in action, view this entertaining video about pair programming from North Carolina State University: An Introduction to Pair Programming for Students

Now that you know the rules, here are some pair programming guidelines to help you get the most out of your experience:

• You should try to choose a partner whose skill level is similar to your own.  We realize this may be difficult to judge, but we've found that partnerships are most productive when pairs work at about the same level.
• If you and your partner have different experience levels, it is extremely important that the more experienced partner does not simply take over. Both experienced and inexperienced students will need to draw on their reasoning and problem solving skills. A more experienced partner may sometimes feel frustrated or slowed down by a less experienced partner, but the experienced partner still benefits from the teamwork in many ways. The less experienced partner’s requests for clarification often uncover flaws in an approach or solution; the exercise of providing a clear explanation solidifies and deepens the explainer’s own understanding and the teamwork and communication skills they gain have great value in both the academic realm and the job market.

  “My partner had never coded anything before so I was able to teach him
  a little bit about how it worked. The teaching bit helped me a lot with
   understanding the labs and passing the exams.”  – CS student 
  

  The less experienced partner may feel that questions hold the other partner back or that there is no benefit to participating actively, but pair programming studies show that paired work is consistently better than work the stronger partner does alone.  It is each partner’s job to understand the whole task; that means asking questions when necessary and answering them when possible.
• Pair programming is shown to help, not hinder, your successful completion of this course, so we strongly encourage you to use it. It is important that you understand the processes and expectations up front so you can gain the most benefit. If you are unsure of any of the aspects of pair programming and how it is implemented in the course, see Christine right away.

Whether you are programming individually or as a pair, there are a few important rules regarding cooperation. You are always welcome and encouraged to discuss approaches to solving homework problems with any classmate, the grutors, or Christine. You may not share any written/typed materials of any kind. In particular, you may not send or receive code that is related to this course by e-mail, on the web, from another person's file or printout, or in any other form. This rule applies to two people working as a pair with the following exception: The code may be sent by e-mail from one member of the pair to the other after the code is submitted for grading. Moreover, the pair may print out a copy of their code to work on together.

You may wonder if it is permitted to help a classmate (other than your partner if you are pair programming) debug a program and, in the process, look at their code. This is permitted, assuming that it is done with the intent of aiding your classmate and not with intent of gleaning code that might be used in your own program. Use your good judgement here. If you're not sure about what's appropriate, please talk to Christine.

All conduct in this course should be conducted in accordance with the Harvey Mudd Honor Code. If you are an off-campus student and unfamiliar with the honor code, please talk to Christine.