Return Home
# Fallacy: An Appeal to Monads

## Form of fallacy

## Premises 1 and 2: *X is Y* and *Monads are Y*

## Premise 3. *Monads are good.*

## Conclusion. *Therefore, X is good.*

## A counter example.

## How to avoid making this mistake

## Examples in the wild

### PHP

### Ruby

*…In terms of the thought process behind how these structures are implemented I believe some similarities can be drawn, which does give me the impression that idea is not necessarily a bad one. In that same way that moving closer to the equator typically implies warmer weather.* – “Monads” and the continuous spectrum of goodness proximity.

The Appeal to Monads is a form of logical fallacy which creeps up in programmer discussions. Typically, a programmer presents some data structure and claims it is *like* a Monad, and is therefore good. Here, I demonstrate the argument is rubbish.

For some program, X, the following argument is made:

**Premise 1.** X is Y

**Premise 2.** Monads are Y

**Premise 3.** Monads are Good.

**Conclusion.** Therefore, X is Good.

This is a formal way of saying “X is *like* a monad”. Y is (presumed to be) the set to which some or all monads belong. For X also to be a member of Y, it must share some property with the Monad.

Typically this property is a non-idiomatic form of error handling, or other control flow, that is said to somehow be *like* Haskell monad code.

Monads are a form of abstraction that requires parametric polymorphism. If your language does not support parametric polymorphism, you won’t get a monad.

Imagine using a monad in a language that allows arbitrary mutation of state. Your monad tries to make some guarantee over its computation. At some point, a call is made to external code. Something happens which you were trying to prohibit. What is the point?

Unless you write in a functional language that has:

- Parametric polymorphism
- Strict prohibition of side effects

There is little utility to be found using monads: in your case monads are **bad**.

Even if monads are good, your thing is not a monad. Perhaps it is superficially *like* some type of monad. But it does not follow that it will be good; it does not follow that it would be good for the same reason that the monad was good.

Handling uranium with your ass is kinda like what happens at a nuclear power station.

I mean, nuclear engineers use gloves and have a point to what they are doing, but never mind that.

Nuclear power stations are legit.

Therefore, sticking uranium up your ass is legit.

Everyone agrees that nuclear power is legit, right?

- Use the existing idioms of your programming language instead of wrongly applying Haskell idioms to PHP/Assembler/Brainfuck.
- Refrain from writing enthusiastic blog posts concerning IT industry buzzwords.
- Appreciate that some concepts are more powerful when they refer to a specific thing, instead of absorbing all possible similar and not-so-similar ideas.
- If you desperately want to use monads,
*why not write your program in a language that supports them?*

*Because monadic error handling will certainly prevent your PHP code from breaking.*

Bonus: begins with *For now, let’s not worry too much about what a Monad is.*

*If it looks like a duck, and walks like a duck, it’s probably an ephemeral construct of category theory.*

Because Pipelining makes Promises easy. My pipelining code is *like* a Monad. Monads are good…

16-06-2018 Gutenfinder

13-03-2018 The Many Bleeding Edges Of Self Sufficiency

13-03-2018 Start Of 2018

21-10-2017 The Joy of Virtual Machines

21-10-2017 The Kolmogorov Esolang

21-10-2017 Why I'm taking a break from Godless development

03-07-2016 Fat Ephemeralization

03-07-2016 Nathan Barley, meet Autocad.

08-03-2016 Appeal to Monads

29-02-2016 Godelbrot Region Render Algorithm