Course Staff

• Steve Wolfman <wolf@cs.ubc.ca>
  Office hours: Mon 1500–1630, Thu 930–1100, Fri 1330–1500 in ICCS 239
  Also available by appointment or come talk to me when my door is open!
  
  
• Jason Chou <f6k6@ugrad.cs.ubc.ca>
  Office hours: Thu 1100–1200 and 1300–1500 in ICCS 015

• Khamza (pronounced "hum-ZA") Davletov <khamza.cs311@gmail.com>
  Office hours: Mon & Wed 1000–1100 and Tue 1200–1300 in ICCS 015

• Maria Ivanova <maria.cs311@gmail.com>
  No regular scheduled office hours (Maria's kindly helping during crunch times)

Exams

• Midterm #1: Wed, 5 Oct, 1600–1800, DMP 310
• Midterm #2: Wed, 9 Nov, 1600–1800, DMP 310
• Final: Dec 9 1200–1430 in DMP 310 (see final exam time/location from UBC)

Lectures and Tutorials

Lectures are MWF 1200–1300PM in DMP 301. Tutorials are Tuesdays in ICCS 015 at 1100–1200 (T1A), 1300–1400 (T1C), and 1400–1500 (T1B).

We will write code on the fly and collaboratively in lectures. So, bring your active curiosity to class.. and your computer if you can!

Tutorials will also explore course concepts hands-on. The TA will work exercises with you, briefly summarize and answer questions about the assignments, and facilitate discussions. Tutorial material will sometimes supplement and sometimes reinforce lecture.

Come to tutorials prepared, having read assigned readings and attempted (or completed!) the current assignment. Those with laptops may want to bring them, although the tutorial room has desktop computers.

Course Materials

• Required Textbook: Programming Languages: Application and Interpretation by Shriram Krishnamurthi.
  
  We will closely follow this text. It's available for download, at zero cost, from the PLAI textbook website.
   
• In the first week of the course you will learn the Racket (a descendant of Scheme) programming language. Get started immediately!

  The following books/references are helpful but not required for that:

• How to Design Programs by Mattias Felleisen, Robert Findler, Matthew Flatt, and Shriram Krishnamurthi, MIT Press, 2001. (available online)
• Teach Yourself Scheme in Fixnum Days by Dorai Sitaram (available online)
• The Little Schemer by Daniel P. Friedman, Matthias Felleisen, Duane Bibby, and Gerald Sussman, MIT Press, 1996.
• The Seasoned Schemer by Daniel P. Friedman, Matthias Felleisen, Duane Bibby, and Gerald Sussman, MIT Press, 1996.

Also see the Racket exercises on our Assignments page.

• Another Optional Text: Structure and Interpretation of Computer Programs (2nd Edition) by Harold Abelson, Gerald Jay Sussman, and Julie Sussman, MIT Press, 1996.
  
  Available online. This is sort of an introductory programming book, sort of a programming languages book, and entirely an amazing book.
   

The CS Reading Room (ICCS 262) has all but the "Fixnum" book on course reserve. Ask the librarian on duty for them.

Software

Most of our programming will be in Racket using its DrRacket environment. DrRacket is installed on the department machines, and is available for free download.

On the department machines or after you've downloaded and installed DrRacket on your machine: in the Language menu select Choose Language then Use the language declared in the source, click Show Details (at the bottom), select the Output Style labeled print, and for Automatic #lang line type #lang plai.

(On a department machine, these settings may not persist across logins. In that case, the short version is to use the drop-down in the lower-left to choose Use the language declared in the source and type #lang plai as the first line of your source code.)

Assignments

People learn by doing, not listening. We will have regular assignments.

Read and adhere to the very open but absolutely required collaboration policy. See individual assignments for rules regarding teamwork.

No late submissions will be accepted. In extenuating circumstances, contact your instructor immediately, preferably in advance, and we may waive the assignment. Submissions that do not properly acknowledge collaborators and sources will receive zero marks and result in an official misconduct investigation.

Coding Style

A key theme of this course is expressiveness in programs. Thus, we require you to write code that is clean, concise, elegant, tested and appropriately documented. 20% of your grade on programming assignments will be based on these qualities. As is common in companies and large software projects, we use a specific coding style in this course: the coding style from How To Design Programs. In particular:

• All functions must have a purpose statement that fully explains, in a sentence or two, what the function does.
• All functions must have contracts.
• If you need to use a new type, define a new datatype to represent it. Do not overload lists. Understand the difference between lists and datatypes. Lists are homogenous collections of unlimited extent. In contrast, datatypes are heterogenous collections with a fixed number of members.
• As a general rule, all functions should be no longer than what fits on a screen. We will of course relax this for functions with a lot of pattern matching (parse comes to mind) and in that case recommend that each match case fits on a screen.
• Assume that your reader understands Racket/Scheme, so, in any inline comments, explain why you wrote the code, don’t explain what you wrote. We consider define-type to be self-documenting.
• Only use Racket primitives that we have taught in this course. For example, use first and rest instead of car and cdr. Likewise, use local instead of let.

Test Cases

All functions must have unit tests that exercise the functions'.. um.. functionality. This is good software development practice but, more importantly, documents that you grok your code. We will not give full credit to untested functionality, even if it is correct.

Good test cases:

• Test a single aspect of a single feature. Therefore, you will need multiple test cases per feature to ensure its correctness.
• Actually test the program. Testing means not only executing the program but also checking the output to ensure it is what you expected.
• Have a comment to explain their purpose.

When writing test cases, resist the temptation to make them massive and complicated (so they “must be testing something”). Instead, write small, clean tests with clear purposes. A mega-test may expose errors you haven't yet tested for, but if your mega-test fails, figure out which aspect failed and write a focused test for that.

It's a fabulous learning exercise to try to create a parsimonious test suite. Try doing it carefully and intentionally a few times, and you'll find yourself more able to do it automatically in the future. You'll also have a clearer sense of the core functionality you want from your code.

Collaboration Policy (for assignments)

• Where teams are allowed (see individual assignments for rules on team formation), students may work as they wish within their team (but see our guidelines). Except in extraordinary circumstances, a team makes a single shared submission and receives a single shared mark.

• Consultation with the course staff, the course's posted assignment handouts and lecture/tutorial notes, the textbook, and DrRacket's language help is unrestricted. (You should still acknowledge copied code and quotes.)

• All other collaboration, including consultation of physical or online resources, is encouraged subject to the following rules:
  1. Acknowledge all collaborators—by name and with a brief description of their contribution—in a README.txt file in your submission.
  2. Besides the collaborator names/descriptions you need for acknowledgments, you may not take any record away from the collaboration. Neither should you circumvent this rule through rote memorization or running-out-and-writing-stuff-down. (Destroy such records (e.g., discard annotated sheets of paper, erase whiteboards) to avoid violating these guidelines because someone exploited your notes later.)
  3. Collaboration outside your team may not happen over a computer. (Use a whiteboard instead!)

     Exceptions: (1) You may access online resources (like the textbook) from a computer, but treat them like written resources. Metaphorically, if the assignment were a closed-notes exam, the resources would be notes you can review before but not during the exam. (2) In cases when you "hit a wall" debugging, you may get brief debugging help over a computer, acknowledging as usual. However, your debugging helper may not type on or otherwise control your team's computer (because that's your job!), and both your team and your debugging helper's team are responsible if we find that one of you copied the other's submission or otherwise violated this policy. (3) You may take notes away from classwide discussions or group discussions that the TA arranges in your CPSC 311 tutorial. (Acknowledge classwide discussions by just citing your section, e.g., "T1A".)

(Can you access sites like Course Hero? Technically yes, but please do not, as such sites contribute little to your learning. If you ignore this advice, bear in mind that you must acknowledge the sites you use and may not "take notes away". So, you have committed academic misconduct if you use such a site but do not acknowledge it or if you copy material from such a site, regardless of acknowledgement.)

These rules encourage collaboration that helps you learn. Nonetheless, submissions that follow these rules will not display the unusual properties that, under stricter rules, suggest academic misconduct. Thus, we will vigorously prosecute submissions that display these unusual properties.

Collaboration Recommendations

When you collaborate outside your team, follow the "Gilligan's Island Rule" (thanks to Larry Ruzzo, who inspired the whole collaboration policy): After discarding notes from a collaboration, spend at least an hour doing something at least as mindless as watching Gilligan's Island. If you can recreate your insights after such a mental emetic, you probably truly learned.

When you work with your team, work together rather than "cutting up the problem" and working separately. (We may use code reviews and will use exams to enforce individual accountability for assignments.) To increase productivity and improve learning, use pair-programming techniques (of the form preached by Extreme Programming). Pair-programming in a nutshell:

• Both programmers share a single computer, monitor, and keyboard.
• One person is the typist, the other watches what is being typed and critiques it.
• Programmers switch roles at regular intervals. (Note that this is also good for preventing RSI!)
• Both programmers jointly own every single line of code, regardless of who typed it.

Plan ahead to schedule the face-to-face time this requires!

Communication

Most material will be distributed from the course web page http://www.ugrad.cs.ubc.ca/~cs311/. The Matygo site is for announcements, discussion boards, grade distribution, and a few restricted access handouts (though as we explore the system, we may decide to use it more). You are responsible for keeping up with announcements in lecture and (at least once every "business" day) with the Matygo announcements.

Within the confines of the collaboration policy, use the Matygo discussion boards for everything except private matters (e.g., discussions about marks). We all benefit from that! However, please e-mail the teaching staff (see Course Staff) when you need us.

Missing Lectures, Tutorials, and Exams

You are required to attend all scheduled lectures, tutorials, and the final exam. If you miss a lecture or tutorial, catch up. Use (at least) the website, friends, the discussion boards, and office hours to do so. If you miss the final exam, you must follow the procedures defined in the Academic Concession Policy.

(What if you miss a midterm? This course is an odd duck. See Grade Calculation.)

Grade Calculation

Course components are weighted as follows:

Assignments:	30%
Midterms:	30%
Final:	40%

The instructor reserves the right to modify these weights (but does not anticipate exercising that right).

You must pass the final exam to pass the course. If you fail the final, your course grade will be no higher than 45%.

Each assignment will have equal weight, and we will drop your lowest assignment mark.

Each midterm exam will have equal weight. Weird stuff: Your calculated mark for each midterm will be the maximum of the midterm mark you earned and the final exam mark you earned. Thus, midterms are effectively optional, and no special action is required if you miss them, although do let me know if you miss for an "excusable" reason rather than just choosing not to come. But write the midterms! (Nu, it couldn't hurt.)