4 ms·

People who already know what a monad is probably think this is a great example. I still have no clue.

by joev714 2y ago

miohtama 2y ago
It's a type of burrito
- chuckadams 2y ago
  It's an endotaco in the category of fast food, what's the problem?
burkaman 2y ago
This is an inside joke about people who write monad tutorials and think they've completely solved the issue by explaining that they're just like, for example, burritos: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
- myhf 2y ago
  monad tutorials are monads
  - burkaman 2y ago
    class Monad (MonadTutorial badAnalogy) where return badAnalogy = MonadTutorial badAnalogy (MonadTutorial badAnalogy) >>= attemptToExplain = attemptToExplain badAnalogy attemptToExplain :: Analogy -> (MonadTutorial worseAnalogy) attemptToExplain analogy = MonadTutorial (makeItWorse analogy) Been like 10 years since I've used Haskell so I'm not totally sure this works but it was fun.
zug_zug 2y ago
A monad is a weird/unnecessary concept for a type that wraps another type (and makes certain guarantees). Like you can have a List<Int> so List is a monad type. There's also an "option" type in many languages (which is just a list of size 0 or 1), which is a monad. Some people call futures monads. But the real takeaway is that people pretend they want you to understand all this type stuff, but they don't, they want to make up new complicated words for obvious ideas that you already understand, so they can feel smart. Once you understand it they aren't "smarter" anymore, so they make sure to explain every weird term they made up with 5 other weird terms they made up and insisting that all this abstract theory is relevant to everybody when it's not.
- wk_end 2y ago
  The "(and makes certain guarantees)" is the important-and-not-unnecessary part, rather than a parenthetical.
- anon291 2y ago
  A future forms a monad because if you have a future that returns a future that returns an X, then there's a standard transformation from that to a future that returns an X
- boltzmann-brain 2y ago
  > for a type that wraps another type I think you are very confidently wrong here. Monads are not about wrapping types, as evidenced by the IO monad. You cannot say that a type is "wrapped" by the input-output system of a computer any more than you can say that a keyboard contains all possible character strings. I am sorry to say but your comment is a cliche that's existed for at least the 15 years I've been using Haskell, where someone who doesn't understand a concept shows up, decries it as being a hoax and just a bogus complication on top of something simple, and while doing that displays not understanding it in the slightest. But this existed before Haskell too, people have been doing what you're doing on the topic of structural programming, memory safe languages, regular expressions, dynamic html, ... html in the first place, microkernels, linux, unix, personal computers, minicomputers, computers, typewriters, looms, and electricity.
- numerate 2y ago
  > A monad is a weird/unnecessary concept. No it isn't. A monad is a simple and easy concept that make it possible to write generic code that works across a number of very common things in software. The Monad interface is simple, and of immense practical utility. There are only two things that are difficult about the concept: 1. The interface is so simple that it's hard to understand the purpose of it when you are looking at the interface disconnected from the concrete concepts that it abstracts over. 2. The interface was based on category theory concepts and created by people that have strong intuitions about category theory, so there is a lot of text floating around that presumes that background. The essential thing here is that you don't need to know any of this in order to make use of the Monad interface or the generic code written against that interface. > they want to make up new complicated words for obvious ideas that you already understand, so they can feel smart > insisting that all this abstract theory is relevant to everybody when it's not. Where is all of this bitterness coming from, my guy?
EvertBouw 2y ago
monad means a datastructure that implements flatmap.
- ivanjovanovic 2y ago
  Monad means a function composition where you can program what happens when inner function gives its result as argument to the outer function.
- eigenket 2y ago
  I don't think that's a super helpful description, because probably most people wouldn't call IO a datastructure.
deleted 2y ago
[deleted]
bane 2y ago
I like reading the comments on monad descriptions looking for all the ones that declare the wrongness with this one but either offer no further clarification, or offer a similarly useless and confusing description...then I look for the comments under those. They become like beautiful fractal trees with branches upon branches of people giving alternate examples and then comments refuting those. I'm pretty sure at this point this sort of meta-in-joke art form is what a monad is. It's almost as good as the old "time to crate" way of measuring first person shooters.
- bazoom42 2y ago
  Good observation - this happens on every thread mentioning monads. The issue is, monads is a pattern for function composition which can be used for various seemingly unrelated things. But people see one instance of it and then generalize wrongly. E.g. lists and option-types are monads so some generalize them as “wrappers around types” - except this doesnt describe the IO monad at all. Or some see the IO and State monad and generalize monads as about managing side-effects - except this does not describe list or option types.
trealira 2y ago
I'll try to explain it. The article used F#, but I'll explain using Haskell, and first I'll explain dome Haskell notation, because I learned it while learning Haskell. In Haskell, you have types. Concrete types have names that start with an uppercase letter, and generic types have lowercase letters. inc :: Int -> Int inc x = x + 1 not :: Bool -> Bool not True = False not False = True -- id returns whatever it's given unchanged, -- no matter the type. id :: a -> a id x = x You also have more complex types: data IntOrChar = AnInt Int | AChar Char You can match on the "AnInt" part or the "AChar" part. They're like tags. -- Increment it if it's an Int, otherwise leave it f :: IntOrChar -> IntOrChar f (AnInt n) = AnInt (n + 1) f (AChar c) = AChar c The letter "n" is the name of a variable of type Int, and "c" is likewise the name of a variable of type Char. You can have generic data types in the definition of a data tyñe and still add those tags. Generic type parameters are lowercase, just like in functions. data Maybe a = Nothing | Just a You could have functions that define the a type explicitly: someFn :: Maybe Int -> Maybe Int Or it could be generic over that type parameter: someFn :: Maybe a -> Maybe a "Maybe" is a type constructor rather than a type itself. You can also have other type constructors, e.g. this binary tree definition (which is recursive in this case): data Tree a = Leaf a | Branch a (Tree a) (Tree a) In function definitions, you can be generic over type constructors, too. You would write it like this: someFn :: t a -> t a That "t" could be a Maybe, or a Tree, or a list, or any type constructor. In Haskell, Monad is basically an interface where it implements two functions: the infix function ">>=" and the function "return". The interface looks like this: class Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a ">>=" takes two parameters: some "m a" value, and a function that takes an "a" and returns an "m b", then returns an "m b", where "m" is a type constructor like "Maybe", and "a" and "b" are simple types like Int. Here's how you could write the Monad instance for Maybe: instance Monad Maybe where return :: a -> Maybe a return x = Just x (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b maybeX >>= f = case maybeX of Nothing -> Nothing Just x -> f x Here's how you could write it for lists: instance Monad [] where return :: a -> [a] return x = [x] (>>=) :: [a] -> (a -> [b]) -> [b] xs >>= f = concatMap f xs
tonetheman 2y ago
[dead]

People who already know what a monad is probably think this is a great example. I still have no clue.

miohtama 2y ago

It's a type of burrito

chuckadams 2y ago
It's an endotaco in the category of fast food, what's the problem?

burkaman 2y ago

This is an inside joke about people who write monad tutorials and think they've completely solved the issue by explaining that they're just like, for example, burritos: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...

myhf 2y ago
monad tutorials are monads
- burkaman 2y ago
  class Monad (MonadTutorial badAnalogy) where return badAnalogy = MonadTutorial badAnalogy (MonadTutorial badAnalogy) >>= attemptToExplain = attemptToExplain badAnalogy attemptToExplain :: Analogy -> (MonadTutorial worseAnalogy) attemptToExplain analogy = MonadTutorial (makeItWorse analogy) Been like 10 years since I've used Haskell so I'm not totally sure this works but it was fun.

zug_zug 2y ago

A monad is a weird/unnecessary concept for a type that wraps another type (and makes certain guarantees). Like you can have a List<Int> so List is a monad type. There's also an "option" type in many languages (which is just a list of size 0 or 1), which is a monad. Some people call futures monads. But the real takeaway is that people pretend they want you to understand all this type stuff, but they don't, they want to make up new complicated words for obvious ideas that you already understand, so they can feel smart. Once you understand it they aren't "smarter" anymore, so they make sure to explain every weird term they made up with 5 other weird terms they made up and insisting that all this abstract theory is relevant to everybody when it's not.

wk_end 2y ago
The "(and makes certain guarantees)" is the important-and-not-unnecessary part, rather than a parenthetical.
anon291 2y ago
A future forms a monad because if you have a future that returns a future that returns an X, then there's a standard transformation from that to a future that returns an X
boltzmann-brain 2y ago
> for a type that wraps another type I think you are very confidently wrong here. Monads are not about wrapping types, as evidenced by the IO monad. You cannot say that a type is "wrapped" by the input-output system of a computer any more than you can say that a keyboard contains all possible character strings. I am sorry to say but your comment is a cliche that's existed for at least the 15 years I've been using Haskell, where someone who doesn't understand a concept shows up, decries it as being a hoax and just a bogus complication on top of something simple, and while doing that displays not understanding it in the slightest. But this existed before Haskell too, people have been doing what you're doing on the topic of structural programming, memory safe languages, regular expressions, dynamic html, ... html in the first place, microkernels, linux, unix, personal computers, minicomputers, computers, typewriters, looms, and electricity.
numerate 2y ago
> A monad is a weird/unnecessary concept. No it isn't. A monad is a simple and easy concept that make it possible to write generic code that works across a number of very common things in software. The Monad interface is simple, and of immense practical utility. There are only two things that are difficult about the concept: 1. The interface is so simple that it's hard to understand the purpose of it when you are looking at the interface disconnected from the concrete concepts that it abstracts over. 2. The interface was based on category theory concepts and created by people that have strong intuitions about category theory, so there is a lot of text floating around that presumes that background. The essential thing here is that you don't need to know any of this in order to make use of the Monad interface or the generic code written against that interface. > they want to make up new complicated words for obvious ideas that you already understand, so they can feel smart > insisting that all this abstract theory is relevant to everybody when it's not. Where is all of this bitterness coming from, my guy?

EvertBouw 2y ago

monad means a datastructure that implements flatmap.

ivanjovanovic 2y ago
Monad means a function composition where you can program what happens when inner function gives its result as argument to the outer function.
eigenket 2y ago
I don't think that's a super helpful description, because probably most people wouldn't call IO a datastructure.

deleted 2y ago

[deleted]

bane 2y ago

I like reading the comments on monad descriptions looking for all the ones that declare the wrongness with this one but either offer no further clarification, or offer a similarly useless and confusing description...then I look for the comments under those. They become like beautiful fractal trees with branches upon branches of people giving alternate examples and then comments refuting those. I'm pretty sure at this point this sort of meta-in-joke art form is what a monad is. It's almost as good as the old "time to crate" way of measuring first person shooters.

bazoom42 2y ago
Good observation - this happens on every thread mentioning monads. The issue is, monads is a pattern for function composition which can be used for various seemingly unrelated things. But people see one instance of it and then generalize wrongly. E.g. lists and option-types are monads so some generalize them as “wrappers around types” - except this doesnt describe the IO monad at all. Or some see the IO and State monad and generalize monads as about managing side-effects - except this does not describe list or option types.

trealira 2y ago

I'll try to explain it. The article used F#, but I'll explain using Haskell, and first I'll explain dome Haskell notation, because I learned it while learning Haskell. In Haskell, you have types. Concrete types have names that start with an uppercase letter, and generic types have lowercase letters. inc :: Int -> Int inc x = x + 1 not :: Bool -> Bool not True = False not False = True -- id returns whatever it's given unchanged, -- no matter the type. id :: a -> a id x = x You also have more complex types: data IntOrChar = AnInt Int | AChar Char You can match on the "AnInt" part or the "AChar" part. They're like tags. -- Increment it if it's an Int, otherwise leave it f :: IntOrChar -> IntOrChar f (AnInt n) = AnInt (n + 1) f (AChar c) = AChar c The letter "n" is the name of a variable of type Int, and "c" is likewise the name of a variable of type Char. You can have generic data types in the definition of a data tyñe and still add those tags. Generic type parameters are lowercase, just like in functions. data Maybe a = Nothing | Just a You could have functions that define the a type explicitly: someFn :: Maybe Int -> Maybe Int Or it could be generic over that type parameter: someFn :: Maybe a -> Maybe a "Maybe" is a type constructor rather than a type itself. You can also have other type constructors, e.g. this binary tree definition (which is recursive in this case): data Tree a = Leaf a | Branch a (Tree a) (Tree a) In function definitions, you can be generic over type constructors, too. You would write it like this: someFn :: t a -> t a That "t" could be a Maybe, or a Tree, or a list, or any type constructor. In Haskell, Monad is basically an interface where it implements two functions: the infix function ">>=" and the function "return". The interface looks like this: class Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a ">>=" takes two parameters: some "m a" value, and a function that takes an "a" and returns an "m b", then returns an "m b", where "m" is a type constructor like "Maybe", and "a" and "b" are simple types like Int. Here's how you could write the Monad instance for Maybe: instance Monad Maybe where return :: a -> Maybe a return x = Just x (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b maybeX >>= f = case maybeX of Nothing -> Nothing Just x -> f x Here's how you could write it for lists: instance Monad [] where return :: a -> [a] return x = [x] (>>=) :: [a] -> (a -> [b]) -> [b] xs >>= f = concatMap f xs

tonetheman 2y ago

[dead]