Thoughts on Functional Programming Podcast

Functional programmers tend to prefer pure, immutable data to represent their domain. We talk about many of the benefits of such an approach. But we focus on one in particular: that good data representations can reduce complexity by reducing the number of if statements you need.

There are two sources of complexity in software: the complexity inherent in the domain (essential complexity) and the complexity we add as programmers due to the platform or due to bad programming practices (accidental complexity).

Functional programmers tend to model important relationships using data, while OO programmers tend to represent them with references.

How do functional programmers use the Single Responsibility Principle?

This ain’t no “a monad is a burrito” talk. This is a real-world monad, found in the wild. We look at how reading a book is monadic. It’s what lets you see a list of lines of words as a single stream of words.

Functional programmers often talk about creating layered designs, where each layer represents a coherent level of abstraction. It’s a way to organize your code.

People ask me how to keep functional code organized. It’s a good question but my answer is so simple, it feels kind of silly saying it: I keep everything in one file, and split it up as it grows.

Does the term “design” make sense in the context of code? I discuss Sandi Metz’s definition from her book Practical Object Oriented Design in Ruby.

In OO languages like Java, people tend to make new classes more than they reuse existing ones. In Clojure and other FP languages, we tend more on the side of reuse. How do we develop that habit?