What Might Functional Programming Mean
and should we care?

I want to know what functional programming is, and if it's a good thing.

However, treating functions as first class citizens, like "programming with functions", is too broad! There are two questions one could ask:

1. Am I able to treat functions as first-class citizens?
2. Do I want to treat functions as first-class citizens?

Functional Programming as "treating functions as first class citizens" is at best something which is sometimes useful to do, and is a non-controversial practice.

There is one slightly more reasonable, and two much more reasonable, opinions which people often mean when they talk about no side effects:

1. There are no references to side effects in the language specification
   • An implementation of that language may perform side effects when it processes certain expressions
2. Side effects are dangerous and so we should be careful about how we use them
3. All data structures in the language are immutable

I will discuss (3) in the next section.

Functional programming as "programming without side effects" is nonsense, but recognizing the dangers of side effects is helpful, which is mostly non-controversial.

There are minor potential downsides, such as performance, which I won't discuss here. Rather, I wish to discuss what I see as the only candidate for a fundamental downside.

When we write computer programs, we often want to model some part of the world. Since part of our goal when writing computer programs is always to change the state of the world, it often seems useful to reify those mutable parts of the world in our program. And the fact that they are mutable is not an incidental property we can ignore, but essential to the problem at hand.²

So it seems that we lose a kind of expressive power with immutable data structures. This is especially evident in areas such as graphical programming, where it can be difficult to imagine not modeling graphical objects as those with states that change over time. But even here there has been work to come up with functional paradigms, albeit with no obvious grand success of which I am aware.

Functional programming as "programming exclusively with immutable data" is an interesting and still yet-to-be widely accepted approach to programming which is worth talking about. The dangers of undisciplined data mutation is widely known and non-controversial.

(3) is terribly misleading, funnily because of not taking seriously the idea of functions as values. It is virtually impossible to write a function which only looks at its arguments. Consider the following function definition:

(define square
  (lambda (x)
    (* x x)))

There is a non-local reference here: *!
Every function consists of references to non-local data. What makes the above code actually "transparent" to reason about is lexical scoping. That is, the fact that the value which is bound to * within the scope of the function cannot be changed outside the scope of the function after its definition. Note that immutability also makes a difference here, because it ensures that there is no time attached to this definition. If there were mutation in the language of the above code, mutating the value of * before the definition is made could cause confusion.

That leaves us with (4). But we obviously don't want all functions to return the same value given the same arguments + environment, because we would like to read in data from the outside world. So we can't take an absolutist stance to (4), only a conditional one. But that functions should generally return the same thing given the same arguments is widely agreed upon.

Therefore, talking about pure functions either reduces to talking about something else (like immutability or side effects), or is pointless/trivial.

Functional programming as "programming with pure functions" is a useless notion.

In addition to this, most if not all of the other ideas discussed in this article are related to each other. It is difficult to program with immutable data without first-class functions, and it is easier to control side effects with immutable data. Thus I don't think there is any need to censor speech about these other qualities in relation to functional programming. But, rather than talking about them as part of a constellation of functional qualities, we should instead speak of them as the branches of a tree rooted in the idea of immutability.

Finally, there are a few other things people bring up when talking about functional programming, such as:

• Pattern Matching
• Recursion / Tail Call Optimization
• Lazy Evaluation
• Type Systems

and more. However, these are all potential concrete features of a programming language, not a programming paradigm. I would classify them similarly to everything which is not immutable data that we've already discussed: things which pair nicely with functional programming.

Functional programming is immutable programming, which makes it very cool 😎.