The three principles of functional programming

The “three principles of functional programming,” from this tweet:

1. Orthogonal composability
2. Maximum polymorphism
3. Maximum deferment

The “three pillars of functional programming,” from Functional and Reactive Domain Modeling:

1. Referential transparency
2. Substitution model
3. Equational reasoning

When I learned OOP I saw that it was based on several principles that everyone agrees upon. When I started learning FP (and later took two years to write Functional Programming, Simplified) I was surprised there wasn’t a single accepted definition of functional programming. I ran across the principles/pillars in the last two days and was reminded of that again.

The meaning of the word “reify” in programming

I don’t recall hearing of the words “reify” or “reification” in my OOP years, but that may be because I studied aerospace engineering in college, not computer science. Since learning FP I often see those words, so I thought I’d try to understand their meaning.

The short answer is that the main definition seems to be:

“Taking an abstract concept and making it concrete.”

For the longer answer, I found the following definitions and examples of reification.

A terrific Model View Controller (MVC) diagram

Every once in a while when something hits you, you really remember it; it stands out in your mind as an “Aha” moment. One of those moments for me was when I saw a particular “Model/View/Controller” (MVC) diagram, and the light bulb went on. This diagram made the MVC pattern very simple, and I’ve never forgotten it.

The Scala spectrum: OOP to Pure FP

Scala is a great language in many ways. One great feature is that you can use it as a “Better Java” (i.e., as an OOP language), and you can also use it as a pure FP language. While some people prefer one extreme or the other (not unlike extremist Republicans and Democrats in the U.S.), I appreciate that this lets you find a “Middle Way” of using the best features of both approaches.

What is “Functional Programming”?

Table of Contents1 - Defining “Functional Programming”2 - A working definition of “pure function”3 - Note 1: Higher-Order Functions are a great FP language feature4 - Note 2: Recursion is a by-product5 - Proof: Wikipedia’s FP definition6 - Proof: A wonderful quote from Mary Rose Cook7 - That’s great ... but why immutable values?8 - Summary9 - See also

Note: This is an excerpt from my forthcoming book on Scala and functional programming. (No one has review this text yet. All mistakes are definitely my own.)

Back to top

Defining “Functional Programming”

It’s surprisingly hard to find a consistent definition of functional programming. As just one example, some people say that functional programming (FP) is about writing pure functions — which is a good start — but then they add something else like, “The programming language must be lazy.” Really? Does a programming language really have to be lazy (non-strict) to be FP? (The correct answer is “no.”)

I share links to many definitions at the end of this lesson, but I think you can define FP with just two statements:

An article on the problems with OOP

There seems to be a lot of OOP-bashing lately, which I’m not a fan of, but this article titled Goodbye, OOP makes decent points about the problems with inheritance, encapsulation, and polymorphism. IMHO, OOP still makes sense in certain areas, including GUIs like Java Swing and JavaFX, so I’m not ready to throw it out completely or bash it.

OOP, FP, and encapsulating state

This article on medium.com has the flame title, Object-Oriented Programming: A Disaster Story. IMHO, a less-flamy but still accurate title would be, “OOP, FP, and the conundrum of encapsulating state.”

As someone who occasionally thinks of himself as an engineer as well as a software developer, I think you have to always look for what is the best solution to the problem, and sometimes that’s more along the lines of OOP, sometimes it’s FP, and sometimes it’s a hybrid.

For instance, when it comes to collection classes, I like the hybrid approach of the Scala collection classes where it appears that the functions are directly available on a collection instance, so I can write something like res = people.filter(age > 30). In other languages the filter function may not be directly available on a sequential collection class, so you have to import it and then write something like res = filter(people, age > 30). In either case you’re doing the same thing in the end, but the Scala approach “feels” better to me, and it’s also easier to read. (This example may just be syntactic sugar, but again, it’s easier to read, and the collections’ methods are a bit of a hybrid.)

As a better example of what I’m trying to say, OOP makes a lot of sense for rich GUIs, like Java Swing. Things like a JFrame, JDialog, JList, JTable, etc., all make a lot of sense in an OOP design. For instance, you create a JTable, the data is updated, users move columns around, and so on. OOP fits this very well.