Doi: 10.1145/2018396.2018413
Article development led by
queue.acm.org
Why the next language you learn
should be functional.
By yaRoN miNsky
ocaml for
the masses
SometimeS, the eLeGAnt implementation is a
function. Not a method. Not a class. Not a framework.
Just a function. —John Carmack
Functional programming is an old idea with a
distinguished history. Lisp, a functional language
inspired by Alonzo Church’s lambda calculus, was
one of the first programming languages developed
at the dawn of the computing age. Statically typed
functional languages such as oCaml and Haskell
are newer, but their roots go deep—ML, from which
they descend, dates back to work by Robin Milner
in the early 1970s relating to the pioneering Logic
for Computable Functions (LCF) theorem prover.
Functional programming has also
been enormously influential. Many fundamental advances in programming
language design, from garbage collection to generics to type inference, came
out of the functional world and were
commonplace there decades before
they made it to other languages.
Yet functional languages never really
made it to the mainstream. They came
closest, perhaps, in the days of Symbolics and the Lisp machines, but those
days seem quite remote now. Despite a
resurgence of functional programming
in the past few years, it remains a technology more talked about than used.
It is tempting to conclude from this
record that functional languages do
not have what it takes. They may make
sense for certain limited applications,
and contain useful concepts to be imported into other languages; but imperative and object-oriented languages
are simply better suited to the vast majority of software engineering tasks.
Tempting as it is, this conclusion is
wrong. I have been using OCaml in a
production environment for nearly a decade, and over that time I have become
convinced that functional languages,
and in particular, statically typed ones
such as OCaml and Haskell, are excel-
