Hacker News Reader

Comment by dotdi | Hacker News Reader

> A very clear indication of this is how Haskell treats programming terms. Instead of explaining Monads like all other design patterns out there, they insist on using some obscure definition from category theory to explain it.

The author is bashing people for explaining a concept from Category Theory with... dum dum dum... Category Theory?! Just because OP was looking for articles explaining monads as design patterns doesn't mean there aren't other people who, God forbid, are looking for theoretical articles about CT/Monads explained with Haskell.

Yes, there is value in pragmatism. Rant posts, on the other hand, have little value IMHO. Haskell has shortcomings like any other programming language. That absolutely does not make it a bad programming language.

View on HN

Well to be fair, Functor and Monad in base are pretty far removed from the Category Theory originals.

https://hackage.haskell.org/package/categories has something much closer to the math.

Maybe we should just save the math explanation for the latter, and just call the former something else? :O

Explaning monads in terms of category theory is like explaining regular expressions in terms of finite automata. It's a good idea if you're writing a textbook, but maybe not so much if you're writing documentation for users of a programming language.

> Rant posts, on the other hand, have little value IMHO.

Sure ;=)

But Haskell's explanations of Monads is in my experience really no adequate. Category Theory is the underlying since theory, but do you need to know about mechanics and gears to drive a car?

There are explanations of Monads which are much much easier to understand for most people (people not having much to do with Category Theory).

E.g. by now the concept of map, flat_map is fairly wide spread in most programming languages and you can teach about Monads in terms of that fairly easy. And then add the additional abstraction layer used in context of Monads like abstracting over the "external world state" (IO) and "combining computation descriptions".

> But Haskell's explanations of Monads is in my experience really no adequate. Category Theory is the underlying since theory, but do you need to know about mechanics and gears to drive a car?

Monads are part of the underlying category theory. So asking for a full explanation of Monads you are asking to explain part of the "mechanics and gears" in your car analogy.

> E.g. by now the concept of map, flat_map is fairly wide spread in most programming languages and you can teach about Monads in terms of that fairly easy. And then add the additional abstraction layer used in context of Monads like abstracting over the "external world state" (IO) and "combining computation descriptions".

I think I agree with your main point here that teaching the internal details first is often not the optimal method. You do not need to know how Monads work to use them to great effect in Haskell and other languages.

> but do you need to know about mechanics and gears to drive a car?

Depends on what you are trying to do. You don't need that knowledge in order to drive a car, but there are drivers that absolutely should know about mechanics and gears.

I think that 99% of programmers can get approximately all the value of monads by reading an article explaining how promises, options and lists all have this pattern in common, without any mention of monoids or endofunctors. I enjoyed the courses I did in category theory very much, but the benefit to my code has been zero.

Reply on news.ycombinator.com