RFC: Programming Languages Course Reboot, 2026Published using Google Docs<br>Report abuseLearn more

RFC: Programming Languages Course Reboot, 2026<br>Updated automatically every 5 minutes

Why Programming Languages?

Why should anyone ever need to take a programming languages (PL) course? I have tried to open my PL course with this question every year. I feel like the ground under the question has changed, so I’m re-thinking the course from scratch to be able to answer the question afresh.<br>A Three-Legged Stool for Software Quality

What is PL? It’s the “material science” of software, which is one of the central and unique products of computing. It’s what ultimately enables computing to provide non-inert value to the world. So anyone producing it should have some sense of the materials they use for production.

It’s vital in general, even more so for course design, and even more so at Brown, to distinguish between programming languages, formal methods (FM), software engineering (SE). There is real overlap between these — they all care about producing quality products, helping humans, etc. — but they are not the same thing. I may write about their differences at greater length separately. But to me, PL is uniquely about the artifacts (languages) in which software is produced: their design, their properties, their affordances, and so on. FM often takes these as input, while SE treats these as part of a large tool-suite, but for PL they are uniquely outputs. (Language implementation I think of as categorically different: given a language, make it run. Of course, the desire or need to make it run in a particular way—fast, resource-constrained, in parallel, etc.—can have backward pressure onto the language design. Inasmuch as it does, I consider those parts to be part of PL, but the rest is downstream.)<br>Course Context

At Brown, at the undergraduate level, we already have courses in implementation (compilers), software engineering, and formal methods — in fact two of the last of these, one primarily proof-theoretic and the other model-theoretic [see design writeup]. So any PL class has to justify itself in the space left over after taking these excellent, established courses into account. At other institutions where, for instance, the PL course also doubles up as an implementation course, the constraints are different so the justification would also change.<br>Why Reboot?

Why does the PL course need a reboot? Until now, the focus of PL courses has been on programs written by humans. This means exploiting their strengths and guarding against their (many) weaknesses. It also means tackling aesthetic considerations such as syntax, and debating tradeoffs like the presence of types.

We are, however, entering a new world of machine-generated code. (Obviously, compilers already generated code. And that’s why we don’t have all but a small number of students spend time thinking about, say, the aesthetics of assembly languages.) It is a useful and important thought experiment (whether or not this will become the complete reality, at least in the near future) to ask, What if all code were generated by AI? (I’m intentionally blurring the lines between language models, agents, and other AI technologies du jour; think of “AI” as a stand-in for now for “agentic language models”.) How would that impact these courses?

It is abundantly obvious that this change greatly increases the burden on FM. It also clearly significantly impacts a good many parts of the SE process. But what is its impact on PL, as separate from those two? In particular, intellectual honesty demands that I ask the question, Do we need a PL course any longer? I’ve been asking this question for a while (e.g., on social media) and not gotten good answers—in particular, answers that don’t fall into the FM or SE buckets. So I’ve spent the past few months thinking about it, and finally have some thoughts.

I think we still need and want a PL course! Below I want to argue why, and present one vision for a form it can take.<br>Programming with AI

First, let us understand what AI systems do. We make a request (“prompt”) or sequence of them. These put some constraints on the generated code. But everything not pinned down, the AI is free to do. Indeed, we can make the exact same request several times and literally get a different program every time. All we know is that the code is trying to satisfy our request, using whatever checks we have provided to confirm it. That is, we are giving specifications, and leaving the AI with implementation flexibility. (Henceforth, I am going to gloss over the fact that our request can be bad and that the AI can misinterpret the request. Those are separate problems: how do we formalize what the request really is, which is mostly an SE problem, and how do we check it, which is mostly an FM problem. My concern here is that, even assuming a perfect request and perfect AI, each decision not pinned down is a degree of freedom given to the AI.)

I...