Chapter 1: What is functional programming?

Contents

• Notes: Chapter notes and links to further reading related to the content in this chapter
• FAQ: Questions related to the chapter content. Feel free to add questions and/or answers here related to the chapter.

Notes

See the Wikipedia articles on functional programming and referential transparency.

Why functional programming matters

In this chapter we highlight some of the benefits of functional programming. A classic article that gives some justification for FP is John Hughes's Why Functional Programming Matters.

Referential transparency and side effects

We introduce functional programming as programming with referentially transparent expressions. Our definition of referential transparency in the chapter is a little bit simplistic, but it serves our purposes for the time being. We discuss a more expanded notion of referential transparency in chapter 14 on "local effects".

A subtlety in the definition of RT given in the chapter is the meaning of "without affecting the meaning". What is the meaning of a program? To answer this, we need to consider the program with regard to some evaluator, or in the context of some other program. That is, the meaning of a program depends very much on how we interpret or evaluate it, and whether some effect of evaluation is to be considered a side effect depends on the observer. For example, the fact that memory allocations occur as a side effect of data construction is not something we usually care to track or are even able to observe on the JVM. So ultimately what we consider to break referential transparency depends very much on what we can or care to observe.

See for example What purity is and isn't for a discussion of purity with regard to an evaluator, and Is network I/O always worth tracking? for a more philosophical take on what constitutes a side effect.

FAQ