COMP 411 Principles of Programming Languages (Spring 2022) |
|
| Professor Robert "Corky" Cartwright | Dr. Zoran Budimlic |
| Department of Computer Science | |
| Rice University | |
| Canvas Remote Instruction/DH 1064, MWF 11:00am - 11:50am |
|
|
| Lecturer: | Robert "Corky" Cartwright |
| Email: | corky.cartwright at gmail dot com |
| Office: | Duncan 3104 |
| M-W 3-4pm and by appointment via Zoom |
| Chathma Abate | |
| Email: | caa8@rice.edu |
| Location: | Remotely via Zoom |
| Office Hours: | Tu-Th 4-5pm and by appointment via Zoom |
| Shaan Nagy | |
| Email: | san7@rice.edu |
| Location: | Remotely via Zoom |
| Office Hours: | As announced on Piazza and by appointment |
| TBA | |
| Email: | TBA |
| Location: | TBA |
| Office Hours: | Friday 4-6pm [16:00-18:00] |
Please try to arrive early during the scheduled office hours or let us know in advance that you will be coming to talk to us.
Course website: http://www.cs.rice.edu/~javaplt/411/
Course Piazza page: https://piazza.com/rice/spring2018/comp411/home
Please check the course Piazza page regularly for announcements. We also recommend posting questions to Piazza rather than emailing the staff directly.
The recommended reference book for this class is:
Another good reference is:
Please also look at the additional references and the language resources on the course website.
The purpose of the written homework is to deepen your understanding of the material introduced in class. The assignments will be posted on course website.
Generic Java 8 is the only language that is supported by the course staff for use in the assignments in this course.
Scheme and occasionally OCaml are used in examples given in lecture because they are more concise, but the same abstractions can be expressed in Java. Students are expected to write their programs in the essentially same "mostly functional" style as well-written Scheme or OCaml code. Mostly functional Java programs only mutate the fields of objects when there is a compelling reason. Static variables are typically used to represent constants. A thorough understanding of the composite and visitor design patterns is a prerequisite to writing good solutions to the course assignments (except for Assignment 1). For tutorial guidance on how to write interpreters in Generic Java, see Prof. Cartwright's Notes on Object-Oriented Program Design.
Java 8 is an industrial strength language that supports "programming in the large". If you have taken Comp 211 or 310, then you have already been educated in how to write Java programs in a clean OO style. Java 8 supports generics, the parameterization of classes and methods by type and performs type checking at the level of parameterized types -- eliminating the need for the most common uses of casting in Java. You are expected to use generics wherever they help avoid explicit casting. The Java 8 Development Kit (JDK) can be downloaded from the Java website at Sun Microsystems/Oracle. The current release of Java is Java 11, but Java 8 is still supported by Oracle and the course grading software uses Java 8. Later versions of Java includes some controversial changes which break many legacy Java programs including the DrJava IDE. The production IDEs, Eclipse and IntelliJ, both support later versions of Java, but many user communities have declined to adopt them because of backward compatibility problems.
The Java software ecosystem also includes several effective unit testing tools, most notably JUnit, which we expect you to use to test your Java programs. This tool is built-in to DrJava. DrJava includes a command on the "File" menu that generates test class templates for you. If you execute the test command by activating the "Test" button.above the Definitions Pane, DrJava will run all open unit test classes. DrJava encourages developers to use the old JUnit 3.8.1 format, but DrJava (together with IntelliJ and Eclipse) supports Java 4 as well. We only support course submission software on CLE@R machines.
We strongly encourage you to use pair programming on these projects, but we realize that scheduling constraints may make pairing impossible at times. Nevertheless, we expect both students on a team to understand every part of the project. Please employ good coding practices and document your programs extensively. Include a README file with your submission that explains how your project functions and how to invoke it. Test your program well! We will usually supply you with some test cases, but you are expected to add more.
Later projects heavily depend on earlier ones. Please make sure your projects are easy to use and extend (that's why good coding practices are important). For the first three projects, we will give you support code for the first project and solutions to the preceding project for the second and third projects. After that, you will have to use your own code.
The projects are due about every one and a half to two weeks. For an up-to-date schedule, please check the course website regularly. The assignments do not involve huge amounts of code, but the concepts behind them can be very deep. Please start early.
If you cannot find a partner, please email one of the teaching assistants or post to Piazza. Groups of more than two students will not be allowed.
There will be two written exams, one approximately in the middle of the semester and one during finals week.
To grade program functionality, we run our own unit tests against the API specified in the assignment description and mandated by the minimal test suite that we provide for each assignment. The specifications for Assignment 1 give detailed instructions on the expected form of internal and external documentation. These guidelines apply to all seven programming assignments.
With regard to the test suites (JUnit test classes) that you submit, we are primarily concerned about how well you cover the details of the contracts for each method in the mandated API. In our experience, conscientiously written unit tests that cover the the base, inductive, and corner cases for the inputs for each of the methods in the mandated API (used to grade functionality) typically receive full credit. In the parlance of software engineering, we use a "white-box" approach to testing your assignments.
Your grade in this course will be weighted 50% on performance on the projects, and 50% on the exams.
Your grade in this course will be weighted 47% on performance on the projects, 47% on the exams, and 6% on the written homework assignments.
Each student has seven (7) slip days that can be used for any homework assignments during the semester, exams excluded. An assignment that is submitted up to one day late will be accepted at the cost of one slip day. Similarly, an assignment that is submitted up to two full days late will be accepted at the cost of two slip days. A day consists of 24 hours; weekend days are included.
Note: You are limited to using a maximum of 4 slip days on a single project. This allows us to get projects graded and give you feedback in a timely manner. As an exception, you may use all of your remaining slip days on the final project (since you won't need the feedback for any later projects).
If a student has no slip days left, late submissions will not be accepted. If there are any extraordinary circumstances, please try to let us know in advance.
Recommendation: Save your slip days until the end of the term when the assignments are longer and more challenging.
You are encouraged to talk with the lecturer, the teaching assistants, and to any classmates that you choose about the homework. Such conversations are to help you understand the lecture material, the homework problem, and possibly even the key idea for the solution. However, you are ultimately responsible for writing your own solutions in cooperation with your partner. You must do all work jointly with your partner; this stipulation includes every line of code. You and your partner are not permitted to copy the solution from another source.
Posting solutions to assignments online is a violation of the honor code. Note that this includes making your source code available through publicly-accessible version control, such as a public GitHub repository. While we encourage you to use a version control system throughout this course, please remember to use a private repository.
If you have a general question, please post to the course's Piazza page. We will be monitoring it and by answering questions there, we can help the entire class. Since all students will be receiving your messages, you may also help each other, as long as you keep the Honor Code Policy outlined above in mind.
If your question is of a personal nature or reveales part of the code of your solution, please DO NOT post to Piazza (see Honor Code Policy). Instead, send an email directly to the course instructor (using the email address listed at the top of this page).
Students with disabilities are encouraged to contact the instructor or the teaching assistants during the first two weeks of class regarding any special needs. Students with disabilities should also contact Disabled Student Services in the Ley Student Center and the Rice Disability Support Services.
Solutions in Java are straightforward to write but Java is a very wordy language so they require many more lines of code than the corresponding code in Scheme or Ocaml. For this reason, most code fragments shown in class will be in Scheme.
Start working on the projects early. While they do not involve huge amounts of code, the concepts behind them are very deep. Make sure your approach is correct.
Code well. While we will provide solutions for the first 3 assignments, you will inevitably base later projects on code written in earlier assignments. Don't make it difficult to use your code later in the course.
Test well. There often are intricate usage cases for some language constructs.
Make sure you stay in sync with the lecture material. Come to class and ask questions. You might be able to solve the course projects without studying the course lectures, but the exams will get you.
Document your code and use good OO coding style (including the appropriate use of design patterns and Javadoc documentation). We will deduct points for bad style.
You can talk to the instructor, TAs, and even classmates about general concepts including program style. Ultimately, however, you have to write your own solutions. For example, you cannot share code with anyone outside of your programming pair. This is not the only rule, it was just an example. If in doubt, ask first!
For the projects, you should work in pairs and engage in pair programming for every part. Both partners have to know how each part of the program works. You may also work alone but this approach is more work and perhaps less rewarding. Talking about your code with a partner helps you understand it better.