Lecture: Programming Language

Dear students:

Welcome to CS 430: Programming Languages. I have two primary computing interests: computer graphics and programming languages. They don't necessarily go together, but I like them both and I try to find ways to unite them so I can think about both of them.

I'm Chris, and you can call me Chris. Or Dr. Chris. Or Dr. Johnson. I'm still kind of new to this department and this part of the country. My family fled the Midwest because of the cold and other reasons that we can talk about some time. When I say family, I'm referring to my wife and four sons. I'll show you a picture so you know that you aren't the only thing I've got going on in my life.

Course Structure

My aim is for our weekly schedule to be predictable. On Tuesdays, we'll have lecture. I will talk. I will try to get you to talk. We'll write a fair bit of code together. On Thursdays we'll have a lab. Some labs will be on paper, some on a computer. If you have a laptop, bring it on Thursdays. Bringing a laptop on Tuesdays isn't a bad idea too, as we'll occasionally do short exercises together. However, please understand that we do our worst thinking at the computer and they eroding our ability to do focused think. I'm not very present when there's a soul-sucking screen on around me. Be present, and make it easy for others to be present.

The textbook for our is course is one that I am working on. I have chosen to write it not because I think I can do it better than others. I have other reasons: so that I myself can better understand the material, so that I can give it to you for free, so that I can distill the book down to the material that we'll actually cover, so that I can integrate exercises directly into the reasons, and so that I can improve the writing and the exercises semester after semester. The book is a work-in-progress, and I welcome your constructive criticism and error reports.

Each week will look something like this: read → front quiz → lecture → middle quiz → lab. Readings will generally be assigned on Thursdays. You will take a front quiz that accompanies the reading, all before Tuesday's lecture. If you like your score, you can keep it. If not, you can take a middle quiz and replace it. You don't have as much time for that one; it's due before Thursday. Then on Thursday you'll work on a lab exercise in teams. These labs will generally be due by Monday noon. I will grade them almost immediately and move on with my life. I will not accept late labs. Please don't contribute to the unsustainability of my profession. Your late work hurts you, me, and the other people I am here to serve. The quizzes aren't timed because I want to eliminate panic where I can.

We'll be discussing three languages throughout the semester: Ruby, Haskell, and Rust. They are chosen for their differences from what what you are used to. For each of them, we will have a programming exam.

I have long avoided taking attendance because it made me feel like a high school teacher. But I don't feel like things have been going well the past few years as our focus and commitment degrades. If I don't expect attendance, our whole mission seems sort of pointless. We're here to talk to each other about programming languages. So, while I'm not going to waste my time on attendance itself, I am going to assign in-class exercises each time we meet, both Tuesdays and Thursdays. These will be short and related to the course topics. Your participation will count toward your grade. If you complete the exercise correctly, you'll get four points.

We'll try one of these exercises on this first day. In the first round, you do not talk but think quietly to yourself. Once all have answered, you'll briefly confer with your neighbors. Then you'll answer again.

For programming assignments, we will have a single project with four milestones. You will build a spreadsheet application that runs in the terminal. Users will be able to write code in a cell just like in Excel or Google Sheets.

I push their due dates right up to the point at which I'm going to start grading. There won't be extensions. I have a job that does not end and easily destroys relationships and physical and mental health. If you find that you don't have enough time to complete something, please just accept the very appropriate consequence of not receiving credit.

The four project milestones will not have exact due dates. Instead I have scheduled six ready dates. These are dates at which you may turn in your work for a milestone. You will get credit if you've met all the requirements of the milestone. If you don't, then you can roll over to the next ready date. This is my scheme for accommodating emergencies, illness, breakups, breakdowns, and other trying times. I do not otherwise grant extensions because I'm a finite being.

You will turn in all your work on GitHub using a repository that I have made for you. I need to get you access to that repository. Also, we will use Discord for all communication. Please do not use email. If you send me an email, I will passive-aggressively wait one day before responding, and then my response will be, “Please ask on Discord.” Email is terrible because I cannot easily revisit the history of our conversation and because the university floods us with noise. Emoji is also easier on Discord.

Let's take a moment right now to make sure I have your GitHub and Discord usernames. Find the link on Canvas and submit these to me. Make accounts if you need to.

Terminology

In this class we're going to be talking about how programs are written by humans and read by machines. We're going to be using a lot of anatomical terms. Let's introduce some of those. With your neighbors, please answer these questions about program anatomy:

1. What is an identifier?
2. What is an expression?
3. What is a statement?
4. What is operator precedence?
5. What do you call x in void f(int x) { ... }? What do you call 5 in f(5)?
6. What is a token?

Quick Questions

The best way to learn a language is to learn it. A lot of tech learning materials start by enumerating all possible features—before you care about them. Let's not do that. Instead, here are ten small, quick, and representative tasks to solve in Ruby:

1. How do you print a value? How do you print a value in a human-readable form for debugging?
2. How do you collect a value from the user typing at the keyboard?
3. How do you print a statement about how one person ❤️ another if both names are passed as command-line arguments?
4. How do you loop through the numbers 1 through 10?
5. How do you access the last character of a string?
6. How do you instantiate a random number generator and generate a random integer less than 100?
7. How do you create an array of 20 zeroes?
8. How do you compute the larger of two numbers?
9. How do you print the string please some absurd number of times?
10. How do you return a value from a function?

In the next five minutes, find answers to as many of these as you can with your neighbors. Start at a random location in the list to increase the likelihood that each question is covered by someone. Don't try executing the code. Just type or write it somewhere. We'll walk through these together once the time is up.

Note on AI

Let's take a quick moment to discuss AI. It has some benefits: it can eliminate drudgery, it can give you ideas, and it has entered the lexicon of modern society. Knowing something about it is like knowing about Minecraft and Beyoncé. You can participate in more conversations. However, it also has costs. Not just the environmental ones, but also the opportunity ones. You are in school to develop yourself, not produce right answers. The exercises we complete in this class are designed for you to learn, and you will lose that opportunity if you head to an AI agent to get an answer. I view challenges like my children. I had them because I want to raise them. I don't hand them off to some “expert”.

The exams we complete in this course will be completed in-class through the LockDown browser. In the past I allowed folks to use any browser and IDE but not AI. They used AI anyway, and they ruined it for everyone else.

Here's my advice. Own your work. View exercises as training. Don't rob yourself of the opportunity to think. If stuff's hard, that means you haven't visited office hours enough. Use AI only after you've learned enough to identify when it's wrong.

TODO

Here's your list of things to do before we meet next:

See you next time, when we start looking at how to represent a program written in a language we don't know in a language that we do know.

P.S. It's time for a haiku!