A Neighborhood of Infinity

It's definitely surprising, for a couple of reasons:
1. It isn't just the uninteresting result that the set of trees has the same cardinality as the set of 7-tuples of trees; the bijection here is given by a finite, non-looping program built out of `isEmpty : Tree -> Bool`, `getLeft : Tree -> Maybe Tree`, `getRight : Tree -> Maybe Tree`, and the constructors `empty : Tree` and `join : Tree x Tree -> Tree`
2. It isn't true for any number 1 < x < 7
3. In any case, why should it work out exactly? Why not "one tree can be encoded into seven trees, or one of these 13 remaining cases"?

The paper is quite good, but Dan Piponi has a great blog post that recasts the isomorphism as a game of "nuclear pennies", which is a fun puzzle to work out yourself: http://blog.sigfpe.com/2007/09/arboreal-isomorphisms-from-nuclear.html

Category theory is mostly useful if you're getting very deep into Haskell, or if—for some reason—you need to generalize the lamba calculus to handle strange new kinds of computations.

In particular, the lamba calculus is closely related to Cartesian closed categories, which are in turn related to topoi (which are used in many cases of mathematical logic). And from there it's a small leap to probability and generalizations of probability theory.

So basically, if you're a programming language designer with esoteric tastes, category theory contains some great abstractions.

Here's​ an example showing how to represent quantum superposition as a monad: http://blog.sigfpe.com/2007/02/monads-for-vector-spaces-probability.html If this kind of thing makes you drool, go learn some category theory. :-)

I also found the style in this article kind of annoying and difficult to follow, but I think "discovery fiction" usually means something different. The two examples Michael Nielsen gives are https://michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/ and https://michaelnielsen.org/ddi/why-bloom-filters-work-the-way-they-do/. Another classic example is http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html.

You can see there's no dialogue; the idea is to frame an article as "how might you discover/invent this concept on your own", rather than just directly explaining how a thing works. You are given a fictional goal, and you "discover" the subject matter by building iterative solutions.

To be fair, I don't know a single person that explains things using

> "just a monoid in the category of endofunctors"

In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell.

As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html

The whole point about monads is that they provide a uniform interface for working with values that carry some extra context. The genericity of the interface is nice, in that it allows you to write generic monad combinators, but they are only useful because of the context (effects, control flow, etc). If you don't describe any of the implementations, you are missing the point!

The best introduction to monads was written in 2006 (more than eight years ago now) and I don't imagine that a better one will be written in the near future -

http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html

It wasn't meant to be a criticism of your implementation - just a comparison of the two languages for this particular task. Haskell happens to be very concise for writing mathematical code. I love Python too, but for different reasons (easy to prototype, great libraries, flexible).

I've noticed that people with a mathematical background tend to be very attracted to Haskell. There's a great blog post by Dan Piponi enumerating eleven reasons to use Haskell as a mathematician:

http://blog.sigfpe.com/2006/01/eleven-reasons-to-use-haskell-as.html