Welcome!

Welcome to CS340: Modeling for Computer Systems!

Agenda for today:

Professor introduction

I'm Alexa VanHattum–-you can call me "Alexa", "Prof. Alexa", or "Prof VanHattum".

This is my second year as an Assistant Professor at Wellesley. My research focus is the intersection of programming languages & computer systems, with a focus on applying lightweight formal methods (e.g., this course) to compilers for systems languages.

Before Wellesley, a version of this course (taught at Brown University by Tim Nelson) convinced me to pursue a PhD in the area. I spent time as a software engineer for Apple health, then completed grad school at Cornell.

Student introductions

(Names, pronouns, year, favorite programming project).

This is a small elective, and we want to all get to know each other!

Correctness exercise

Let's think about correctness in the context of programs you've written before.

Questions:

  1. How many people have worked on programming projects for a class? [Everyone]
  2. How many people have worked on programming projects not for a class? In what context? [Everyone]
  3. How many people have worked on programming projects that have had users other than yourself (it's ok if not! My answer to this question was no until my senior year of college!)? [Some folks]

Now I want you to step back, and think about how you knew what to program in each case.

In groups, discuss the following. Fill in your 2x4 sheet of paper: {class project, real users}
Write your logins in the top right.

A. How did you know what code to write? Did you know it fully ahead of time, or did you change what you were implementing as you went?
B. How did you know you were done programming?
C. How did you know if your design and code were correct?
D. If the code was incorrect, how would you find that out afterward? What were the implications of it being incorrect?

(Group discussion of these 8 cases). Main points: with course projects, you were given a specification of what to program in the form of instructions from your professor. You knew your program was done because you either (1) passed some tests or (2) manually examined the output/interface. You knew your code was correct because of how many tests it passed, manually testing, or the grade you got. The implication was a potentially bad grade.

With external users and software out in the world, a complete specification might never exist. You may know what to program your own tests, or information from clients, or trying to copy some external system, or just going off of vibes. You might be done when you pass your tests, reach a deadline, someone tells you they are taking over, or when you pass code review. For code correctness, you have to write your own tests in this case. Maybe you interact with Quality Assurance (QA) or other forms of additional manual testing. If code is incorrect: maybe it's caught in QA or a bug is reported. Maybe your users don't use your software how you expect, but it's minor. Or maybe users complain about it online or in your bug tracker. In extreme cases, maybe the code is used in medical software, or avionics, or autonomous driving, and someone's life is at risk.

This course focuses on improving the correctness of code by modeling the underlying systems. More on this next time!

Expectations

We went over the course website and syllabus, focusing on:

Mysteries

We considered a first mysterious computer program. More tomorrow!

Mystery 1

// What does this function do? How do you know?
int mystery(int x) {
    if (x % 2 == 0) {
        return x;
    } else {
        return x - 1;
    }
}