On this page:
1.1 Things to talk about
1.1.1 Course content
1.1.2 In-class assessments
1.1.3 Assessments and reassessments
1.1.3.1 Reassessment
1.2 Out-of-class assessments
1.3 Final examination → final presentations
1.3.1 Simple presentations
1.3.2 Skilled presentations
1.3.3 Evaluation Criteria
9.3

1 Mid-semester Changes🔗

The aim of this class is to make you better programmers and teach you how to think logically about computation.

To address this we are switching to a different style of assessment for this class, called standards-based grading (SBG). SBG centers around the idea of assessing your skills directly.

Skills are broken down into the following categories:

  • Intro + Functional programming (Weeks 1-2) – 4 skills

  • Runtime semantics (Weeks 2-4) – 10 skills

  • Type systems and logic (Weeks 5-7) – 5 skills

Skills have their own dedicated page that describes how skills translate into your grade: Skills.

IMPORTANT: My hope is that, instead of blasting you all with the rest of the course, you will have a solid foundation of programming languages that will make you:

  • Better programmers

  • Better debuggers

  • Introduce you to new ways of thinking about programs, namely, that all we are really doing when we write programs is playing a game. Each expression is a move you make to reach some desired outcome, and the rules of the game are defined by the language definition.

1.1 Things to talk about🔗

1.1.1 Course content🔗

  • The remaining lecture material is going to go over the same content as before in the first 7 weeks. The flavor will change: there will be a stronger emphasis on live-coding than me working on the blackboard. I will also come up with some notation for type-checking that is equivalent, but feels more "coder-friendly."

  • There will be a de-emphasis on some material (namely compilation and big-step semantics) and a re-emphasis on other material (small-step semantics). If you want to work more on compilation, there is a lot of interesting stuff in there and we can talk about it for your final project.

  • There will be a continued emphasis on the lambda calculus (untyped and STLC). The lambda calculus is a language that is "plait with less" so as you learn how to write and run plait code, you will implicitly learn the lambda calculus.

1.1.2 In-class assessments🔗

  • Classroom coding exercises will go away. They will turn into timed (10-15m) skills assessments. No laptops, no phones. If I see you looking at these you will be dismissed and I will discard your assessment.

  • "Turn and talk to a partner" is going to be a bit different: they will be shorter, but you will have time to reflect and share your answers with a neighbor, but crucially you will not make modifications to your skill assessments during this time. If I see this you will be dismissed from class. All pens/pencils must be down.

1.1.3 Assessments and reassessments🔗

You will always be able to retake an assessment. What does this mean?

1. The first part (75m) of class will be:

  • Lecture: 50m

  • Assessment on skills (did you pay attention?): 15m

  • Talk to a neighbor: 5m

  • Break: 10m

2. The second part (75m) of class will be one of:

  • Lecture day: A second lecture, followed by a skills assessment of your choosing (you can also take the one connected to the second lecture, but usually attention flags by this point in time).

  • Assessment day: You can retake any skill assessments you want to (I will have a big stack of papers of assessments to this point).

  • Presentation prep day: Details on presentations are below.

1.1.3.1 Reassessment🔗

Why are we allowed reassessment? They are not simply "do-overs", they are opportunities to show improvement.

You will not get to keep your assessments, they will not be shown over any digital platform. That said, you can review them during my office hours (in person) or schedule a time to review your submissions with me.

1.2 Out-of-class assessments🔗

  • Homeworks: We are not going over new material, so there won’t be any new homeworks.

  • Midterm: This is going to be handed back to you. I will convert this into practice problems for skills assessments.

  • Concept-checks: These will turn into "recommended exercises" or études. It will be up to you to follow along with these.

  • Presentations: To get a C or above, you will need to prepare a final presentation.

1.3 Final examination → final presentations🔗

Instead of a final exam, we’ll be doing final presentations. The final presentations have two modes (simple and skilled):

  • "Simple" presentations will follow the design recipe format and showcase a language you choose.

  • "Skilled" presentations will be a little more pedagogic (looking at more theoretic languages like Lam) and can be used to showcase more skill assessments.

1.3.1 Simple presentations🔗

A rough idea of a "simple" presentation would be a 10-15min presentation like the following:

  • Motivate a problem: How can a language provide memory-safety guarantees without requiring garbage collection? Give a bad example program in C.

  • Introduce the language: Rust is a strongly-typed language that has no garbage collection.

  • Explain functional examples: This is what it is like to program in Rust.

  • Show how your language satisfies the problem in your motivation: Show the equivalent bad example and how it doesn’t type-check.

1.3.2 Skilled presentations🔗

A rough idea of a "skilled" presentation would be a 10-15min presentation using a more pedagogic language I have shown in class. For instance:

  • ISWIM (a different style of interpreter)

  • Lazy evaluation (an alternative to call-by-value)

  • Simple multi-languages (a language of FFIs)

  • System-T (a language that allows for recursion but ensures termination)

The major difference between "simple" and "skilled" presentations (aside from the choice of language) is that "skilled" presentations also signal that you would like to do a code walk with me the week before finals to showcase particular skills (as an alternative form of skills assessment).

1.3.3 Evaluation Criteria🔗

TBD, but baseline is:

  • C-level answers: What does this feature do?

    Includes a concrete example and an accurate explanation of its behavior.

  • B-level answers: What problem does this feature solve?

    Includes a motivating problem and examples showing how the language addresses it, basically organized around the presentation recipe above.

  • A-level answers: How does the language design solve the problem?

    Includes an explanation of the underlying mechanism connecting the feature to the demonstrated behavior.