sophacles on Monads for Normal Programmers

Comment on Monads for Normal Programmers parent

This comment is exceptionally useless. Why is it wrong?

This is a vast oversimplification of both Haskell's monads and the category theoretic Monad. Just because you can chain methods doesn't make something a Monad even in the most basic sense of satisfying the typeclass requirements in Haskell.

Peaker 13y

It does not cover any of the interesting traits of Monads.

I could try to explain Monads in this comment, but others have already done it well.

Any explanation of Monads must at least cover the actual Monadic operations and the laws that relate them. Also, all of the examples he brings are not actually Monads, as explained by others.

seliopou 13y

> Any explanation of Monads must at least cover the actual Monadic operations and the laws that relate them. Also, all of the examples he brings are not actually Monads, as explained by others.

That's not true at all, and thinking like that is the reason why so many awful monad tutorials exist, and everybody outside of the Haskell community immediately tl;dr's when monads are mentioned.

You don't need to understand the monad laws to use monads. You do need to understand the monad laws implement your own monad. They are two completely different levels of understanding, and there's nothing wrong with that.

Ixiaus 13y

I respectfully disagree. It wasn't until I read the typeclassopedia and the article on the Haskell category (that goes into the Monad laws, the Functor laws, &c...) extensively did I really start to understand Monads.

At first, reading all of these "tuts" or "analogies" I always thought, "Oh! It's just like an object in Python!" but boy was I wrong - no one told me I was wrong, I just figured it out after reading the more formal presentations of what a Monad is.

It was also mind opening to understand the basics of Category Theory and learn that every Monad is a Functor.

Peaker 13y

He wasn't trying to explain how to use monads. There are good tutorials that do that. He was trying to explain what they are. And that definitely involves their operations and the laws that apply.

steveklabnik 13y

    class Monad
      def foo
        return Monad.new
      end
    end

is a monad by the article, but is certainly not a monad.

EDIT: s/unit/foo/, to remove discussion about comparisons to the 'unit' that monads actually have.

sophacles 13y

I don't fully understand monads, but this is disingenuous. The article clearly compares unit to constructors, in a way that is far more like this:

   class Monad:
       def __init__(self, val):
           self.val = val
       unit = __init__
       def bind(self, fun):
           return fun(self.val)

Now, in the case of our ruby and python examples respectively, there is no sane way of enforcing typing, but if it works out, it looks to me like that at least implements the monad interface. Not so sure how all the laws work out...

But interestingly we could implement lift as a Monad method by:

   def lift(self, fun=lambda x: x*2):
       self.val = fun(self.val)
       return self

unless I really don't get all this.

Peaker 13y

Your class is not representing the "Monad" abstraction, but the "Identity" value wrapper that happens to have a Monad instance.

steveklabnik 13y

The article says:

  > A Monad is an object whose methods return monads.

Further down, it explicitly states that this is not an analogy, that it is 'equivalent':

  > That is, that the following definition is equivalent 
  > to the type theoretical definition of monads:

My Monad object has one (actually... let's not go there yet) method, and it returns a Monad. I happened to name it 'unit' but it could have been 'foo' and it would still fall under the definition given in the article. I've edited my above post to change the name.

Okay, now let's go there: another reason that this is even more silly is that my object has way more than one method:

  irb(main):005:0> Monad.new.methods.count
  => 57

Many of these do not return a monad. Even if I inherited from BasicObject, there would be methods that do not return a Monad, and therefore, according to the above definition, it is impossible to have a monad in Ruby. However, you can have a monad in Ruby, so this further demonstrates that the above definition is incorrect.

Comments