CM50262: Functional Programming
Functional Programming is a compulsory unit in the Bath MSc Computer Science course. The course covers two topics: Haskell and Lambda Calculus. I would say it's 65% Lambda Calculus and the rest Haskell.
We had two lectures a week and a two hour lab session with the TAs. Initially the course felt easy to me because I had learnt some Haskell and Standard ML before starting my degree. Also many of the concepts in functional programming have made their way into mainstream languages that they didn’t feel entirely new. Things such as higher-order functions, list comprehensions and anonymous functions.
Lambda Calculus is where the fun actually began. Initially I kept comparing it with Haskell, wishing there was a interpreter for it that told me what errors I am making as I write the lambda terms. Over time it got easier as we learned the different rules to write them. Implicit brackets was the biggest thing tripping me up at start and I remember thinking that this course would be at least 30% easier if the brackets were explicit always. It was only until the revision before the exam that the rule, the scope of a λ extends as far to the right as possible, became intuitive to me.
Lazy Evaluation still seems unnecessary to me. I recognize the benefits it provides over strict evaluation. But I can’t think of scenarios where we would need things like infinite lists, or any other kind of programming made possible by lazy evaluation. Still, the lecture on Evaluation Strategies where we covered Graph Reduction, a way of performing Lazy Evaluation, was probably my favourite!
Another lecture that I loved was Recursive datatypes. I couldn’t believe how easy it is to do tree traversals in Haskell. There’s barely any code required for creating a tree of arithmetic operations and evaluating them!
I don’t agree with the idea that minimal code is better, however. Explicit is better than implicit. A lot of resources mention how powerful Haskell is, and that a lot can be achieved in it by a few lines of code. Granted that’s true but I don’t see how that can be a benefit always. If conciseness was the goal we would all be writing as we’re playing Code Golf. Terseness easily leads to cleverness, resulting in situations where the author may not understand what they wrote.
Consider the following two definitions of sum
that are equivalent:
sum :: Num a => [a] -> a
sum = foldr (+) 0
sum’ :: Num a => [a] -> a
sum’ xs = foldr (+) 0 xs
Both functions perform the same task of summing up the values of a numerical list. I much prefer the second definition because we can immediately see what arguments a function expects. I don’t need to look at the function body. The former however, makes this implicit and is the preferred way of writing Haskell programs – a style known as point-free. I don’t like it one bit.
Haskell and Lambda Calculus obviously complemented each other very well during the course. It was very enjoyable to learn something and then think how this would work in the other.
The course’s organization was great as well. I specially loved the beautiful looking lab sheets and slides. The slides colour coded related terms which was very helpful. The TAs Ben and Alex and very smart and the lab sessions with them were maybe the best part of the course.