1. 24
  1.  

  2. 8

    ‘If you should by some accident come to understand what a Monad is, you will simultaneously lose the ability to explain it to anybody else.’

    1. 15

      This is actually not as much parody as something often touted by people in earnest. It’s the so called “Crockford’s Law” and I think he coined it in that talk referenced in this article.

      First, for the avoidance of doubt, Crockford’s talk is terrible and his “law” has some serious flaws—but there’s a good thing going on inside of it, I think.

      In particular, it’s my believe that “coming to understand Monads” has little to do with “Monads” at all. It’s more of a problem of understanding abstract concepts (as a term of art, see http://www.stephendiehl.com/posts/abstraction.html), their representation in Haskell’s type system, and then coming to terms with one particular choice of abstract concept.

      So, what often happens is that once someone actually succeeds at this they either (a) stop responding to requests to “explain Monads” since they know that’s an immediate dead end and a detour should be taken or (b) get overconfident and actually try to answer the question but leave out the aforementioned prerequisite ideas.


      There is actually an easy way to understand Monads. Pick two of them—let’s say “Maybe” and “State"—and stop trying to "understand Monads” but just get used to using those two. Understand them concretely and notice patterns in how people use them. Either dive into do notation and use it as you see others do or avoid it and write everything out by hand. Both approaches work fine.

      At the end of the day, there’s a good chance you’ll see some common patterns and perhaps want to give them a name. At that point, ask someone what a Monad is.

    2. 8

      It might have been the late hour, but I found this article hilarious. The author clearly comes from a place of knowledge of functional programming, and she uses just the right blend technical concepts and dogma to be really funny!

      There are a bunch of really silly jokes in this article but I think some points could merit further discussion:

      • Articles touting the merits of FP and explaining Monads are becoming very common and generic, and it may be argued that the general response to them hasn’t changed. Would a shift in focus from explanation (articles explaining FP concepts) to demonstration (case studies of successful projects where FP was the ‘secret ingredient’) help with this?

      • Different programming languages and paradigms offer different benefits and trade-offs to programmers, and choices about them should be dealt with on a project by project basis. I think too many programmers are stuck thinking that “X is the best programming paradigm”. Instead, I think it would benefit people to learn/be taught about several different paradigms, thereby fixing the “If all you have is a hammer, all problems look like nails” aphorism.

      • Every programming ingroup has some amount of dogma. I think that a lot of this dogma actually stems from certain groups trying to overcome the dogma from other groups, causing people to become further polarized. This is commonly referred to as the backfire effect.

      1. 4

        verity stob is also responsible for the classic quote about how “lisp is still #1 for key algorithmic techniques such as recursion and condescension”