Supervisions in 2024/25

Michaelmas Term

The following timetable summarizes the supervision preparation work for the Michaelmas Term 2024 for Foundations of Computer Science. Please complete this work before attending the supervision for the relevant week and bring it to the supervision with you.

In the following, Week 1 starts on Monday 14th October.

Past exam papers can be found here. They are identified below using the format year-paper-question, so for example 2011-1-2 denotes Paper 1, Question 2 from 2011.

A small amount of web searching will no doubt lead to the discovery that solution notes for past exam questions are available. DO NOT READ THESE until AFTER the work is covered in supervisions. If you read them beforehand, then I reserve the right to (a) get VERY cross and (b) make you redo the question using a fiendish alternative approach of my own choosing. Why? My reasons are explained on the right-hand side of this page.

If you have been previously corrupted by Python/Java or anything else that emphasizes imperative over functional methods, then you will undoubtedly feel the temptation to use imperative methods when implementing in OCaml. Resist this. Functional methods are an addition to your toolbox that are well worth having, and you won't master them by avoiding them. In fact do not use any of OCaml's imperative methods unless either the questions tells you to, or you absolutely can't find a purely functional alternative.

Foundations of Computer Science

• Week 1

  Everyone: start attempting the questions in the handout for Foundations of Computer Science as early as you can. You should continue with these questions throughout the term.

  There are no supervisions in this week.

• Week 2

  Exam questions 1999-1-1, 2006-1-1, 2008-1-1.

  Note that these aren't representative of current exam questions because they predate the current exam format.

  In 2008-1-1 you may ignore Part (a), as it relates to the language ML, on which OCaml is based and which used to be used to teach this course. Having said that - don't ignore it completely. Give some consideration to what you think might be going on, and look up the difference between = and == in OCaml.

• Week 3

  Exam questions 2002-1-1, 2005-1-1, 1996-1-2.

  I suggest you also start to take a look at 97-1-5. This is generally regarded as challenging, and it may take a few supervisions for you to finish it, but you should definitely aim to do so before the term ends.

• Week 4

  Exam questions 2003-1-5, 2004-1-5, 2005-1-6, 2019-1-2.

• Week 5

  Exam questions 2020-1-1, 2020-1-2, 2010-1-1, 2010-1-2.

• Week 6

  Exam questions 2017-1-2, 2019-1-1, 2018-1-2, 2022-1-1

• Week 7

  Exam questions 2022-1-2, 2021-1-1, 2015-1-2, 2017-1-1

A note on ChatGPT and all the similar nonsense...

There are two ways of using such things. One is (only just) acceptable; the other ABSOLUTELY UNACCEPTABLE!

If you want to use such things for background research then by all means go ahead. But consider the fact that the quality of the output is extremely variable, and you're not necessarily in a position to judge its quality at this stage. Buy the course textbook and use it.

Do not under any circumstances hand in material generated by ChatGPT or similar as supervision work. I expect anything you hand in to me to be your own words and thoughts. If I find myself reading and commenting on anything auto-generated, then I shall consider it an offensive waste of my time. I regard this as a very good reason to Dean you. (And to take the view that you obviously won't mind if I use ChatGPT to provide feedback, rather than wasting my own time on it even further.)

Does that sound harsh? Consider the following: the College is paying a great deal of money to allow you to be advised by experts. (And yes, you're paying fees, but in fact they come nowhere near to covering the actual cost of your education.) We really don't want our time wasted. Why anyone should want to do this is a mystery to me, as supervisions are intended to be an entirely supportive process, having no bearing on the outcome of your degree, which you make the best use of by actively engaging in.

The big picture...

The aim long-term is for you to become excellent programmers, capable of writing reliable code that solves difficult problems. There is no short-cut to this: it is like learning to drive, and - as is the case with pretty much anything worth learning - you have to be bad at it before you can be good. Expect this and accept it from the outset, because being a good programmer takes practice.

The temptation to engage in “Programming by Stack Overflow” - that is, cutting and pasting someone else’s code from a web site - may be considerable; but avoiding the experience of thinking about a problem by way of several failures to solve it is depriving yourself of the most effective part of the process. One the the great things about Cambridge is that there is no actual disadvantage to handing in supervision work that you couldn’t finish: the supervision just gets more interesting as there’s lots to discuss, and - as the work is never formally assessed - there is no downside. You may feel that being unable to complete an exercise is in some sense embarrassing, or a “failure”; drop those thoughts immediately, because with anything challenging you will have to fail before succeeding, and this is just an accepted and necessary part of the process.

Ultimately, you need to perform in an exam where aids are not available. Ultimately, you might expect to be working on problems for which such aids are no help to you. We want to get you to the point where you are the expert; not someone winging it by hoping the answer lies elsewhere.

You should particularly avoid using LLMs to generate code for you. The reason for this is simple:

• Whatever you get can’t be relied on and will need to be debugged before use.

• One thing we know from decades of experience is that rattling off bad code, then relying on debugging, is a very bad way of producing good code.

The way to write good code is to attempt to make it correct first-time, because you have thought extremely carefully about what you’re trying to do. Ocaml is actually a great ally here, because the type system finds many problems for you before you get as far as running anything, Debugging should be what you do when something surprises you by failing; not something you expect to do because you don’t fully trust what you’ve written. Does this sound like hard work? Well, it’s hard to learn to do it this way, but in the long term it makes writing good code much easier.

(As an aside, your chances are that, as LLMs produce output reflecting their training set, you might well get solutions in Python that are more or less badly written and full of security holes, but getting anything like decent OCaml is going to be less likely as the training data is much more sparse.)

The even bigger picture...

The course appears to encourage the use of online notebooks to the extent that, according to the course web page, “Although not essential, you may find it convenient to install OCaml on your own computer.”

Notebooks are fine for beginners, and for small-scale projects. However real programming works at a different scale, and is often a collaborative process. I strongly advise you to get to grips with this fact from the outset, and the use of notebooks might not be entirely helpful:

• Install OCaml on your computer and learn how to use it. You can use it interactively; this has the same shortcomings as notebooks. Learn to use the compiler, which is what you’ll end up needing to do when you program for real.

• Find a good editor. Even better, a good Integrated Development Environment (IDE). It doesn’t really matter what - many of us will use Emacs or similar as a basic editor, and one or more IDEs such as Xcode or (if you’re a masochist) Visual Studio. There are many others, some specialized for a particular language. Many now find VS Code to be a good halfway point between the two and, if you don’t want Micro$oft spying on you, then VS Codium has had the surveillance removed.

• Learn to use git and GitHub. You will really thank me for this advice. They allow you to keep track of modifications to code, to try out new things while making it easy to revert later, to collaborate so that multiple authors can change code while merging the changes together later, and more. You will definitely need this for the Group Project in Part 1B, and you might as well learn to use it now. git and GitHub generally have build-in support in IDEs.

• Whatever the language, there will be frameworks, again often build into IDEs, to support systematic testing. There will be debuggers allowing you to trace execution step by step and more, there will be profilers allowing you to see which parts of the code are using the most CPU and memory, there will be support for tracking down errors in the use of memory (not an issue so much for OCaml, but definitely an issue when you get to C/C++ and so on).

• We have already suggested that you install and start to use some form of Linux. I will reiterate this advice here: it opens up a massive ecosystem of free tools for all of the above. The command-line is your friend!

All of the above have a learning curve, but the time saved long-term makes them vastly worthwhile, so try to find out as much as you can about them right now. Many will be covered in the course “Unix Tools” in Part 1B:

https://www.cl.cam.ac.uk/teaching/2425/UnixTools/

You can obviously take a look at the lecture notes for it now, and I suggest you use them as a starting point.