Spreadsheet

Dear Computer

Project: Spreadsheet

Spreadsheet

This semester you will learn more about programming language concepts by implementing your own spreadsheet application that runs in the terminal.

Like other spreadsheet programs, your spreadsheet presents a table of cells that the user fills with data and formulae to achieve various computational tasks. Users will enter into cells either code or plain text data like the string total: and the number 1.68. The code may contain cell references, variable references, multiple statements, conditionals, loops, and function calls. You will write an interface to display this grid and an interpreter to lex, parse, and execute code entered in a cell.

Unlike most other spreadsheet programs, your spreadsheet runs in the terminal. In an era of buttons and menus, this likely 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 would interfere with that.

You may implement your spreadsheet in Ruby, Haskell, or Rust. If you have a particular language outside of these three that you've been itching to learn, 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 designed this project after witnessing 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 your own spreadsheet 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 terminal spreadsheet is meant to be a project that leaves 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:

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 dates.

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. You can't, for example, submit milestone 3 without first having submitted milestones 1 and 2 on earlier ready dates.

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. TODO

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.

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 spreadsheet 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.

Recording and Submitting →