Comment by 1718627440 | Hacker News Reader

Comment by 1718627440 | Hacker News Reader

Parent Full thread

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.

(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

> 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.

Reply on news.ycombinator.com