Course Staff
Ron Garcia (he/him) <rxg@cs.ubc.ca>
Office Hours: Thurs 3:30pm to 5:00pm in ICCS 387
Or make an appointment.
Sean Bocirnea <seanboc@student.ubc.ca>
Office Hours:
Fri 11:00a.m. to 12:00 p.m. at Demco Table 2
Fri 2:00p.m. to 3:00 p.m. at Demco Table 2
Exams
Midterms will be held in the Computer-Based Testing Facilities (ICCS 008 and 014).
Midterm 1: Wednesday October 18 & Thursday October 19, 6pm-8pm
Midterm 2: Wednesday November 22 & Thursday November 23, 6pm-8pm
(See Grade Calculation for info about missed exams)Final: TBD
Equity, Inclusion, and Wellness
The CS Department has a fantastic statement on Equity, Inclusion, and Wellness with a large number of resource links available, for example if you have concerns or needs for accommodation.
We hope that all of us in the CPSC 311 course also create a welcoming, respectful, inclusive, and positive environment. While CPSC 311 is unlikely to be stress-free (because learning is hard work, and hard work is often stressful), we also hope you will not find the course overwhelming. You may have ideas, questions, or concerns about creating such an environment in the course; we may make a mistake; or we may just plain do something wrong. If any of that happens, please let someone know. Talk to one of us on the course staff if you’re comfortable or to someone from the link above (or the Head or Undegraduate Associate Head of the department) if you’re not.
Lectures and Tutorials
Lectures are MWF 10:00–11:00 in DMP 310. Here is a tutorial schedule:
| Tutorial | Day | Time | Room | TA Staff |
|---|---|---|---|---|
| T1A | Mon | 14:00–15:00 | ICCS X350 | Lily |
| T1C | Tue | 15:00–16:00 | ICCS X351 | Sean |
| T1D | Tue | 16:00–17:00 | ICCS X351 | Jack |
| T1E | Wed | 14:00–15:00 | ICCS X350 | Lily |
We will write code on the fly and collaboratively in lectures. So, bring your active curiosity to class... and your computer if you can! Do the reading (which means trying the exercises!) beforehand or expect to be left quickly behind.
Tutorials will also explore course concepts hands-on and on the fly. 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 should bring them, although the tutorial rooms have some desktop computers.
Course Materials
Required Textbook: Programming Languages: Application and Interpretation, 1st Edition by Shriram Krishnamurthi.
If you’d like more information about the book or to pay for it (which I encourage you to do if you can afford it, or you may use it for free), see the PLAI website but DO NOT ACCIDENTALLY GET THE SECOND OR THIRD EDITION from there!
We will closely follow this text.
We will start out assuming you are familiar with the Racket (a descendant of Scheme) programming language. Get started learning it immediately!
The best resource for learning the systematic design approach that we use is the material for CPSC 110.
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 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,
Available online. This is sort of an introductory programming book, sort of a programming languages book, and entirely an amazing book.
Software
Most of our programming will be in the PLAI dialect of Racket using its DrRacket environment. DrRacket is installed on the department machines, and is available for free download. See Assignments page for more information on getting set up.
Assignments
People learn by doing, not listening. We will have regular assignments. The tentative term-long schedule is posted on the assignments page, including a schedule of assignment deadlines.
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. Thus, we can release solutions right away, which gives you a chance to get feedback when it counts. However, if you have extenuating circumstances, please contact your instructor immediately, preferably in advance, and we will try to handle the situation empathetically, reasonably, and respectfully. Submissions that do not 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. Your grade on programming assignments will depend on these qualities. 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 signatures.
If you need to use a new type, define a new datatype to represent it. Do not overload lists. ** Lists are but one kind of datatype, representing homogeneous collections of unlimited extent. That datatype will only sometime suit your problem at hand. You should define your own when appropriate.
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.
Examples
All functions must have examples that informally characterize the behaviour of a function, while also serving as unit tests once the function design is complete. This is good software development practice but, more importantly, documents that you understand the intended operation of your function. When reviewing code, we will not give full credit to functions that do not have sufficient examples to explain and exercise their functionality, even if the function body is correct.
Good examples:
- Demonstrate a single aspect of a single feature. Therefore, you will need multiple examples per feature to ensure its correctness.
- Actually check the program. This means not only executing the program but also checking the output to ensure it is what you expected.
When writing examples, resist the temptation to make them massive and complicated (so they “must be demonstrate something”). Instead, write small, clean examples with clear purposes. They are concrete documentation of your understanding of the problem, and not random test cases. That they test your code is secondary. A mega-example may expose errors in your code or your understanding, that you hadn't yet accounted for, but if your mega-example fails, figure out which aspect of your understanding falls short and write a clear and communicative example that addresses that aspect of your program.
Collaboration Policy (for assignments)
Our course builds on the department’s academic integrity statement with additional rules designed to create a professional but collaborative environment:
All assignments will be completed individually (but see our guidelines for interacting with classmates).
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:
Acknowledge all collaborators — by name and with a brief description of their contribution — in a
README.txtfile in multiple-file submissions or in comments at the top of your file/document in single-file submissions.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, shatter stone tablets) to avoid violating these guidelines because someone exploited your notes later.)
Collaboration with others may not happen over a computer.
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 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 arranged by the course staff. (Acknowledge classwide discussions by just citing the event name, e.g., tutorial T1A.)
Requisite Large Language Model (LLM) Statement You are discouraged from consulting a large language model, like any version of ChatGPT, or other chatbots, to complete your assignments. Doing so is unlikely to benefit your learning. However, this is not forbidden. Should you choose to do so, you must indicate this in your homework, and you must provide all prompts and responses used in any interaction related to your homework. This includes code completion IDE tools that interact with LLMs in the background.
(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-and-paste 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—but with great disappointment and annoyance—prosecute submissions that display these unusual properties.
Collaboration Recommendations
When you collaborate with a classmate, follow
the “Gilligan’s Island Rule”"Tiger King Rule""The Book of Boba Fett 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
IslandTiger KingThe Book of Boba Fett (no URL provided for your own sake). If you can
recreate your insights after such a mental emetic, you probably truly
learned.
Communication
We use several systems for communication:
Most material will be distributed via Piazza .
We also use Piazza for announcements and discussion boards. Key items in Piazza will be “pinned” to the top of your list of posts. Announcements are also available collected under “Course Information” on the Resources page. You are responsible for keeping up with announcements in lecture and (at least once every “business” day) on Piazza.
We use Canvas only to report grades. You can also find the code to join Piazza there!
We use Gradescope to submit assignments (and get feedback from the course team on those submissions).
Within the confines of the collaboration policy, use Piazza for asking anything at all! If you’re in doubt about whether something should be posted publicly, simply post it privately! We all benefit from that! However, you can also e-mail the teaching staff for matters of a personal nature (see Course Staff when you need us).
Missing Lectures, Tutorials, and Exams
You are required to watch all scheduled lectures, tutorials (live or recorded), and to write the final exam. If you miss the final exam, you must follow the procedures defined in the Academic Concession Policy. Please see the Grade Calculation section for how to document missing a midterm exam.
Grade Calculation
Course components are weighted as follows:
| Assignments: | 40% |
| Midterm 1: | 20% |
| Midterm 2: | 20% |
| Final: | 20% |
The instructor reserves the right to modify these weights (but does not anticipate exercising that right).
The Final exam is cumulative, covering the entirety of the course.
You must pass the average of the midterm and final exams (weighted corresponding to the components labelled midterms/final above) to pass the course. If you fail this average, your course grade will be no higher than 45%.
The weight of each assignment will vary depending on workload and significance. We will drop your lowest assignment mark.
Each midterm exam will have equal weight. The midterms this term will take place in the Computer Based Testing Facilities (ICCS 008 and 014). If you miss one, please have (but do not yet provide) documentation for the reason you missed the exam and e-mail or post privately on Piazza as soon as possible explaining why you missed it.
Acknowledgements
This year 311 is using Programming Languages: Application and Interpretation by Shriram Krishnamurthi as the course text. With Shriram’s kind permission, we are borrowing heavily from other parts of his CS173 course at Brown. Many elements of the course are also based on prior work by Steven Wolfman, Kris De Volder, Gregor Kiczales, Norm Hutchinson, Kurt Eiselt, Jana Dunfield, Felipe Bañados Schwerter, and other previous course staff.