An interview with Simon Thompson
Today you will read Simon Thompson’s interview. Simon is Professor of Logic and Computation in the Computing Laboratory of the University of Kent, moreover he is one of the authors of the project Wrangler. He also wrote with Francesco Cesarini the book Erlang Programming.
Ask and answer
Paolo – Hi Simon, how would you like to introduce yourself to our readers?
Simon – Hi, I am Simon Thompson, and I have been at the University of Kent since the early 1980s. I teach a variety of subjects, but my favourite – and the area where most of my research is focussed – is functional programming. Recently I’ve been working on building tools to help programmers to be more productive and with my colleague Huiqing Li have built the Wrangler tool for refactoring functional programs; I talk more about that later on.
Paolo – You have been teaching computing at undergraduate and postgraduate levels for the past twenty five years. Do you think functional programming spread is growing?
Simon – Certainly: you can measure this in the number of jobs on offer, by the growing interest in different languages at the major open source conferences, and by the action around functional languages in the open source community. Specifically you can see this in the contributions to the Erlang system on github and in the number of open source Haskell packages contributed to Hackage.
Paolo – In your experience as teacher and developer, what is the most difficult thing to learn in Erlang world?
Simon – Experienced programmers coming to Erlang find the functional basis quite dis-orientating: how can I program without “proper” variables and control structures? It takes time to see that this can be done with tail recursion and “loop data”, and then a bit more time to internalise this so that it becomes second nature. Other concepts, such as “processes that share nothing” sell themselves more easily.
For beginning programmers the problem can be a different one: they can be unhappy that they can’t write “real” programs in whatever functional language. That’s partly the fault of the textbooks (mea culpa) but also due to the lack of support for realistic libraries, bindings etc. That has changed, and in both Haskell and Erlang it’s now straightforward to program more realistic systems.
Paolo – And what are the most common errors developers do when coding in Erlang?
Simon – Errors are so individual, it’s hard to single out particular ones. At a higher level, one of the more difficult lessons to learn in Erlang is to “let it fail” and not to program defensively, instead letting the context and the infrastructure deal with the crash.
Paolo – Based on your experience, how would you characterize the degree and quality of the collaboration between Universities and businesses?
Simon – Big question. First, as an educator, I really value student co-operating with industrial partners to offer students one year “sandwich” placements, where they work for a year during their studies. The majority of our students do this, and it’s a win-win-win. Employers get a chance to work with students and recruit them on graduation, students learn the practical aspects of computing which we simply can’t teach in a university classroom, and the department benefits from more focussed and more motivated students, who actually get improved results in final exams as a result of their placement.
As a researcher, I have benefited from working with a variety of companies, and particularly Erlang Solutions Ltd. We have together received two tranches of UK government funding for “Knowledge Transfer Partnerships”, one for using refactoring techniques in practice and the other for e-learning. in each case there’s been two-way traffic: ESL have given us a practical context for our ideas, “tensioning” what we do to make sure it’s useful, while we have been able to roll out academic ideas into practice. In the ProTest project, which is funded by the European Commission, a number of universities have benefitted from collaborating with Ericsson, Lambda Stream and Quviq as well as ESL, and this has given us invaluable feedback about what;s useful in the tools and techniques that we’re building, like Wrangler.
Paolo – At Erlang Factory in London, you will give a talk on DIY refactoring with Wrangler. Can you tell to our readers what is Wrangler?
Simon – Wrangler is a tool for refactoring Erlang programmers, written in Erlang and accessible within Emacs and ErlIDE as well as on the command line. Wrangler implements a whole collection of refactorings, and “bad smell” detection, and applies these refactorings across complete projects.
In particular it can be used to detect and eliminate code clones. We automate the generation of reports of clones, as well as the transformations themselves, but the selection and direction of these is very much under user control.
Paolo – Why should Erlang developers use Wrangler?
Simon – It can help you clean up your code, by getting rid of bad smells coming from clones or from problems in the module structure of the system. Those are the “occasional” refactorings, which you might do every once in a while, but others – like function extraction – are transformations that you might well want to do in your day-to-day programming practice: hence the reason that we have built Wrangler into the common IDEs. Finally, using the clone detection and other tools can help you to understand how some code works, if you’ve inherited responsibility for a test suite, for example.
Paolo – Can you suggest to our readers some resources online to learn more about Wrangler?
Simon – There is a guide to getting started and links to YouTube videos at the Wrangler home page. Please mail me if you have any feedback or comments on the system, the videos or anything else to do with Wrangler; we’d really like to have your feedback.
Paolo – You wrote also “Miranda: the Craft of Functional Programming”, and “Haskell: The Craft of Functional Programming”: why should an Erlang developer learn one of these two other languages?
Simon – Haskell is different from Erlang in quite a few ways: it’s lazy, doing evaluation on demand, it’s side-effect free, and most importantly it’s strongly typed: every expression and definition has a most general type. This means that when we’re writing a program in Haskell the first thing to do is to write its type: whether our program has that type is then checked by the compiler. This keeps you “honest” and avoids a whole class of errors, which in Erlang might be caught by dialyzer, but also might not.
Can I conclude with a plug for the third edition of the Haskell book, which is out in mid June: more details here.