Making the case for functional programmingMaking the case for functional programming<br>Where does the difference between Java and Haskell come from? 2026.07.11<br>KO | ENFunctional programming as a paradigmThe practical benefits of functional programming<br>Functional programming is clearly mainstream now. Many programming languages have already adopted its core ideas, and companies like Greenlabs are producing successful examples of functional programming at enterprise scale. Books and other materials explaining functional programming are easy to find too. Lately, even people just getting started in programming seem to recognize its importance.And yet there still are not many programmers who take functional programming seriously. Programmers who have only just started looking into what it is often doubt themselves: “I use map, filter, and reduce every day, so am I a functional programmer?” In a broad sense the answer is yes, because they handle first-class functions and preserve the immutability of lists, but that still does not wash the doubt from their minds cleanly. By the same token, saying “the language you use every day is a functional programming language, and we are all doing functional programming” rings hollow. That may be true, and it may lower the psychological barrier around functional programming, but it still is not what people expect functional programming to be.Meanwhile, ideas like functors and monads are still taken as the kind of thing only programming language nerds dig into. Haskell can even seem more like mathematics. Listing the many advantages of functional programming and talking as if it were simply the right thing to do does not persuade anyone. As John Hughes put it in Why Functional Programming Matters[1], “The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous.” If functional programming is to be persuasive, as Hughes said, it has to prove its practical benefits.Functional programming as a paradigm<br>The first thing people do when trying to understand functional programming is look for the languages called functional programming languages. What counts as a functional programming language? It is a perennial circular debate among programmers. The debate always ends up being wasteful because there is no agreed standard or definition of functional programming. In a broad sense, though, any language that supports first-class functions is a functional programming language. If a language lets functions be treated the same way as other values, that is, if you can assign a function to a variable, pass a function as an argument to another function, and return a function from a function, then that language supports first-class functions. Things often mentioned as the core of functional programming, such as pure functions, immutability, lazy evaluation, referential transparency, and currying, are secondary by comparison when seen from the perspective of language design.By that definition, JavaScript, Python, and Java, all of which support first-class functions, are all functional programming languages. It is genuinely possible to do functional programming in them. But if Java really is a functional programming language like Haskell, where does the subtle difference people feel when comparing Java and Haskell come from? Perhaps the reason the argument over what counts as a functional programming language keeps returning, even though there is an agreed definition of first-class functions, is that this subtle difference is not easy to explain.Misunderstandings about Haskell contribute to that subtle difference, but I think the bigger gap lies in the paradigms the two languages aim at. A programming paradigm is not exactly the same thing as the scientific paradigm Thomas Kuhn talked about, but the idea can still be borrowed, in the sense that programmer communities in each era tend to share a common set of theories, rules, beliefs, and values. To talk about functional programming as a paradigm, it is not enough just to explain what functional programming is. We also need to look at the historical context through which programming paradigms have developed.The ancestor of what we now call a function in programming was the subroutine. A subroutine was simply a way to jump the program’s flow of execution from the main routine into a subroutine. At the time, a subroutine that returned a value to the main routine was called a function. Later, the distinction between functions and subroutines disappeared, and all subroutines came to be called functions. This kind of function is different from a function in mathematics. A function f(x)f(x)f(x) may denote no value at all (void), may modify the argument xxx itself (call-by-reference), or may modify some arbitrary variable outside the function.The goto statement, which transfers control flow to another subroutine, created the problem of execution jumping around wildly. Out of...