14 ms·

I agree wholeheartedly that Functors and Monads should be thought of as interfaces. And that much of what complicates them is separating the implementation deta

by cole-k 5y ago

I agree wholeheartedly that Functors and Monads should be thought of as interfaces. And that much of what complicates them is separating the implementation details from the interface details. However, I can't help but feel that the author and I have some common flaws. The first being verbosity. I often notice the same thing in my own writing: I will see a well-written paragraph and think "this is good stuff" and then wonder "but what purpose does it serve here?" Stuff like dedicating 5 paragraphs to discussing whether Functor should be a noun (I get the point, but that's a lot of words to make it), or a paragraph with caveats about how Haskell does name resolution. The second being that we both seem to have fallen victim to the monad tutorial fallacy (https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...). But I'm not 100% sure about this one. I don't think it's wrong to call monads interfaces in the same way that it's wrong to call them burritos. However, our framework of thinking does seem to align with what that author refers to as fallacious. Still was a good enough read that I felt the need to comment partway through :)

Dylan16807 5y ago
> the monad tutorial fallacy The paragraph starting with "I am aware of the notorious effect" directly addresses this, do you disagree with it? Also calling it an interface isn't an analogy.
- cole-k 5y ago
  > The paragraph starting with "I am aware of the notorious effect" directly addresses this, do you disagree with it? I suppose my answer should be "yes," but let me try to explain my convoluted reasoning: Understanding monads simply in terms of interfaces is what I think is the silver bullet to comprehending them. It's what helped me "get" them. So they are my "burrito." > Also calling it an interface isn't an analogy. I agree, I apologize if I came across this way.
jerf 5y ago
The verbosity is a direct effect of the several discussions I've had over the years on this topic. It has actually had a number of words removal and paragraph revival passes done on it.
- xupybd 5y ago
  It helped me to understand what is going on. I think I've been hung up on functor sounding like a noun for a long time. I thought there was some extra magic I wasn't getting that made it into a noun. The verbosity helped me a lot.
- cole-k 5y ago
  That's fair, and I hope that I didn't come across too harsh in my comment. I elided a paragraph of praise I thought was redundant to my first few sentences.
- ectopod 5y ago
  I found that section really helpful. I've been writing Haskell (on and off) for years but I hadn't realised that the noun thing had created a sort of mental speedbump, which is now gone.
thewakalix 5y ago
I think it is at least somewhat wrong to say that monads are just an interface. For instance, when the author says (paraphrased) “you could remove every trace of monads from IO and it would still be usable, albeit clunky”, they’re actually talking about removing the monad interface, but not the monad structure — it would still rely on a function of type (IO a -> (a -> IO b) -> IO b) that’s expected to follow certain rules. In my book, that is a monad — whether or not it’s called “monad”, and whether or not it’s formalized as such. (This isn’t an entirely new kind of concept in programming, either; see “patterns”.)
- ledauphin 5y ago
  i am interpreting this as "monads are a structural type, not a nominal type". which to me is an interesting debate given Haskell's emphasis on strong interfaces strictly enforced. We seem to be converging on a world where we agree that declaring and enforcing types is very important, yet also that it's the structure of the type, not its name, that is most critical. At some point, with sufficiently advanced type inference, do you end up in a world that looks like a lot like fully dynamic languages, where the actual declaration of the type is purely optional?

by cole-k 5y ago

Dylan16807 5y ago

> the monad tutorial fallacy The paragraph starting with "I am aware of the notorious effect" directly addresses this, do you disagree with it? Also calling it an interface isn't an analogy.

cole-k 5y ago
> The paragraph starting with "I am aware of the notorious effect" directly addresses this, do you disagree with it? I suppose my answer should be "yes," but let me try to explain my convoluted reasoning: Understanding monads simply in terms of interfaces is what I think is the silver bullet to comprehending them. It's what helped me "get" them. So they are my "burrito." > Also calling it an interface isn't an analogy. I agree, I apologize if I came across this way.

jerf 5y ago

The verbosity is a direct effect of the several discussions I've had over the years on this topic. It has actually had a number of words removal and paragraph revival passes done on it.

xupybd 5y ago
It helped me to understand what is going on. I think I've been hung up on functor sounding like a noun for a long time. I thought there was some extra magic I wasn't getting that made it into a noun. The verbosity helped me a lot.
cole-k 5y ago
That's fair, and I hope that I didn't come across too harsh in my comment. I elided a paragraph of praise I thought was redundant to my first few sentences.
ectopod 5y ago
I found that section really helpful. I've been writing Haskell (on and off) for years but I hadn't realised that the noun thing had created a sort of mental speedbump, which is now gone.

thewakalix 5y ago

I think it is at least somewhat wrong to say that monads are just an interface. For instance, when the author says (paraphrased) “you could remove every trace of monads from IO and it would still be usable, albeit clunky”, they’re actually talking about removing the monad interface, but not the monad structure — it would still rely on a function of type (IO a -> (a -> IO b) -> IO b) that’s expected to follow certain rules. In my book, that is a monad — whether or not it’s called “monad”, and whether or not it’s formalized as such. (This isn’t an entirely new kind of concept in programming, either; see “patterns”.)

ledauphin 5y ago
i am interpreting this as "monads are a structural type, not a nominal type". which to me is an interesting debate given Haskell's emphasis on strong interfaces strictly enforced. We seem to be converging on a world where we agree that declaring and enforcing types is very important, yet also that it's the structure of the type, not its name, that is most critical. At some point, with sufficiently advanced type inference, do you end up in a world that looks like a lot like fully dynamic languages, where the actual declaration of the type is purely optional?