CPSC 311 Definition of Programming Languages
Winter 2016 Term 1
| Course Goals | Syllabus | Notes | Assignments | Piazza |
|
University of British Columbia, Department of Computer Science CPSC 311 Definition of Programming Languages Winter 2016 Term 1
|
Lectures are Mon/Wed/Fri 09:00–10:00 in DMP 110.
Tutorials are
In some lectures, we will write code on the fly and collaboratively. So, bring your active curiosity to class...and your computer if you can! If reading is assigned, do it beforehand (including trying the exercises!) or expect to be left 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 having started on (at least!) the current assignment. Those with laptops probably want to bring them, although the tutorial rooms also have desktop computers.
There is no formal textbook. We will mostly follow the lecture notes from the 2015W1 instance of 311.
If you would like to look at textbooks, consider these:
We will start out assuming you are familiar with the Racket (a descendant of Scheme) programming language. If you used DrRacket in CPSC 110, you'll need to refresh your memory. If you did not take 110, you have some catching-up to do, and 311 might not be an ideal course for you. Get started learning it immediately!
The following are helpful but not required for that:
Also see our Assignments page.
Most of our programming will be in Racket using the DrRacket environment. DrRacket is installed on the department machines, and is available for free download. See the Assignments page for more information on getting set up.
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. This policy allows us to release solutions quickly. 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.
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. A substantial fraction of your grade on programming assignments will be based on these qualities. In particular:
parse comes
to mind); for such functions, each
match case should fit on a screen.
We strongly recommend that all functions have unit tests that exercise the functions'...um...functionality. This is good software development practice but, more importantly, documents that you understand your code.
Good test cases:
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.
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 arranged by the course staff. (Acknowledge classwide discussions by just citing the event name, e.g. "tutorial 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 must 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 acknowledgment.)
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. Don't annoy this cat.
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 that hour, 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:
Plan ahead to schedule the face-to-face time this requires!
Most material will be distributed from the course web page http://www.ugrad.cs.ubc.ca/~cs311/. The Piazza site is for announcements and discussion boards. (We will not use Connect. Instead, we will distribute grades through the department's handback system used for exam scans.) You are responsible for keeping up with announcements in lecture and (at least once every "business" day) with the Piazza announcements.
Within the confines of the collaboration policy, use Piazza for everything. You can even broach private matters if you're careful to mark your question/post private. We all benefit from that! However, please e-mail the teaching staff (see Course Staff) when you need us.
You are expected 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 the midterm? This course is an odd duck. See Grade Calculation.)
Course components are weighted as follows:
| Assignments: | 40% |
| Midterm: | 15% |
| Final: | 45% |
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%.
Most assignments will have the same weight. We will drop your lowest assignment mark.
Weird stuff: Your calculated mark for the midterm will be the maximum of the midterm mark you earned and the final exam mark you earned. Thus, the midterm is effectively optional, and no special action is required if you miss it, but let me know if you miss for an excusable reason so that I can make a minor statistical adjustment that may get you a few more points. But write the midterm! This instance of 311 has no in-class quizzes, so the midterm will be your only chance to see what kind of questions the course staff like to put on exams.
Much of the course is based on prior work by Steve Wolfman, as well as Kris De Volder, Gregor Kiczales, Norm Hutchinson, Kurt Eiselt, and other previous course staff.
