I really wish people would start treating languages as languages. `(m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)` is not easy to understand because the symbols don't have names. I can't read it. How is "m >>= f" pronounced?
How do you pronounce '4 + 5'? It's easy, because you don't try to pronounce '+', you pronounce 'plus'. With '>>=', there are a few names that all mean the same thing.
There are two primary names, 'bind' and 'chain', and a description 'feed':
bind (the result of) m to (the input of) f
chain (the result of) m into f
feed m to f
There are probably a couple more things that can be said, in different contexts, but these three cover the majority use case.
That those terms are not mentioned in the article (titled "What I Wish I Knew When Learning Haskell", so apparently meant for people being new to the concepts) is my actual criticism. The ability to instinctively replace those symbols with the appropriate terms is something that has to be learned - and easy to forget to teach. He's talking about "don't learn monads by analogies" because he's maybe not fully aware that he is using "bind", "chain", "feed" when actually reading those expressions - all of which are analogies.
Warning. I think I'm right with these things but I'm also very new to Haskell
> How is "m >>= f" pronounced?
If I'm not mistaken ">>=" is the bind function and could be written like:
bind m f
Meaning that "m >>= f" is pronounced as "bind m to f". What it's doing is:
main = do
m <- SomeActionReturningMonad
f m
Are you saying that a language that uses symbols isn't a language? Is Japanese a language since it uses symbols (glyphs? correct me if I'm wrong).
If you are talking about programming languages specifically, do you believe that "plus" should be used in place of "+"? Now I'm not going to get absurd and assume you mean using "parenthesis_start" in place of "(", but just in case... I will ask if you are.
Also, in Haskell specifically there are matching functions for those.
No, see below, I just think that if you write something is "easy to understand" and then you go on and explain it using unknown (to the reader) symbols without given the symbols pronounceable names, you're doing it wrong. One of the tricks that helped me most when learning more advanced math was to learn "reading"/"pronouncing" formulas first and understanding them second. It feels very nice and intuitive. That's why I'm always annoyed when people explain something using very domain-specific symbols and don't provide any way to "read" them.
I misunderstood your parent comment then I think. I prefer the Haskell tutorials (especially for beginners) that use the function and then provide the shorthand symbol to do it with.
You can also search those symbols on Hoogle[1] or if it is a builtin keyword the Haskell keywords page[2] can be useful.
Programming languages are not natural languages. And where imperative programming can benefit from something that looks like a series of instructions resembling natural language, functional, declarative programming works better with the language being closer to mathematical notation.
If I can't talk to you about it (e.g. I have to literally say "Oh, you forgot to declare a way to apply the greater than-greater-than-equal operator!"), it's hard to actually reason about a problem domain. It's like the magic moment where you go from stumbling through cryptic signs to being able to fluently read (aloud) complex math or logic formulas. I doesn't need to resolve to a normal, casual sentence you'd drop chatting with your cab driver - but there should be a way to pronounce it.
P.S.: I guess what I'm trying to say is - every normal mathematical expression has a way to pronounce it. "plus", "for all x", "there exists an x", "sum of", "element of", ...
You wouldn't have to say "Oh, you forgot to declare a way to apply the greater than-greater-than-equal operator!", you would say "Oh, you forgot to declare a way to apply the bind operator!". Now that you know that, you can stop saying that ">>=" doesn't have a name? You are upsetting poor bind :/
Also here is a great explanation with pictures that helped me understand it:
Thanks! That article is pretty awesome. It would slightly more awesome if it would use the analogies "bind"/"feed"/"chain" that apparently are more often used to speak about it. But I could consider calling it the "shove" operator from now on. ;)
Hey no problem! I used to see Haskell as needlessly complex, unapproachable, and not usable in the real world and now realize that was a mistake, so I just try to show people what I've found out/learned when i can :)
