The University of Michigan, Winter 2021
Survey of programming language features and paradigms, with a focus on how to effectively use them. Introduces common features for structuring program execution, data, and resource management. Exploration of programming paradigms including imperative, functional, object-oriented, and declarative paradigms, as well as advanced techniques such as metaprogramming. Students will gain programming experience in large projects that incorporate these paradigms and techniques.
| Amir Kamil <akamil@umich.edu> |
Due to COVID-19, EECS 398 will be remote this semester. You can complete the entire course from anywhere in the world.
All dates and times in this course are with respect to Ann Arbor (Eastern) time.
Lectures are offered live over Zoom, and recordings will be made available. We do not take attendance in lecture.
| MW 1:30 - 3:00 PM ET | Kamil Zoom Lecture |
Discussions will be held remotely using Zoom. You may attend any discussion section, even if it's different than your registered section. We do not take attendance in discussion. We are planning to make recordings available.
Projects and homework assignments will be completed either alone or in a partnership and turned in to an autograder.
Exams will be completed remotely using a web-based exam platform. Expect scheduled, timed midterm and final exams.
Office hours will be held via video conference, both one-on-one and in groups.
Make sure you have a laptop consistent with CAEN recommendations.
Test your internet connection with the U-M Custom Speedtest website and make sure it meets the minimum requirements for any UM service. You'll need more bandwidth if there will be multiple simultaneous users in your household.
Resources for help with computing equipment:
The main goal of this course is to become better programmers, by learning about common programming-language techniques and paradigms and developing significant programs that incorporate these techniques. We expect that everyone will come out of the course with the background needed to quickly learn a new language or programming system and then effectively write code in that language or system. Regardless of where you end up, you will likely have to learn a new programming system sooner or later, and our goal is to help you develop the skills to succeed at that.
While we will be using several languages, learning different languages is not our main purpose here. Instead, we will explore the fundamental features, concepts, and paradigms of programming languages. Gaining the ability to learn a new language quickly and to make better use of its constructs is much more important than memorizing the syntax of several different languages. To analogize with spoken languages, we are more concerned with linguistics than with specific languages.
The main themes of the course are:
Please refer to the course schedule for a full list of topics that we plan to explore.
Passing EECS 281 is all you need to be prepared for this course. Everyone who has made it through EECS 281 is able to complete EECS 398 successfully.
Prior experience in Python, Scheme, or Prolog is not required.
We use a set of course notes developed specifically for this class. Required reading assignments are listed on the schedule. We encourage you to read them in advance of lecture, but it's fine if you read them afterwards instead.
If you would like an additional resource, we recommend Programming Languages: Principles and Paradigms by Gabbrielli and Martini. It is available in print form and DRM-free electronic form here.
The course website links to all course resources. Please check the website regularly for updates.
We use Piazza as a collaborative discussion forum for the course, and it is the best place for technical questions, project updates, and policy questions. Please do not publicly post your code; if you have a specific question about your code, please make a private post instead. Please search the forum before posting; duplicate questions create extra work for everyone, and they make it harder for others to find answers to their questions.
eecs398w21@umich.edu reaches the full course staff.
Please reach out to us using our individual email addresses for confidential matters.
We publish important announcements and grades on Canvas. Please ensure that you can receive Canvas announcements.
We will have one midterm and one final examination. Exam dates are on the course website. Make sure to verify you can attend both exams before registering.
We are only capable of providing alternate exams for documented conflicts due to time zone, a religious holiday, or university-affiliated athletics.
We will also work with you if you have SSD accomodations.
We will post forms for requesting alternate exams and letting us know about SSD accommodations in the first few weeks of the semester. To ensure that we can accommodate requests, we will announce a deadline for submitting the forms.
In addition to lectures, we will hold discussion sections each week. While the main goal of lectures is to introduce new concepts, discussion sections are intended to give you some hands-on experience with exercises, as well as help you get started on assignments. Though attendance is not required, you do need to be familiar with the material covered in discussion.
We will have five major programming projects and four smaller homework assignments. These assignments will give you hands-on, in-depth experience with the concepts covered in the course.
We encourage working with a partner on the assignments that allow it. Coding is a collaborative endeavor, and working with another person helps you both learn from each other. Past data from several courses (EECS 280, EECS 490) have shown that partnerships do better on projects than people who work individually.
However, if you do wish to work on your own, we will support that as well.
Project 1 must be done individually, since it is intended to ensure that everyone is up and running in Python. You may work either alone or in a partnership for the remaining projects and for any of the homework assignments.
A partnership is composed of two students. If you work in a partnership, you and your partner must both be registered for EECS 398 this term (any section). Partnerships are not allowed with anyone outside the course.
For those retaking the course (either as EECS 398 or EECS 490): if you submitted an assignment in a previous term, you cannot partner on that same assignment this term. This is to ensure that both members of a partnership contribute to all aspects of a solution, as required below.
You may change partners between projects. Changing partners during a project is not allowed. In exceptional cases, you may request partnership dissolution by sending email to us. If we grant a dissolution, both partners may use previously shared code and both partners must work alone on the remainder of the project. We want both partners to have an opportunity to complete the project, so we do not generally grant dissolutions close to a deadline. Please let us know early if you run into partnership issues, and we will help you in resolving them.
For some assignments, we may require you to work in the same partnership as a previous assignment. This is the case when an assignment reuses work done on the prior assignment. Refer to the assignment specifications for when this applies.
To work in a partnership, register your partnership on the autograder prior to the first submission for an assignment. The autograder will then treat you and your partner as a unit, and a submission from one partner counts for both.
We require partners to collaborate on all aspects of a solution. This ensures that both partners meet all the learning goals of the projects. We do not allow splitting up the project and working on separate parts individually. For both grading and honor-code purposes, both partners are held equally responsible for anything submitted on behalf of the partnership.
We use a web-based autograder to provide early feedback, and to evaluate correctness and programming practices. We also hand grade some assignments for programming practices and test cases. This allows us to provide better feedback than we can get from automated tools.
Before the deadline, we allow 3 submissions a day per partnership, with the count resetting at midnight Eastern Time. After each submission, the autograder shows the results of the public tests released with the project.
After the deadline, the autograder shows the results of private tests, which are usually more thorough than the public tests.
The final assignment score is a combination of public tests, private tests, and hand grading. We use the submission that received the combined best score on the public and private autograder tests. If multiple submissions share the best score, we grade the last such submission.
For hand grading, we grade the same submission that is used to determine your correctness score -- it is important for programs to simultaneously have the correct behavior and be readable and maintainable by following good practices. Make sure to always use good programming practices. This will ensure that you do well on the hand grading, even if we end up grading a submission you did not expect.
Several projects have optional checkpoints that entail meeting a specific correctness threshold in advance of the final deadline. These are inteded to get you on track for completing the project on time. Refer to the project specifications for details.
You may develop your programs on any platform you like. However, use only standard features and libraries of the programming environment for an assignment (e.g. Python 3.9, Scheme R5RS, and C++17).
Since the autograder is the system we use for grading, make sure that your code works correctly on the autograder. In particular, submit before the due date so that you have the opportunity to fix any errors.
Tips for doing well on the assignments:
Tips for assignment partnerships include:
While we do not consider grades to be the metric for success in this course, we do have to assign grades at the end of the semester. We will do so based on scores from homework assignments, programming projects, survey participation, and two exams. The tentative point distribution is included in the following table. It is not likely that this will change, but circumstances might occur that would make changes necessary (see the Revisions section for how we handle changes).
| Assignment | Weight |
|---|---|
| Homework assignments (all equal weight) | 16% |
| Projects (P1 5%; P2-P5 10% each) | 45% |
| Midterm exam | 19% |
| Final exam | 19% |
| Course surveys | 1% |
| Total | 100% |
There are no letter grades for individual projects or exams. The final course letter grade is based on the total weighted score earned. Passing EECS 398 requires meeting the following criteria:
These thresholds are to ensure both sufficient hands-on experience with the core concepts through successful completion of the projects, and sufficient understanding of the material as reflected by individual performance on the exams. We may adjust thresholds in your favor.
After computing the total weighted score, we use these ranges to assign letter grades, as long as the passing thresholds for projects and exams are met. Each range is inclusive at the bottom and exclusive at the top; for example a score of 89.9% is a B+ and a score of 90.0% is an A-. We do not round scores. We may adjust thresholds in your favor.
| Total Weighted Score | Letter Grade |
|---|---|
| 0 - 50% | E |
| 50 - 65% | D |
| 65 - 74% | C |
| 74 - 78% | C+ |
| 78 - 82% | B- |
| 82 - 86% | B |
| 86 - 90% | B+ |
| 90 - 94% | A- |
| 94 - 100% | A |
If you score 65% overall, and your weighted exam average is above 50%, and your weighted project average is above 65%, you will pass the course with a C or better.
There is no guaranteed threshold for an A+. A grade of A+ is only awarded for exceptional work at the discretion of the instructors.
Please note:
A final thought on grades: we assign grades solely based on scores on the course assignments. We do not consider grades to be a value judgment. We value everyone's participation, and we treat everyone with respect and consideration regardless of what scores or grades they obtain.
We typically set deadlines for assignments to be at 8pm Eastern Time on the due date. This allows us to support the assignments until the deadline. We also do not want to encourage working late into the night, since that can negatively impact your well-being and your work the following day.
We understand that people are spread out over different time zones this semester. Unfortunately, we do have to set a deadline somewhere, and we have decided on Ann Arbor time as that is what we can best support.
We do not accept late submissions. Assignments turned in late for any reason will receive a zero, unless we have worked out an extension in advance. We consider extensions for the following reasons:
Some components of assignments and exams are graded by hand. Request a regrade via the mechanism announced for the assignment. We accept requests only to correct grading errors, not disagreement with the rubric. Your score may go up or down.
We do not accept regrade requests for automatically graded components of assignments or exams.
In all cases, regrade requests are due no later than 7 days after a grade is released unless a shorter deadline is specified.
We encourage collaboration in EECS 398, especially on concepts, tools, specifications, and strategies.
All work you submit must be your own or your partnership's. Collobaration must not result in code that is identifiably similar to other solutions, past or present.
| Encouraged Collaboration | Unacceptable Collaboration |
|---|---|
| Discussing high-level design strategies, e.g., helper function organization or data structure choices | Walking through an important piece of code step-by-step, sharing pseudocode, sharing comments |
| Helping others understand the spec or project nuances | Providing your code as a reference |
| Helping someone debug | Debugging someone's code for them |
| Explaining a compiler or runtime error to someone | Fixing a compiler or runtime error for someone |
| Discussing test strategies | Sharing test code to verify someone else's design, even if test cases are not submitted |
| Brainstorming edge cases for testing | Discussing specifics about what test cases are on the autograder |
| Sharing code provided by the course staff | Copying code in whole or in part, even if the code is modified Writing original code for someone else, or having someone else write your project |
| Looking at small snippets of someone else's code to understand concepts | Sharing your code in a way that could be copied, e.g., sending code over email or taking a picture of code |
These rules continue to apply even after the course is over.
If you are unsure about what constitutes an Honor Code violation, please contact the course staff with questions.
If you are retaking the course, you may reuse your own code, provided it was wholly written according to the rules outlined in this syllabus. It is possible for us to miss an Honor Code violation in a previous term, but catch and report it when the code is reused.
You may not make your code publicly available in any form, for example in a public GitHub repository or personal website. These rules continue to apply even after the course is over.
As part of our own responsibilities under the Honor Code, we have to report suspected violations to the Engineering Honor Council. To identify violations, we use both manual inspection and automated software to compare present solutions with each other, with past solutions, and with code found online. The Honor Council determines whether a violation of academic standards has occurred, as well as any sanctions. Read the Honor Code for detailed definitions of cheating, plagiarism, and other forms of academic misconduct.
Here's what you can expect if you are reported for an Honor Council violation:
If you have a pending Honor Council case at the end of the term, you receive an "I" (incomplete) grade until the case is resolved. We will send you a grade projection via email to help with planning. Your grade is updated once the case is resolved.
We encourage you to attend lectures and discussion sections synchronously if possible. When participating in remote lecture, discussion, or office hours, please keep yourself muted unless you are actively talking to the other participants, so as to avoid background noise that can be distracting.
We may record course lectures and discussions and make them available to other students to facilitate their participation in this course. If you do not wish to be recorded, you can keep yourself muted during class sessions. We also record chat transcripts and make them available to students in the course. If you would like to ask a question in chat but do not want it in the recording, you can send a private chat message to the instructor, which will not show up in the recording.
Students may not record or distribute any class activity without written permission from the instructor, except as necessary as part of approved accommodations for students with disabilities. Any approved recordings may only be used for the student’s own private use.
If you think you need an accommodation for a disability, please let us know during the first three weeks of the semester. Some aspects of this course may be modified to facilitate your participation and progress. As soon as you make us aware of your needs, we can work with the Services for Students with Disabilities (SSD) office to help us determine appropriate academic accommodations. SSD (734-763-3000; http://ssd.umich.edu) typically recommends accommodations through a Verified Individualized Services and Accommodations (VISA) form. Any information you provide is private and confidential and will be treated as such.
As indicated in the General Standards of Conduct for Engineering Students, we are committed to a policy of equal opportunity for all persons and do not discriminate on the basis of race, color, national origin, age, marital status, sex, sexual orientation, gender identity, gender expression, disability, religion, height, weight, or veteran status. Please feel free to contact us with any problem, concern, or suggestion. We ask that all of us treat each other with respect.
We all experience stressors that can impact both our academic experience and our personal well-being. These may include academic pressure and challenges associated with relationships, mental health, alcohol or other drugs, identities, finances, etc.
If you are experiencing concerns, seeking help is a courageous thing to do for yourself and those who care about you. If the source of your stressors is academic, please contact us so that we can find solutions together. For personal concerns, U-M offers many resources, some of which are listed at Resources for Student Well-being on the Well-being for U-M Students website. You can also search for additional resources on that website.
We are always working hard to improve the course, our teaching methods, and the curriculum as a whole. Often, this requires using your class work for research purposes. However, we will not publish any identifying information about you or your work. For example, we may use anonymized student assignments to design algorithms or build tools to help programmers. Or we might survey responses to help us improve the course and better understand instructional techniques. If you wish to opt out, contact the course staff (eecs398w21@umich.edu) at any time up to seven days after final grades have been issued. Opting out has no impact on your grade in any manner.
While we try to do our best to plan ahead, unfortunately, sometimes circumstances do arise that motivate a policy change. When this happens, the change will be announced, and this document will be updated with the new policy.
We wish you the best of luck this semester! We will do our best to make it a positive and meaningful experience, and we hope that the course helps you in your future endeavors.