Thoughts on Functional Programming Podcast

Are map, filter, and reduce popular for a reason? Do these things capture some essence of iteration? Are they just better for loops?

When a functional programmers looks at the typical OOP examples that show the inheritance hierarchy, they see something weird: why is one possible field plucked out to become the class? And why make it static?

It turns out that in distributed and parallel systems, time plays a huge role. I think that’s why fp is booming these days: all web sites are distributed systems. And web developers are facing all the irreducible problems of distributed systems, and they’re turning to fp for answers.

“To reify” means “to make real”. It’s an old concept from philosophy. When you name a concept, you can start talking about it. We do something similar in programming. When you take a concept and make it first class, you can begin to manipulate it with the normal programming constructs.

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.