[dkersten]

and monads

I really don't understand why people have such issues with monads. I don't have a haskell background and originally built up most of my functional programming skill in Python (going somewhat against the grain) and I find monads to be a fancy scary term for an extremely simple concept. I think if they were named something friendlier perhaps people's eyes wouldn't immediately glaze over and they could realise that, actually, monads are just a simple strategy for controlling how things are executed/computed. Computational or execution strategies, if you will. Lets just call them strategies and see if they are less confusing and scary?

[ddellacosta]

I don't know if I can agree with this. I've invested a significant amount of time in learning about monads (and functors, applicatives, monoids, and more from the bestiary of commonly used category theoretic structures in Haskell) and I find them quite challenging to grasp in their full generality. While specific use-cases are readily understood, getting to the heart of what a monad "is" has taken me time, and I honestly don't believe I've properly grasped it yet.

So I think there's a spectrum of understanding and effective use when it comes to monads and other algebraic structures like these, and I'm skeptical when people say, "oh yeah, a monad is just X, it's simple." I've said that myself in the past and I was wrong, and so were most of the people I've heard say that.

To put it another way: when I hear people who know what they're talking about say it's simple, they are talking about its structure, not about understanding what it is and how it is used. In that sense it is quite simple. But as Euclid said, there's no royal road to geometry (er, or monads...).

[dkersten]

Absolutely there's a spectrum and I certainly don't fully understand the full set of category theoretic structures (I'm slowly trying to learn, but.. its slow going). I just think that monads as programming constructs are quite simple. I don't doubt that in a full mathematical context there is a hell of a lot more to them and the mathematical reasoning behind how they work is surely beyond my understanding, but from a how they work, how to use them, how they interact with the language and what they enable you to do point of view, they aren't difficult at all.

[ddellacosta]

...but from a how they work, how to use them, how they interact with the language and what they enable you to do point of view, they aren't difficult at all.

I guess we'll have to agree to disagree here: I have found it challenging to grasp all of these things (even simply within the context of programming language usage). I guess that is, in the end, rather subjective.

[lostcolony]

For me the block for a long time for monads was understanding how they made IO possible.

That is, the basic ideas for things like a Maybe or similar were obvious and intuitive to me, and everyone software dev for long has done such things, even if they never think about what parts they could refactor out into something reusable.

But the leap from that to how it makes IO possible without side effects I just did not grok. It really only clicked reading something or other that described (admitting it was lying a little bit) the IO monad as something that threaded the state of the world through the program; that is, that world state becomes both an (invisible) input and output for functions, and so effects on it are fully encapsulated by the param(s) and return type of the function.

[dkersten]

That's a fair observation and I admit I didn't consider that when I wrote my comment. It is pretty difficult to visualise and leads to a lot of "but you still interact with the outside world so how can it be pure" kinds of confusion. Its very hard to visaulise how the program essentially gets wound up and then at runtime as IO occurs gets unwound. Some of the other monads are definitely simpler to understand!

[runT1ME]

> controlling how things are executed/computed.

No...see...you understand a monad. That is not the same thing as groking "Monads" in the abstract sense.

For instance, I don't think the State monad really has anything to do with how things are 'executed/computed'

[dkersten]

Sure it does - you execute code in the context of a monad. In the case of the State monad, your code executes in the context of a stateful environment.

[nbouscal]

I really don't understand why people think monad is a "fancy scary term". It's a five-letter easily-pronounceable word. What makes it fancy or scary? I think people assume that they're scary, and then confirmation bias themselves into making them hard to learn, despite them being a reasonably simple concept overall.

As for calling them strategies… if we called them that it would make learning and understanding the intermediate and advanced concepts significantly less accessible and more difficult. We should call things what they are.

[jfaucett]

hmm, if we called them what they are we'd call them "type wrapper functions" and talk about "type wrapper function chains", monads carries zero metaphorical/associative meaning. I think thats the problem with the name and a large reason people find them so unapproachable, most other terms in computer science carry significant associative meaning that helps in learning them, pointers have to do with pointing at things, functions carry the mathematical meaning of a set of inputs mapping to a set of outputs, etc.

[nbouscal]

You're demonstrating that you don't know what monads are. "Type wrapper function" could mean any number of things (lack of specificity is a bad trait in naming), but it couldn't mean a monad: monads consist of three things, whereas "type wrapper function" implies one thing.

Names don't need to be metaphorical. The purpose of a name is not to teach you what the thing is. For that, you should have a proper explanation from someone who knows. Names have a different, very important purpose: uniquely specifying the thing being named. "Monad" does that very effectively.

[amelius]

> I really don't understand why people think monad is a "fancy scary term".

The reason could be that the term "monad" comes from category theory, and that is a topic not everybody is too familiar with...

[nbouscal]

Lack of familiarity doesn't make it fancy, and for a software engineer it shouldn't make it scary either. One of the largest parts of our job is learning unfamiliar things.

[dkersten]

We should call things what they are.

Sure - I wasn't seriously suggesting we rename them, just that in my personal experience, newcomers get scared off seemingly by the name alone before ever actually finding anything out about them. A friendlier name may avoid this for newcomers. It definitely wouldn't be worth it for more advanced practitioners where referring to them exactly and in the context of their category theory roots is much more useful than friendliness.

[nbouscal]

I'm not sure how worried I am about the class of newcomers that will be scared off by a word that they don't know. PHP is friendly to newcomers, and the result is thousands of insecure websites built by people who think they know what they're doing but don't. Software engineering is a professional discipline. I don't understand the desire to pander to the lowest common denominator. When's the last time you saw a physics practitioner propose renaming vector spaces to be friendlier to the students?

(For what it's worth, you may not have been serious about renaming monads, but many others have seriously proposed it. In most languages other than Haskell they've been successful.)

[dkersten]

I don't understand the desire to pander to the lowest common denominator.

If people want to learn about monads is up to them and I don't have any skin in the game, but I hear a lot of people complaining that monads are so difficult to understand or use and I guess I was really just observing, in a roundabout way, that I feel a lot of that is down to monads appearing more complicated or scary than they are and that people are put off by it, kind of how people are put off Lisp's due to the parentheses.

[nbouscal]

Yep, on that point I agree with you completely. I don't at all understand why people find their appearance complicated or scary, but I agree that it's more appearance than reality.

[ufo]

> What makes it fancy or scary?

Its an abstraction and abstractions are hard. In away, its similar to why beginners tend to have trouble with recursion (if you try to understand a recursive program by stepping through without using abstractions like preconditions and postconditions)

[hornd]

Why would calling them anything different have any effect on learning other concepts?

[nbouscal]

Because the associated concepts, for example Kleisli categories, are easy to find if your search is seeded with the word "monad", but very hard to find if it's seeded with the word "strategy".

[arjie]

How about F#'s Computation Expressions? Not exactly the same, I'm told, but they're close, if so.

[louthy]

They're called computation expressions in F# and not monads because they're not exclusively used to implement monads. The term is more generalised to capture the much larger scope of the feature.

Here's a breakdown of the difference:

http://tomasp.net/blog/2013/computation-zoo-padl/index.html

[arjie]

Excellent! Thank you!

[dkersten]

I was kinda thinking of F#'s Computation Expressions when I posted my comment.