Syllabus

We will not be publishing a day-by-day lecture schedule for this course. A day-by-day schedule doesn’t make sense given that some lectures will invariably run over or will need revisiting, and it’s hard to predict a priori which ones these will be. As a student, you should prefer a schedule that doesn’t force the professor to move on irrespective of whether or not you have understood the material well enough!

For the assignment schedule, consult the assignments page.

Staying Current

You are responsible for keeping track of all assignments and other material posted to the course’s newsgroup, brown.cs.cs173, and to its Web site. Please read the newsgroup regularly, because we will post notification of major changes to the Web site there.

Contacting the Staff

To communicate with us, please send mail directly to cs173tas@cs.brown.edu. We will direct our answers to the newsgroup if we think the questions and answers should be of general interest. Please don’t post directly to the course newsgroup or send mail to us individually in addition to mailing the alias listed above. We will remove your name from the questions if we think it appropriate (so you need not feel embarassed about asking “easy” questions), while also giving credit where it’s due.

Assignment Due Time

Assignments are always due at 2:00AM on the listed date. Why 2AM? Because we want you to attend class and to be reasonably alert when you do so. Past experience indicates that making assignments due at the start of class leads to a largely somnambulist audience that day. Those classes are fun for neither the student nor the professor.

Turning in Assignments

For programming assignments, you should use the electronic handin program. From the directory containing the files for the assignment you wish to hand in, execute

  /course/cs173/bin/cs173handin asgn-name
where asgn-name is specified in the table on the assignments page.

For written assignments, print or neatly write your solutions and put them in the handin bin on the second floor of the CIT.

Late Assignments

We will not accept late assignments. Assignments are often timed to be due for a classroom discussion on the assigned material because you can better follow a difficult topic if your struggles are fresh in your head. The class will sometimes even discuss solutions to the homework problems. Once we do this, we can no longer accept your solution.

If you really need or want to turn in an assignment late, you must get the professor’s permission to do this at least 24 hours before the assignment deadline. When we do accept a late submission, we will use this formula to compute your net grade:

(define (net-grade gross-grade number-of-penalty-units)
  (* gross-grade (expt 0.9 number-of-penalty-units)))
	

A penalty unit is a 24 hour period or part thereof after the due time. Even a minute after the due time incurs a penalty unit. So if you have permission to handin late, relax; sleep; attend class; and submit something polished later in the day.

Non-Team Project Collaboration

The purpose of assignments in this class is to help students learn key ideas in programming languages. Some (not all) assignments require a certain insight, or at least careful analysis, that is much harder to generate or perform than to merely replicate. We believe that doing it for yourself, though harder, is the only way to truly understand that insight or analysis.

Having said that, we also want you to be able to work with each other, learning from one another’s successes and failures. Therefore, we will permit you to discuss assignments with your classmates (in addition to the course staff). Note that you may only discuss possible approaches; you may not share answers, unless explicitly permitted by the assignment.

What’s an answer? We consider it to be any key insight, technique or piece of code without which the assignment seems difficult but with which the assignment becomes solvable or routine. This includes literal code and text. Obviously, this concept is impossible to define precisely, so you’ll have to use your discretion. If in doubt, ask us first before you share so you may avoid trouble later!

Please also read our message about honesty.

Team Project Instructions

This year, most of the assignments for this class will be done in teams (pairs, with a single triple if enrollment is an odd number). Our assignments tend to be short on code but long on thinking, so this will give you the opportunity to fully discuss a solution with another person. You will work with three different people over the course of the semester.

Programming in teams does not mean each person writes part of the code and the team simply pastes together these contributions. Each person is responsible for every line of code, documentation, etc. turned in. This responsibility includes getting or losing points for its quality, being able to explain it, and also incurring penalties in case of plagiarism or other violations. That is, all team members will get the same grade, and face the same sanctions: we will not partition credit or responsibility.

For team projects, you may not discuss the assignment with a student not on your team.

Since each team member must separately run the handin script for each programming assignment, we consider running the script the equivalent of signing the code. By handing in code, you acknowledge your responsibility for it in its entirety. Be sure your teammate has not changed or added anything without your knowledge prior to handing in.

We recommend that teams develop the software together using pair-programming techniques (of the form preached by Extreme Programming), though this is a suggestion, not a requirement. Pair-programming in a nutshell:

While this does require that you schedule times to work with your team, we think that pair-programming will increase your productivity and aid you in taking responsibility for all of your code.

Assignments are broken into groups. You will work with the same team for every assignment in a single group, and you may not work with anyone you worked with in a previous group. Once you have selected a partner please inform the course staff. If you are having difficutly finding someone to be your partner, please contact the course staff, and we will attempt to match you with another student.

Coding Style

We are very serious about requiring you to write clean, well-documented code. 20% of your grade for programming assignments will depend on your design, style, and comments. Since we expect that you document and test your code anyway, we think of this as giving you a free 20% for each assignment.

Not already knowing Scheme or having learned Scheme with a different style are not excuses for not following these requirements. We are using the coding style from How To Design Programs for this course.

Test Cases

All functions must have tests that exercise non-trivial cases. We require this to encourage good software development skills, but, more importantly, to force you to show us that you know what your code is supposed to do and that you’re not getting a correct answer by guessing. We will not give full credit to untested functionality, even if it is correct!

Good test cases:

When writing test cases, resist the temptation to make them massive and complicated (the “this must be testing something” thinking). Instead, write small, clean tests with clear purposes. While a mega-test can be good for exposing errors you didn’t think to write focused tests for, make sure that, should your mega-test fail, you figure out what aspect of it triggered an error and write a smaller test for that.

Codewalks

We will use codewalks, a common practice at software companies, to evaluate some of your programs. A codewalk is a presentation where you, the programmer, convince us, a jury, of specific properties of your program. You accomplish this by presenting your program and answering questions about it We are most interested in

Full Details…