Topics
As its title suggests this module is meant to teach you how to programme. For this we need a programming language and I've chosen Racket as a language, mostly because it's easy to install, it has convenient tooling and good documentation, and there are good textbooks available for it. The techniques you learn should be applicable to other languages though and I will discuss the different design choices that other languages have made when relevant.
One problem with most introductions to programming is that they tend to focus on batch programmes, i.e. ones where all the input is available before any computation takes place. They're certainly important, but that's not the only programming paradigm and it's also important to learn how to write interactive programmes.
Another problem with most introductions to programming is that while they generally teach good practice for structuring programmes all of the examples tend to be very short programmes, where the advantages of structuring programmes well aren't apparent.
I'm going to try to address those two problems, and a few others, by making creating a single large interactive programme a central element of this module.
Text
For the middle part of this module we will be following How to Design Programs, Second Edition quite closely. It is available for free online. I certainly won't have time to cover everything in lecture but you are responsible for everything I don't explicitly say you're not responsible for.
For the first few weeks, before starting HtDP, I will give you a crash course of Racket, trying to cover the parts most relevant to the projects you will be working on. Most of that will be covered more systematically and in more detail as we go through the book, but I want to make sure you are able to get an early start on your projects. This part is largely based on lectures given by Kenichi Asai of Ochanomizu University for a similar module there.
No book is perfect, and not everyone learns the same way so you may want to supplement your reading of the main textbook with other sources. If so then there are two I would particularly recommend.
The shorter of the two is A Scheme Primer from the Spritely Institute.
The longer of the two is Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman with Julie Sussman. It is now somewhat out of date in some ways but it was for decades the textbook for the introductory programming module at MIT. It was written primarily with students in computer science in mind, which means the last two of the five chapters are probably not going to be of interest to you unless you're particularly curious about how programming languages are implemented rather than just how they're used. The first three chapters are of general interest though.
Both use Scheme, one of the main dialects of Lisp. Racket is an implementation of Scheme with very minor variations so almost everything in them should work in Racket.
Assignments
There will be weekly assignments. I won't collect or mark them but I will post solutions. They are meant to do a few things. One is to give you some indication of whether you've properly understood the material at a point where it's not too late to do anything about it. Another is to give you some practice for exam. I've written in due dates. Obviously since you won't be turning in the assignments there's no enforcement mechanism for those. I'd still encourage you to try to do the assignments by their due dates so you don't fall behind as the pace of the module is rather fast.
| Assignment | Due | Problems | Solutions |
|---|---|---|---|
| 1 | 1 October | view | |
| 2 | 8 October | view | |
| 3 | 15 October | view | |
| 4 | 22 October | ||
| 5 | 5 November | ||
| 6 | 12 November | ||
| 7 | 19 November | ||
| 8 | 26 November |
Exam
There will be single exam in the usual exam period, worth 70% of your course mark. The format won't exactly mirror the assignment problems, since a timed invigilated exam is necessarily different from an assignment where you no time constraints and can freely consult your book and notes and can test programmes. Doing the assignments will still be good preparation for the exam though.
Group Project
You will be divided into small groups for a group project, which will account for 30% of your mark. The following will be due by 17:00 on Thursday 19 November 2026:
- a working game written in Racket or one of its teaching sublanguages, uploaded to Codeberg.
- user documentation, clearly written and sufficient that someone could use all of the game's functionality without reading the code, in the same Codeberg repository
- developer documentation, clearly written so that someone who knows Racket but wasn’t involved in writing the code could maintain and extend it, in the same Codeberg repository
You will also have to give a short presentation on your project in the final two weeks of term.
The main things I'll be looking at when marking the projects are
- Would this be fun to play?
- Can someone who didn’t read your code or see your presentation but has access to your user documentation figure out how to play it?
- Can someone who didn’t read your code or see your presentation but has access to your developer documentation maintain and extend it?
- Is the code well designed at a macro level?
- Is that design well implemented at a micro level?
- Was the presentation well delivered and informative?
Of course your game actually needs to work. It also has to comply with all relevant university policies, laws and regulations, and software licenses.
I will ask everyone, anonymously, approximately how much each group member contributed. Hopefully in most groups the work will be evenly distributed but I will try to make sure no one gets a free 30% of their mark with little or no effort and that the other members of a group with a lazy member don't lose marks because of it.