| Instructor | Teaching Assistants and Graders | ||
|---|---|---|---|
|
|
|
|
|
Ravi Chugh |
Nick Collins |
Paul Lee |
Nathan Mull |
| M/F 3:00–4:00 JCL 345 |
See Piazza for days, times, and locations |
||
We will use Piazza for announcements and student Q&As. Make sure to sign up and check often! If you have a question, then almost certainly other students do, too.
For individual issues, you can contact the instructor and/or TAs via email. If you do, please say or enter the string "[22300]" in the subject line to help direct your call.
Grades will be based on programming assignments, written exams, and a course project according to the following weights:
You may use up to four late days total across all programming assignments. No additional extensions will be given once you have exhausted your late days.
Late days can only be used in discrete chunks. That is, one late day with respect to a time t is defined to be any amount of time in the range [1 second, 24 hours) after time t. Submission times, and any late days used, will be calculated using the timestamps of the most recent files you've submitted; you do not need to do anything anything special to use late days.
The programming assignments may naturally become more involved later in the quarter, so it's probably not a good idea to use all your late days on the first assignment or two.
Many assignments will include open-ended problems that will give you a basic specification of something to implement but will leave many of the details up to you. These problems will typically comprise a small portion of an assignment's grade, so you can decide how much effort and creativity you will put in. The goal is get extra practice with Elm and start brainstorming topics for the course project.
To award points for these problems, we will collect everyone's submissions and post a poll where all students will vote on their favorite submissions.
The course project will be your opportunity to design and implement something of your choice. You will find more details here, but generally the idea is to work in groups of one or two and build something fun and interesting in Elm that makes use of web programming and data structures in some way. Set your aims high, to contribute an interesting project to the Elm community!
The project will be split into several milestones, culminating in demos at the end of the quarter.
Late days cannot be used for any of the project deadlines.
We will have two in-class written exams, each of which will cover four or five weeks of material. The exams will be equally weighted.
The required textbook for the course is Chris Okasaki's Purely Functional Data Structures, which is a time-honored classic. Although we will not cover the book in its entirety this quarter, it will serve as a trusty reference on your bookshelf going forward... assuming you still have a physical bookshelf!
In addition to the textbook, we will use various other electronic references that will be linked to in the lecture notes. Because we will be doing our programming in Elm, the language documentation — including the Elm Guide, Syntax Reference, Core Library Documentation, and Examples pages — will become good friends of yours before long.
[The following is owed to Stuart Kurtz]
The University of Chicago is a scholarly academic community. You need to both understand and internalize the ethics of our community. A good place to start is with the Cadet's Honor Code of the US Military Academy: "A Cadet will not lie, cheat, or steal, or tolerate those who do." It is important to understand that the notion of property that matters most to academics is ideas, and that to pass someone else's ideas off as your own is to lie, cheat, and steal.
The University has a formal policy on Academic Honesty, which is somewhat more verbose than West Point's. Even so, you should read and understand it.
We believe that student interactions are an important and useful means to mastery of the material. We recommend that you discuss the material in this class with other students, and that includes the homework assignments. So what is the boundary between acceptable collaboration and academic misconduct? First, while it is acceptable to discuss homework, it is not acceptable to turn in someone else's work as your own. When the time comes to write down your answer, you should write it down yourself from your own memory. Moreover, you should cite any material discussions, or written sources (e.g. Note: I discussed this exercise with Jane Smith).
The University's policy, for its relative length, says less than it should regarding the culpability of those who know of misconduct by others, but do not report it. An all too common case has been where one student has decided to "help" another student by giving them a copy of their assignment, only to have that other student copy it and turn it in. In such cases, we view both students as culpable and pursue disciplinary sanctions against both.
For the student collaborations, it can be a slippery slope that leads from sanctioned collaboration to outright misconduct. But for all the slipperyness, there is a clear line: present only your ideas as yours and attribute all others.
If you have any questions about what is or is not proper academic conduct, please ask your instructors.