Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe Functions

blog.benwinding.com

Post reply on HN
Print view View original

21–30 of 103 posts

Re: Maybe Functions

#22

Post by moomin »

I feel like there's a whole genre of essays (red vs green functions is the worst example) that could be summarised as:

* Monads naturally arise out of many problems in programming.

* But I don't want my language to support monads.

* So here's something you can do to stay in denial about how much you need monads.

At least this example only involves writing hard-to-analyse code and doesn't lead to you trying to invent green threads.

Re: Maybe Functions

#23

Post by tuyiown »

This is a pattern you cannot always avoid, due to react, but i don't think it should be normalized.

Two remarks:

• the render function is omitted, this pattern as a huge impact on application behaviors, if not for display-as-you-load issues, on DOM hidden state (things like focus, animations, etc…) for web apps.

• App's do have a global state, with self-consistency, scattering it in a mixed match of loading cache and self contained components just make it hard to work with. I think it's better to have a centralized upper level parent component that manage the transitional initialization states and consistency, not necessarily for the whole app, but at least for the whole displayed UI content.

Re: Maybe Functions

#24

Post by aziis98 »

I can't wait for more languages to adopt the "?" operator [1] like the Rust one. It's just syntactic sugar for "if expr null return null" but makes it far easier to write code in a more monadic style.

(mostly waiting for this in JS and Go)

[1]: https://doc.rust-lang.org/reference/expressions/operator-exp...

Re: Maybe Functions

#25

Post by brabel »

AtNightWeCode wrote: post #15
koliber wrote: post #6

Another option is Exceptions. The function either does what it's supposed to, or freaks out. You can remove the null checks and the software will raise a null pointer exception. In the first example, could raise a NotLoggedInException. It's still a maybe function, but you have a mechanism for expressing the why-notness of the function run, as opposed to returning a generic null. As an aside, I prefer the "Unless" mod…

I am for exceptions but it should not be used for basic control flow. Many techs will treat all exceptions as errors.

In this case, it's not being used for basic control flow. It's a prerequisite of the function that the user is logged in - and you violated that so it's an error. Returning null masks the reason why that happened. As others already said: you shouldn't even be able to call this function when your pre-requisites for calling it are violated, ideally. You can achieve that by putting this function inside some sort of object which can't be created without a logged in user. If you don't have that, you can't ask for user information.

Re: Maybe Functions

#27

Post by steeleduncan »

pavel_lishin wrote: post #10

What's the advantage of the Monad approach? Doesn't the render function still have to check whether those Maybes contain values or not?

I dont think there is any advantage when the language lacks syntax level support for Monads. E.g. in Haskell (which does) it would look roughly like:

  getUser :: Maybe User
  getUser = ...

  getFriends :: Maybe [User]
  getFriends = do
    user  renderBestFriends besties
      Nothing -> renderNoFriends
The Maybe monad itself contains the equivalent of runSafely from the article, and the syntax propagates the failure case transparently from getUser down to the choice of render function used. All without either the hassle of handling null cases, or the danger that you might forget to handle them and the code crash. Without syntax level support, its not obviously an improvement to me

Re: Maybe Functions

#28

Post by nnnnico »

koliber wrote: post #6

Another option is Exceptions. The function either does what it's supposed to, or freaks out. You can remove the null checks and the software will raise a null pointer exception. In the first example, could raise a NotLoggedInException. It's still a maybe function, but you have a mechanism for expressing the why-notness of the function run, as opposed to returning a generic null. As an aside, I prefer the "Unless" mod…

Sure but only in langs wich require exception handling! Otherwise it's just hidden behaviour and explicit optional returns are better imo

Re: Maybe Functions

#29

Post by somishere »

And what if `fetchUser` hits an error? At the very least pop your de-maybeifier after the async call. Or use something language standardised (like a promise in JS where you can just throw).

I'm all for a perfy shortcut / early return but this maybe just seems like an abstraction on a non-issue.

Re: Maybe Functions

#30

Post by cowsandmilk »

Can’t disagree more. Solution 1 just presents risk that some calls getUser() without doing the log in check. Then what happens?

It is false that getUser being a “maybe function” forces the other functions like getFriends to be maybe functions. Don’t let them take null in their arguments. Force the caller to deal with the null when it is returned by getUser.

Post reply on HN