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

31–40 of 103 posts

Re: Maybe Functions

#31

Post by jbandela1 »

I would argue that the vast majority of functions in real world software are maybe functions in that they can fail. You need to be able to deal with failure. Not only can the user not be logged in, there can be a network issue, etc that makes even downstream functions fail.

Also, you have to deal with developer mistakes and what happens when they call incorrectly. This can be something as simple as getting the first element of a collection. What happens when the collection is empty? You can adopt the C++ approach of “undefined behavior” but it turns out to be dangerous.

Monads provide a nice disciplined way to dealing with this and composing together functions that can potentially fail.

Thankfully, newer languages such as providing support for monads and older languages are evolving features/libraries for monadic error handling.

Re: Maybe Functions

#32

Post by fernandotakai »

aziis98 wrote: post #24

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

i remember using this back in my groovy days https://groovy-lang.org/operators.html#_safe_navigation_oper...

Re: Maybe Functions

#33

Post by blowski »

jmduke wrote: post #8

Agreed with this essay, and I think it rhymes with two others that I've found pretty influential over the past five years: 1. Parse, don't validate ( https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... ) 2. Pipeline-oriented programming ( https://fsharpforfunandprofit.com/pipeline/ ) In my experience, the "best" code (defining "best" as some abstract melange of "easy to reason about", "easy to modify", "e…

What constitues the "best" code depends on the incidental complexity of the problems you're trying to solve. Great code is when you have just enough of all those things, but have too much or too little and the code is worse.

Re: Maybe Functions

#34

Post by n4r9 »

In C# the closest analogy I can think of is the "Try" pattern. For example, you have int.Parse(string) which returns int, and int.TryParse(string, out int) which returns bool. The fact that the returned value is the validation is a strong incentive to do something with it.

Re: Maybe Functions

#35

Post by nnnnico »

lixquid wrote: post #14

Program logic fundamentally has to contend with different conditions. Sometimes the user will be logged in and have friends, sometimes they won't. The "maybe" style has the inconsistency embedded in the type system; it's impossible to have an invocation to getFriends and then not handle the resulting possibility of not being logged in. Shifting it up to the caller just means that you're going to have to remember to e…

I agree with this. I prefer explicit optional/null return types, otherwise the possibility of an error still exists but is now hidden to the caller. Langs with syntax for concise optional chaining and such fix this problem imo

Re: Maybe Functions

#36

Post by madeofpalk »

aziis98 wrote: post #24

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

Go actually needs proper nil/null/optionality first before it can get syntax features to deal with them.

Re: Maybe Functions

#37

Post by planede »

jbandela1 wrote: post #31

I would argue that the vast majority of functions in real world software are maybe functions in that they can fail. You need to be able to deal with failure. Not only can the user not be logged in, there can be a network issue, etc that makes even downstream functions fail. Also, you have to deal with developer mistakes and what happens when they call incorrectly. This can be something as simple as getting the first…

> Also, you have to deal with developer mistakes and what happens when they call incorrectly.

There is only one safe(ish) way to deal with programmer errors: crash. Hopefully loudly and early enough so it gets discovered in testing.

Re: Maybe Functions

#38

Post by jagged-chisel »

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 like the philosophy that “exceptions are for exceptional circumstances.” Not being logged in is not exceptional.

Re: Maybe Functions

#39

Post by tobr »

You can address this with explicit parameterization instead of global state. That way the missing data is an obvious type error rather than a surprise in the middle of a running function.

Re: Maybe Functions

#40

Post by PartiallyTyped »

This is a great example of the issue with using monads and monad-like patterns in languages that don't have proper support via language constructs for these.

In rust for example, this is trivially handled with the questionmark postfix operator — which is just sugar for match — whereas in languages like JS and Java, stacking Optionals and so on can be rather painful as all this sugar is done manually.

Post reply on HN