Remembering Paul Hudak

Renowned computer scientist Paul Hudak, one of the designers of the Haskell programming language, died of leukemia this week. There’s been an outpouring of reactions from people Paul’s life and work has touched. Paul was my Ph.D. adviser at Yale in the 1990s. He supervised my work, paid for my education, and created an environment that enabled me to learn from some of the brightest minds in the world. Paul was an influential figure in the advancement of functional programming. Functional programming advocates a declarative style, as opposed to procedural or imperative style, of programming. For example, instead of writing result = 0; for (i=0; i<n; i++) result += a[i]; you write result = sum(a[0:n]). In many cases, the declarative style is easier to understand and more elegant. Because the declarative style focuses on what, rather than how to perform the computation, it enables programmers to worry less about implementation details and gives compilers more freedom to produce optimized code. One of the strongest influences of functional programming came from Lambda Calculus, a mathematical construct formulated by Alonzo Church in the 1930s. Lambda Calculus has had a huge impact on programming languages even though it was created before computers were invented. Lambda Calculus introduced modern programming constructs such as variable bindings, function definitions, function calls, and recursion. Alan Turing, who studied as a Ph.D. student under Alonzo Church, proved that Lambda Calculus and Turing Machine were equivalent in computability. It is therefore comforting to know that, in theory, whatever a computer can do, we can write a program for it. In 1977, around the time Paul was starting his own Ph.D. research, functional programming got a tremendous boost when John Backus presented his Turing Award lecture titled “Can Programming be Liberated from the von Neumann Style?” Backus argued conventional languages designed for sequential “word-at-a-time” processing were too complex and could no longer keep up with advances in computers. Backus favored functional style programming which possessed stronger mathematical properties. The Backus lecture had a strong impact because it represented a radical departure from his early work in leading the development of FORTRAN and in participating in the design of ALGOL 60, the major “von Neumann style” languages of its day. Functional programming research took off in the 1980s. Researchers from all over the world created numerous functional programming languages. The proliferation of languages became a problem. Many of these languages were similar enough to be understandable by humans. But researchers could not collaborate on the implementation or run each other’s programs. In 1987, Paul Hudak and a group of prominent researchers came together and created Haskell as a common research and education language for functional programming. As far as I can remember, Paul always emphasized other people’s contributions to the Haskell language. There’s no doubt, however, Paul was a major driving force behind Haskell. This is just the type of leader Paul was. He painted the vision and gathered the resources. He would create an environment for others to thrive. He attracted a remarkable group of world-class researchers at Yale Haskell Group. I made great friends like Rajiv Mirani. I was fortunate to get to know researchers like John Peterson, Charles Consel, Martin Odersky, and Mark Jones. Mark Jones, in particular, developed a variant of Haskell called Gofer. Gofer’s rich type system enabled me to complete my Ph.D. thesis work on monad transformers. I decided to pursue a Ph.D. in Yale Haskell Group largely motivated by Paul’s vision that we could make programmers more efficient by designing better programming languages. Paul believed programming languages should be expressive enough to make programmers productive, yet still retain the simplicity so programs would be easy to understand. He had a favorite saying “the most important things in programming are abstraction, abstraction, abstraction,” which meant a well-written program should be clean and simple to understand with details abstracted away in modules and libraries. Paul believed compilers should help programmers write correct code by catching as many mistakes as possible before a program ever runs. By the time I completed my Ph.D. program, however, we found it difficult to get the larger world to share the same view. The computing industry in the late 1990s and early 2000s turned out to be very different from what functional programming researchers had anticipated. There were several reasons for this. First, the von Neumann style computers kept getting better. When I worked on the Haskell compiler, computers ran at 25MHZ. CPU speed would grow to over 3GHZ in less than 10 years. The miraculous growth of the conventional computing model made benefits compilers could get from functional programming irrelevant. Second, the tremendous profit derived from Y2K and Internet build-out enabled companies to employ industry-scale programming, where armies of coders built complex systems. One of the last piece of advice Paul gave me was to accept a job in Silicon Valley working on the then-nascent non-functional language Java, instead of pursuing a research career on the East Coast. Like many others, I have witnessed with surprise the rising interest in programming language design and functional programming in recent years. No doubt this has to do with the slowing growth of CPU clock-rate and the growth in multi-core and multi-node computing. Functional programming frees developers from worrying about low-level optimization and scheduling, and enables developers to focus on solving problems at large scale. A more fundamental reason for the resurgence of functional programming, I believe, lies in the fact programming has become less of an industrial-scale effort and more of a small-scale art form. The simplicity and elegance of functional programming strike a chord with developers. Building on the rich foundational capabilities nicely abstracted away in web services, open source modules, and third-party libraries, developers can create application or infrastructure software quickly and disrupt incumbent vendors working with outdated practices. I have not kept in touch with Paul in recent years. But I can imagine it must be incredibly rewarding for Paul to see the impact of his work and see how the programming model he worked so hard to advance is finally becoming accepted.