Thread by @graninas

"Never use Free Monads.

They are slow.
They produce boilerplate.
They require functors. Functors can’t be composed.
They require interpreters. Interpreters can’t be composed.
So FMs can’t be composed."

These statements are all wrong or completely misleading.

1/

Unfortunately, the FUD about Free Monads was significantly boiled by several articles in which the reasoning was based on the mathematical nature of Free Monads rather on the applicability in a particular tasks. (I won’t provide links to avoid unnecessary conflicts.)

2/

In software design, nothing should be assessed from the theoretical point of view. It’s not a rare case when a theoretical statement on some topic turns out to be completely misleading because of the impurity and limitations of the real world.

3/

And vice versa. We often meet the problems that we’d better solve with some fast and dirty hack even if some paper says it’s bad or impossible. If we want to build real software in Haskell, we should unlearn our habits to pursue math excellence.

4/

Free Monads are one of the best design approaches available in statically typed functional programming. Free Monads very powerful and relatively simple. Free Monads don't require additional stuff from the complicated castles of type-level magic as other approaches do.

5/

No, Free Monads are not “slow” in general as they are rumored. There are several different Free Monads:

- Normal Form F. M. (O(n^2) binding)
- Church Encoded F. M. (O(n) binding, as fast as Final Tagless)
- “No remorse” F. M. (used in PureScript, as fast as FT)
- some more.

6/

Theorizing about the performance of an approach when the only math properties are considered is a slippery idea. Even the awfully slow bubble sort is used in some cases. There is no point in rejecting an approach (or language) because someone said it’s slow.

7/

Performance is always a question of requirements a program should meet. But often performance becomes a cargo cult with dancing needlessly around the less important task while risking to fail a bigger one, which is way more important and complex usually.

8/

Normal Free Monads can only be a problem if you have a long chain of monadic actions which you want to be super fast. 30+ operations will be relatively slow.

Church Encoded Free Monads are completely fine. In my Hydra project, I demonstrated that they are as fast as FT.

9/

But even “slow” Free Monads can be good enough in a particular situation. If you feel uncertain, you can start with Free Monad and then replace it by Church Encoded Free Monad later on. They have different implementation, but the interface is almost the same.

10/

Here, I’m not arguing against the statements “functors can’t be composed” and “interpreters can’t be composed”. I’m not interested in whether this true from the math point of view. What I know it’s not an obstruction for using Free Monads in practice.

11/

If you need a kind of “composition”, my engineery solution “Hierarchical Free Monads” works well. As I demonstrated in my talks and projects, this approach is pretty simple and doesn’t a sophisticated type level machinery.

12/

“But you didn’t solve the Expression Problem!”

Well yes, so?

There is nothing about the Expression Problem in my work contract. We solve business problems we’re paid for. If the goal is achieved, why should we bother about the Expression Problem?

13/

You typically know what main effects (better say “subsystems”) should be in the application. All those subsystems are pretty common across the applications: logging, DB, state… For other purposes you can either extend your Free Monad or use the RunIO method as a shortcut.

14/

“But Free Monads produce too much boilerplate! You have to write interpreters, and, what a shame, Functor instances by hand!”

Well yes… but actually no. This “boilerplate” should be written once and then stays untouched the whole lifecycle of the application.

15/

And Functor instances? Just a dozen lines of simple code having the same shape. There is nothing bad in writing such lines by hand once in your life.

16/

Free Monads free you from boilerplate in the business logic, the biggest and most valuable part of an application. This is important, because you work with business logic the most of your time.

17/

Boilerplate is not a repeating code that you have a potential to automate somehow.

Boilerplate is a situation that makes you to write the same code again and again in your day-to-day practice.

Boilerplate is the code that interferes with refactoring.

18/

Just for the record: all the effect systems are much more boilerplaty because they’re forcing you to declare the effects as type level lists (or type class constraints - a note for the Haskellists who understand things too literally).

19/

It’s pretty hard to fight against a widely spread opinion once emitted by an influential article. Even worse if this article is a scientific paper. I’ve met a lot of resistance to Free Monads because the X article stated it’s a bad approach.

No, Free Monads are awesome.

/20