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.