Computer Science 60
Principles of Computer Science
Syllabus, Spring 2011

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, Racket (a.k.a. Scheme), Java, Prolog, and 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 especially made to match the often-changing demands of industry. However, 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:

• MW Section    Monday and Wednesday, 1:15-2:30pm, Galileo Pryne
• TTh Section    Tuesday and Thursday, 1:15-2:30pm, Beckman B126

Course Homepage: http://www.cs.hmc.edu/courses/2011/spring/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)

Instructor: Zach Dodds
Office: Olin 1255
Phone: 909-607-1813 E-mail: dodds AT cs DOT hmc DOT edu
Office hours: Fridays 2-4pm in the LAC lab, or stop by anytime!

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 LAC lab and/or the Beckman CS labs in B102 and B105 (the link below has specific hours and places). They will also be grading your assignments: complimentary comments about grutors are always welcome! A complete schedule of tutoring hours can be found at http://www.cs.hmc.edu/courses/2011/spring/tutorhours.html

Help via E-mail: You can send e-mail to 60help 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 60help, 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, Zach, or a grutor in person. In particular, for help with the submission system (a forgotten password, for example), email Zach. 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

On-time attendance at lectures is required in order to pass this course.
If you are ill and cannot attend or an emergency arises, please contact before the missed class if at all possible (or very shortly thereafter if not). If you need to miss class for any other reason, you must get permission in advance.

Optional Text

Computer Science: Abstraction to Implementation by Robert M. Keller. This is an optional and very vernable textbook for the course. This book is online and is also available in hard copy for purchase from Ms. Joyce Greene in the main CS office in Olin 1258. The book is sold at the cost of production with no profit to anyone at HMC. Old copies of the text are equally helpful -- and equally optional.

Assignments and Exams

There will be an assignment every week, with exceptions for breaks. Unless stated otherwise, homework is due each Monday at 11:59 PM. Since we use an automated procedure to determine submission time, if you submit even slightly after midnight, it will be recorded as being submitted the next day.

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 Jacobsen to arrange an extension and have him contact one of us. Note that CS 60 does not drop any of its assignment scores: 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 two midterm exams 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:

• 75% of the points will be given for a program that meets the exact specifications of the assignment.
• 25% 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 roughly as follows:

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

Final grades are computed with this Racket/Scheme code as our rough guideline*:

(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

For most of the programming assignments you will be permitted to "pair program" on some problems if you wish. The rules and guidelines for pair programming are as follows:

• 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 solutions, and thinks about slightly 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. Be vigilant about this!
• You must work with the same partner for the entire assignment.  You may switch partners between assignments.
• 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.
• To “learn the do’s and don’ts” of pair programming and to see pairs in action, trty out this fun 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 (and many, many of these have been done...) 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 a grutor or instructor right away.

Honor Code Details

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 instructors. 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 or Zach.

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 or Zach.