Introduction to functional programming

We explain what functional programming is, explore its benefits, and look at resources for learning functional programming.
518 readers like this.
How to use Python to hack your Eclipse IDE

Depending on whom you ask, functional programming (FP) is either an enlightened approach to programming that should be spread far and wide, or an overly academic approach to programming with few real-world benefits. In this article, I will explain what functional programming is, explore its benefits, and recommend resources for learning functional programming.

Syntax primer

Code examples in this article are in the Haskell programming language. All that you need to understand for this article is the basic function syntax:

  even :: Int -> Bool
  even = ...    -- implementation goes here

This defines a one-argument function named even. The first line is the type declaration, which says that even takes an Int and returns a Bool. The implementation follows and consists of one or more equations. We'll ignore the implementation (the name and type tell us enough):

  map :: (a -> b) -> [a] -> [b]
  map = ...

In this example, map is a function that takes two arguments:

  1. (a -> b): a functions that turns an a into a b
  2. [a]: a list of a

and returns a list of b. Again, we don't care about the definition—the type is more interesting! a and b are type variables that could stand for any type. In the expression below, a is Int and b is Bool:

  map even [1,2,3]

It evaluates to a [Bool]:


If you see other syntax that you do not understand, don't panic; full comprehension of the syntax is not essential.

Myths about functional programming

Let's begin by dispelling common misconceptions:

  • Functional programming is not the rival or antithesis of imperative or object-oriented programming. This is a false dichotomy.
  • Functional programming is not just the domain of academics. It is true that the history of functional programming is steeped in academia, and languages such as like Haskell and OCaml are popular research languages. But today many companies use functional programming for large-scale systems, small specialized programs, and everything in between. There's even an annual conference for Commercial Users of Functional Programming; past programs give an insight into how functional programming is being used in industry, and by whom.
  • Functional programming has nothing to do with monads, nor any other particular abstraction. For all the hand-wringing around this topic, monad is just an abstraction with laws. Some things are monads, others are not.
  • Functional programming is not especially hard to learn. Some languages may have different syntax or evaluation semantics from those you already know, but these differences are superficial. There are dense concepts in functional programming, but this is also true of other approaches.

What is functional programming?

At its core, functional programming is just programming with functions—pure mathematical functions. The result of a function depends only on the arguments, and there are no side effects, such as I/O or mutation of state. Programs are built by combining functions together. One way of combining functions is function composition:

  (.) :: (b -> c) -> (a -> b) -> (a -> c)
  (g . f) x = g (f x)

This infix function combines two functions into one, applying g to the output of f. We'll see it used in an upcoming example. For comparison, the same function in Python looks like:

  def compose(g, f):
    return lambda x: g(f(x))

The beauty of functional programming is that because functions are deterministic and have no side effects, you can always replace a function application with the result of the application. This substitution of equals for equals enables equational reasoning. Every programmer has to reason about their code and others', and equational reasoning is a great tool for doing that. Let's look at an example. You encounter the expression:

  map even . map (+1)

What does this program do? Can it be simplified? Equational reasoning lets you analyze the code through a series of substitutions:

  map even . map (+1)
  map (even . (+1))         -- from definition of 'map'
  map (\x -> even (x + 1))  -- lambda abstraction
  map odd                   -- from definition of 'even'

We can use equational reasoning to understand programs and optimize for readability. The Haskell compiler uses equational reasoning to perform many kinds of program optimizations. Without pure functions, equational reasoning either isn't possible, or requires an inordinate effort from the programmer.

Functional programming languages

What do you need from a programming language to be able to do functional programming?

Doing functional programming meaningfully in a language without higher-order functions (the ability to pass functions as arguments and return functions), lambdas (anonymous functions), and generics is difficult. Most modern languages have these, but there are differences in how well different languages support functional programming. The languages with the best support are called functional programming languages. These include Haskell, OCaml, F#, and Scala, which are statically typed, and the dynamically typed Erlang and Clojure.

Even among functional languages there are big differences in how far you can exploit functional programming. Having a type system helps a lot, especially if it supports type inference (so you don't always have to type the types). There isn't room in this article to go into detail, but suffice it to say, not all type systems are created equal.

As with all languages, different functional languages emphasize different concepts, techniques, or use cases. When choosing a language, considering how well it supports functional programming and whether it fits your use case is important. If you're stuck using some non-FP language, you will still benefit from applying functional programming to the extent the language supports it.

Don't open that trap door!

Recall that the result of a function depends only on its inputs. Alas, almost all programming languages have "features" that break this assumption. Null values, type case (instanceof), type casting, exceptions, side-effects, and the possibility of infinite recursion are trap doors that break equational reasoning and impair a programmer's ability to reason about the behavior or correctness of a program. (Total languages, which do not have any trap doors, include Agda, Idris, and Coq.)

Fortunately, as programmers, we can choose to avoid these traps, and if we are disciplined, we can pretend that the trap doors do not exist. This idea is called fast and loose reasoning. It costs nothing—almost any program can be written without using the trap doors—and by avoiding them you win back equational reasoning, composability and reuse.

Let's discuss exceptions in detail. This trap door breaks equational reasoning because the possibility of abnormal termination is not reflected in the type. (Count yourself lucky if the documentation even mentions the exceptions that could be thrown.) But there is no reason why we can't have a return type that encompasses all the failure modes.

Avoiding trap doors is an area in which language features can make a big difference. For avoiding exceptions, algebraic data types can be used to model error conditions, like so:

  -- new data type for results of computations that can fail
  data Result e a = Error e | Success a

  -- new data type for three kinds of arithmetic errors
  data ArithError = DivByZero | Overflow | Underflow

  -- integer division, accounting for divide-by-zero
  safeDiv :: Int -> Int -> Result ArithError Int
  safeDiv x y =
    if y == 0
      then Error DivByZero
      else Success (div x y)

The trade-off in this example is that you must now work with values of type Result ArithError Int instead of plain old Int, but there are abstractions for dealing with this. You no longer need to handle exceptions and can use fast and loose reasoning, so overall it's a win.

Theorems for free

Most modern statically typed languages have generics (also called parametric polymorphism), where functions are defined over one or more abstract types. For example, consider a function over lists:

  f :: [a] -> [a]
  f = ...

The same function in Java looks like:

  static <A> List<A> f(List<A> xs) { ... }

The compiled program is a proof that this function will work with any choice for the type a. With that in mind, and employing fast and loose reasoning, can you work out what the function does? Does knowing the type help?

In this case, the type doesn't tell us exactly what the function does (it could reverse the list, drop the first element, or many other things), but it does tell us a lot. Just from the type, we can derive theorems about the function:

  • Theorem 1: Every element in the output appears in the input; it couldn't possibly add an a to the list because it has no knowledge of what a is or how to construct one.
  • Theorem 2: If you map any function over the list then apply f, the result is the same as applying f then mapping.

Theorem 1 helps us understand what the code is doing, and Theorem 2 is useful for program optimization. We learned all this just from the type! This result—the ability to derive useful theorems from types—is called parametricity. It follows that a type is a partial (sometimes complete) specification of a function's behavior, and a kind of machine-checked documentation.

Now it's your turn to exploit parametricity. What can you conclude from the types of map and (.), or the following functions?

  • foo :: a -> (a, a)
  • bar :: a -> a -> a
  • baz :: b -> a -> a

Resources for learning functional programming

Perhaps you have been convinced that functional programming is a better way to write software, and you are wondering how to get started? There are several approaches to learning functional programming; here are some I recommend (with, I admit, a strong bias toward Haskell):

  • UPenn's CIS 194: Introduction to Haskell is a solid introduction to functional programming concepts and real-world Haskell development. The course material is available, but the lectures are not (you could view Brisbane Functional Programming Group's series of talks covering CIS 194 from a few years ago instead).
  • Good introductory books include Functional Programming in Scala, Thinking Functionally with Haskell, and Haskell Programming from first principles.
  • The Data61 FP course (f.k.a., NICTA course) teaches foundational abstractions and data structures through type-driven development. The payoff is huge, but it is difficult by design, having its origins in training workshops, so only attempt it if you know a functional programmer who is willing to mentor you.
  • Start practicing functional programming in whatever code you're working on. Write pure functions (avoid non-determinism and mutation), use higher-order functions and recursion instead of loops, exploit parametricity for improved readability and reuse. Many people start out in functional programming by experimenting and experiencing the benefits in all kinds of languages.
  • Join a functional programming user group or study group in your area—or start one—and look out for functional programming conferences (new ones are popping up all the time).


In this article, I discussed what functional programming is and is not, and looked at advantages of functional programming, including equational reasoning and parametricity. We learned that you can do some functional programming in most programming languages, but the choice of language affects how much you can benefit, with functional programming languages, such as Haskell, having the most to offer. I also recommended resources for learning functional programming.

Functional programming is a rich field and there are many deeper (and denser) topics awaiting exploration. I would be remiss not to mention a few that have practical implications, such as:

  • lenses and prisms (first-class, composable getters and setters; great for working with nested data);
  • theorem proving (why test your code when you could prove it correct instead?);
  • lazy evaluation (lets you work with potentially infinite data structures);
  • and category theory (the origin of many beautiful and practical abstractions in functional programming).

I hope that you have enjoyed this introduction to functional programming and are inspired to dive into this fun and practical approach to software development.

This article is published under the CC BY 4.0 license.

User profile image.
Software Engineer at Red Hat. Interested in functional programming, category theory and other intersections of math and programming. Crazy about jalapeños.


Wouldn't the functions in functional programming need to produce two outputs: 1) the normal out, and 2) the next state out, because you can't have a complex computer program without it generating state?

Great question Tom. In such cases, the type of the output is a 2-tuple, or product, of the "normal output" and "next state". There are nice abstractions for structuring programs to work with state in this form, so you're not always having to explicitly construct and deconstruct the (state, output) tuple.

A side note: you might be surprised at what you can accomplish without state! Having state can make it easier to express a program or algorithm, but the Church-Turing Thesis tells us that algorithms that truly require state... do not exist :)

In reply to by Tom Borkowski (not verified)

Tom, yes, but most of the time the 'normal out' and the 'next state out' are the same thing, like for the result of the fibonacci function.

In reply to by Tom Borkowski (not verified)

Thanks for article!
One question about the introductory books for Haskell: what about Programming in Haskell (2nd Edition), by Graham Hutton? Do you know if this book would be proper to a beginner in Haskell, using it for self-learning?

Hi Florin, I wasn't aware of this book but I asked around about it. Some folks have read it, and recommend it for committed beginners.

In reply to by florindan

I've heard great things about "Learn you a Haskel for Great Good." I'm learning FP in Javascript and have this book on order to help me grok the material.

In reply to by florindan

Hi Matt. In my opinion, LYAH is good for learning Haskell syntax, and probably OK for beginner programmers. It explains a lot of things well but IMO does not do a great job of teaching foundational abstractions for FP (regardless of language). But these are just my own experiences, and regardless it is definitely a fun and engaging book.

In reply to by Matt Perkins (not verified)

Every "Intro to Functional Program" article I see explains how FP uses pure functions with no side effects and all the neat things that implies. They all seem to scrupulously avoid addressing the fact that virtually all useful programs require side effects and how that is reconciled with FP. After all, even displaying the result of your function on a screen is a side effect.

Hi Norton. There are two aspects to this.

First, the fact that many languages let you do I/O anywhere raises the question of whether it is worthwhile to avoid it except where absolutely necessary. It *is* worth it to do so because it lets you use fast and loose reasoning. The "functional core / imperative shell" pattern is an example of how this can work out in practice.

Second, is there a way to perform I/O (or other side effects) in a pure functional program (with all of the benefits that that would imply)? You can - you just need an *interpreter* to do the messy bits. In this sense the pure program is like a recipe: a set of instructions that don't do anything on their own.

In reply to by Norton Allen (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution 4.0 International License.