While It’s Compiling is a new series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

It’s the third round of While It’s Compiling and we’ve had some time to chat with Kevin Hammond. Kevin is a Professor at the School of Computer Science, University of St. Andrews where he also leads the Functional Programming research group. He is also an Honorary Professor at Heriot-Watt University, Edinburgh and his main interests are in cost modelling, real-time parallelism and embedded systems.

1. What attracted you to functional languages in the first place?

I took a summer job rewriting a novel lambda calculus reducer (using spine order reduction) before starting my PhD. I actually started my PhD looking at logic languages as part of an Alvey project, but decided that Functional Languages had advantages in simpler reduction order, and had fewer compromises in purity than Prolog. This was important for maximising parallel performance (due to an administrative error, my thesis was originally about “decorative” programming languages, but I hope we now have languages that are practical as well). After finishing my PhD I moved over to Glasgow where I wrote the first Haskell compiler (pre GHC) including a parallel implementation for the GRIP multiprocessor, working with Simon Peyton Jones, Phil Wadler and John Hughes amongst others. That was a very heady mix!

2. What are you working on?

All kinds of things. I lead a very active research group at St Andrews that is investigating worst-case execution time for lazy languages, static analysis, real-time functional programming, types for parallelism, security through dependency, patterns of parallelism, implementations for heterogeneous (CPU/GPU computation), functional financial computations.

One big current project that I’m running, ParaPhrase, has 13 partners in 8 European countries and aims to develop clean functional patterns of parallelism for both Erlang and C/C++. Partly you can see this as a stealthy way to get more functional ideas into the C++ community.

3. Do you work in only FP languages, or does the project you are working on have some FP code and some OO/Procedure code? If so how does that fit together?

I’ve partially answered that above. As a language implementer, the internals of our systems tend to be very complex and often low-level. I have, for example, written microcode, needed to deal with assembly language/machine code in a very intimate way, used C or other languages for runtime systems implementation, linked with code written in various languages etc. I even at one point had to build some prototype hardware using a wire-wrap tool. If I’m doing something high-level, I much prefer to use a functional language such as Haskell, since this lets me express my ideas quickly, concisely and usually with few or no errors. As an example, the first version of the Hume compiler was written in about a fortnight.

The front end (in Haskell) took one week, and the runtime system (in C) took another week. Over 95% of the bugs were in the (much simpler) back end. I find Java (which I’ve been using since 1995) to be a very awkward level: too low level to let me code quickly and abstractly, too high level to let me get easily at the machine details, and the libraries are often rather poorly written/documented, which I find very frustrating.

One thing that horrifies some of my collaborators is that I tend to write simple Haskell programs (a few hundred lines) without any type signatures at all, using the type inference system to deal with any mistakes. I wouldn’t recommend this for production code, but it’s good for really fast prototyping.

4. What is one piece of advice you can give to new programmers?

Don’t make it too complicated! Gratuitous use of advanced language features may seem cool, but can be murder to understand, debug and change. Good code is clean, clear, easy to understand, but still abstract and generic. Oh, and syntax is important: the most heated arguments about the Haskell design related to syntax rather than semantics; and the single most contentious issues was comments. I think we did a reasonable job there.

5. Do you see the increased interest in FP in industry reflected in your students interest in FP?

Yes, but it takes time for changes to be reflected in the curriculum and we need to get the message through to both students and faculty (who can be surprisingly conservative). One way to feed this through is by running advanced Masters courses with direct industrial links that can then pull through from the undergraduate level. If anyone is interested/willing to help with this, I’d love to get in touch!

6. What would you like to ask the community?

What are the key remaining obstacles to wider spread adoption of functional techniques, and how can we work together to break these down/create new opportunities?

Also, please consider applying for one of our eight 7th Century PhD studentships (and/or tell anyone who might be interested). They’re open to students of any nationality, and have a deadline of March 31st. Please contact me if you’re interested in applying.

Know how to break down the obstacles to a wider adoption of Functional techniques? Tweet #whileitscompiling or @skillsmatter



Kevin will be speaking at the Functional Programming eXchange 2014 about ParaForming: Forming Parallel Functional Programs using Refactoring

Tickets are available at Skills Matter