Computer Science 42
Principles and Practice of Computer Science
Syllabus, Fall 2010

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, Python, 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 42, Principles and Practice 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

The overarching goal is that, at the end of CS42, 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.

Logistics

Class Times and Place:

• Tuesday and Thursday, 1:15-2:30pm, Thomas Garrett Hall, Room 201

Course Homepage: http://www.cs.hmc.edu/courses/2010/fall/cs42

Instructor: Christine Alvarado
Office: Olin 1241
Phone: 909-607-0443
E-mail: alvarado AT cs DOT hmc DOT edu
Office hours: Fridays 1-3pm, or by appointment (just send me an email--I usually can schedule something the same day)
Note: Outside of our office hours, I often can be hard to track down, but I am always available by appointment.  Please send me email to set up an appointment whenever you'd like to meet and can't make it to office hours.  Email is the best way to reach me; you can expect a reply within 24 hours during the work week.

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 42! 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/2010/fall/cs42/tutorhours.html

Help via E-mail: You can send e-mail to cs42help 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 cs42help, 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.

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!

Switching Courses

Attendance

Optional Text

• The CS 5 textbook: CS for Scientists and Engineers by Christine Alvarado, Zachary Dodds, Geoff Kuenning and Ran Libeskind-Hadas
• The optional CS 60 textbook: Computer Science: Abstraction to Implementation by Robert M. Keller. 

Assignments and Exams

You have three late days or "CS 42 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 Jacobsen to arrange an extension and have him contact me. 

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

Grading

This course is considered a first-year course, and is graded on a Pass/No Pass scale.  There are three graded components of this course, weighted as follows:

• Assignments (~100 points each x 12 = 1200 points)
• Exams (2x150 point midterms + 1x300 point final = 600 points)
• Participation (200 points total)

(define (score p)
 (cond
 ((>= p 0.97) "High Pass")
 ((>= p 0.70) "Pass")
 (else "We hope not to have to use this option"))

• You must independently pass each component of this course to pass the course as a whole.  This mean:
• A score below 70% on the homework or the exams will result in a grade of "No Credit"
• More than 5 unexcused absences will result in a grade of "No Credit"
  
• Borderline grades may be moved up or down based on exemplary or particularly poor performance in some aspect of the course.

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.

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.

Students with Disabilities

The college is committed to complying with the Rehabilitation Act of 1973 and the Americans with Disabilities Act of 1990 by providing reasonable accommodations for students who are disabled. Students requiring specific accommodations for a physical, psychological, medical or learning disability should contact the Dean of Students at (909) 621-8125. The Dean will review your concerns and determine, with you, what accommodations are necessary and appropriate. All information and documentation of disability is confidential.