[tickettotranai]

Like many things in life it is far easier to give examples than it is to describe the thing.

Examples of monads are Promises and Elvis operators (for values that can be nullptrs). In a sense exceptions as well. Having heard this I think if you do a second pass at the type definitions, I think you may be able to parse them out

It really is just "a wrapper for values that sticks around when you do something to the values".

Think of it as a coding pattern, and it's much easier to grok

It's handy for IO because, well, did you see the examples I gave? A monad lets you basically ignore the failure mode/weirdness (the async stuff in the context of promises, null type in the case of Elvis) and worry about the computation you actually want to be doing.

Other places you might apply these would be fileio (file not found? cool, don't care, deal with it later) or networking (as long as the connection's good, do this.)

[1718627440]

Sorry I never understood the functional approach outside of LISP being cool, because code is data.

Promises are wrappers, I see that. How are exceptions wrappers? They stop the code at the point the exception occurs and unwind the stack. They don't allow you to continue doing stuff and deal with it later.

> A monad lets you basically ignore the failure mode/weirdness

I just don't see how this works out in practice?

Ok, I defer dealing with file not found. Does that mean I know perform heavy computation and parsing on something that does not even exist. Wouldn't it be way easier to just do an early return and encode that the file exists in the type? And how does it play out to let the user wait for you doing something and you at the end coming around, well actually the input file was already missing?

And then you have some intermediate layer that needs to store all the computation you are doing until you now whether something succeeded or not. All this to save a single return statement.

[tickettotranai]

(rewrote this to be less insufferable)

It's not about saving a single return statement, even in the elvis case. How many times have you written code along the lines of "if this isn't null do this, otherwise return. If the result of that isn't null, do this, otherwise return" etc etc.

Elvis ops are a small QoL change, Promises are essential to async Exceptions (much of the time) are kind of a "catch it pass it on" logic for me, and man do I wish I didn't need to write it every time.

With networking this really shines, or really just anything async etc

[1718627440]

> How many times have you written code along the lines of "if this isn't null do this, otherwise return. If the result of that isn't null, do this, otherwise return" etc etc.

Yeah that sucks, but why would you write it that way. I thought it is common to write "if this is null return, anyways: do this, do that."

> Promises are essential to async Exceptions

I don't see that either. If errors are specific to functions then there is only one case where I handle them, so it doesn't save something to put these checks elsewhere. If they can be accumulated over many calls, then they should be just part of the object state (like feof), so I can query them in the end.