Box
This semester you will learn more about programming language concepts by implementing your own coding challenge system based on closed-box testing. Instead of giving the user a text description of a function to implement, you present a mysterious box with parameter inputs on the left and the return value on the right. The user enters some values for the parameters and examines what value is returned. They keep entering values until they can form a hypothesis about what the box does. Then they code up their hypothesis using a programming language that you invent.
Your application will run in the terminal. In an era of buttons and menus, this sounds like a regression. We target the terminal instead of a graphical user interface for a couple of reasons: to give you more experience with the command-line and to avoid the bossiness of GUI libraries that dictate a program's architecture. We're here to learn about programming languages, and GUIs interfere with that.
You may implement your application in Ruby, Haskell, or Rust. If you have a particular language outside of these three that you've been itching to learn and haven't already used in a course, you may petition to use it by sending a message to your instructor. Make sure that your desired language has bindings for Curses or a similar library for drawing and handling user events in the terminal. Do not petition to use a language that you already know. Don't expect much support from your instructor if you choose a different language.
Your instructor has experienced many semesters of unmet learning objectives, stress preceding due dates, and the overspecification that comes from automated grading. The following features of this project are an attempt to address these concerns.
One project, four milestones. Building this application is no small endeavor. You've got to piece together a user interface, an interpreter, and a runtime that executes the user's code, all while learning a new language. The project has therefore been decomposed into four separate milestones. You'll enjoy the focus of building a single piece of software, but accomplish it in manageable stages.
No autograders. Learning that you are wrong is assumed to be a helpful thing. But not if that message comes rapid-fire from an external agent like an autograder. Discovering your errors at your own pace is much more enjoyable. Additionally, autograders only work when a project is thoroughly specified. When an instructor specifies a project in order to build an autograder, you lose the opportunity to do your own thinking about its design. This application is meant to leave room for you to make decisions. There are no autograders. Instead, for each milestone, you will record a video in which you reflect on your code and demonstrate that it works.
Full credit when done. Each milestone comes with a list of requirements that you must meet to receive credit. After many years of being a student, you've come to expect partial credit for partial work. Partial credit is nice way for you to salvage some points for something you didn't quite understand or have time to finish, but this practice has problems. For one, partial credit is based on pure fiction. If your instructor says A, B, and C are important, and you demonstrate only A, the instructor has to somehow decide what A is worth by itself. For two, assessing partial credit burns up time that your instructor would rather spend helping you achieve full credit. In this project, if a milestone asks you to complete A, B, C, that means they're all important. You won't get partial credit for only completing A. That sounds severe, but the good news is that you don't turn a milestone in until you've completed all the requirements. There aren't fixed due dates by which a milestone needs to be submitted. The policy is not no partial credit but rather full credit when done.
Submit on ready dates. You just heard that you'll submit milestones only when they are fully ready. Taking away due dates entirely is a recipe for disaster when life is full of other obligations that do have due dates. This project is therefore paced by a more flexible time constraint called a ready date, which is a scheduled day by which you may choose to submit a milestone. You have six ready dates across which you may scatter your submissions:
- Sunday, September 7
- Sunday, September 21
- Sunday, October 19
- Sunday, November 2
- Sunday, November 16 (if at least 80% attendance)
- Sunday, November 30 (if at least 80% attendance)
There are four milestones to submit and six days on which you can do so. No further extensions will be granted beyond these two extra ready date. The final two ready dates are only available if you have consistently attended class, as measured by your participation in Prompt exercises. Waiting for the semester's end to kick you into gear is a mistake.
Only one milestone may be submitted per date. You can't, for example, submit all four milestones on the last ready date. Milestones don't have to be completed by a particular date, but they do need to be completed in order.
If you try to submit a milestone that does not meet all the requirements, it will be rejected, and you will have to wait until the next ready date to resubmit. Egregious violations of this expectation will additionally result in the loss of a ready date.
You can miss any two of these dates and still submit all four milestones, but you shouldn't feel like you need to complete all four. Complete as many milestones as you need to achieve your learning and grade goals.
Flexible submission means that the project is on a different track than the rest of the activities of this course. You are used to programming assignments running in a tight association with the course content: there's a lecture about topic X, a lab about X, and then a programming assignment about X. Such synchronicity is nice, but its rigid schedule doesn't work well with humans whose schedules get interrupted by life events.
Read on for a specification of each milestone.