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

Why Maybe Is Better Than Null

nickknowlson.com

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Why Maybe Is Better Than Null

#101

Post by implicit »

I've been working with engineers writing production Haskell for the first time; its lack of a "null" concept is proving to be absolutely incredible. In a high-uptime production environment, it's at least as valuable as Haskell's enshrinement of purity.

We have a convention that all recoverable errors be captured in Either or Maybe. This policy is paying off in a huge way because the type system forces us to think about what error cases mean. This is driving us to write substantially higher-quality code than I've written with other tools.

Re: Why Maybe Is Better Than Null

#102

Post by mokus »

aaronblohowiak wrote: post #37
tikhonj wrote: post #31

Earlier quoted context omitted.

The real trick is that, conceptually, these are not really "unwrapping" functions--instead, they're "propagating" functions. All they do is take Maybe values from deep inside your computation and string them through to the outside. In practice, this means that you write a decent part of your program using these techniques, which creates a block of code that produces a Maybe value after taking a bunch of Maybe inputs.…

>That pattern just turns out to be very useful. Like NaN, it can be hard to track down where things went wrong.

> Like NaN, it can be hard to track down where things went wrong.

Unlike NaN, you have the freedom to not use it when you don't want it.

Re: Why Maybe Is Better Than Null

#103

Post by ycombobreaker »

kruffin wrote: post #23
bajsejohannes wrote: post #14

Earlier quoted context omitted.

I've worked with a code base in C++ where the code base would accumulate significant amounts of if (argumentX == null) return null; at the top of function signatures. It was just defensive programming. Maybe argumentX couldn't be null, but it would take time to figure that out (sometimes I did that, though). More code means harder to read and maintain, thus costing dollars. This would also be contagious: If a piece o…

I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null. You can do this, but if you want it to be maintainable, you'll also want to detail in the function comments this technical debt. If you don't, someone else will come along and see your sweet method (looking only at the comments) and use it where the input can be null. Ex: /** * This does some stuff. *…

Why just put it in the documentation? Documentation is liable to drift from implementation, and AFAIK no compiler or runtime verifies the accuracy of comments. I'd feel much better about adding asserts to the original code, leaving it for a few generations of testing and exposure, and then eventually remove the conditionals. The assert calls then function as executable documentation.

Depending on your user-base (i.e. if you distribute headers to other developers with precompiled code), the documentation may be necessary on its own... but it's much weaker than an assert.

Re: Why Maybe Is Better Than Null

#104

Post by dllthomas »

drorweiss wrote: post #68
dllthomas wrote: post #66

Earlier quoted context omitted.

If the database structure is encoded in your type system, and all your code that accesses the database (including the initial population of the database) is checked against that encoding, the compiler can absolutely statically check the correctness of code that relies on the structure and contents of the database. Several of the mainstream Haskell database packages do this.

Sure, I will look at Haskell. Still, IMO this may be true in theory. In practice, most of the errors we encounter come from incomplete understanding of the input we're dealing with. These are many little rules that are very hard to formalize.

Incomplete understanding of input or domain is certainly a cause of problems, and I don't know that there is a way the type system can help in the general case.

With regard to databases in particular, though, it is comparatively easy to constrain things so that you don't have that problem, and enlisting the type system there makes sense. There are other areas that have useful approaches as well - consider protocol buffers, for instance.

I prefer to let the type system catch what it can, and use tests for where it can't - often type info can be leveraged to help in the testing, too: I recommend checking out quickcheck if you haven't.

Re: Why Maybe Is Better Than Null

#106

Post by geon »

acomar wrote: post #97
pubby wrote: post #80

Earlier quoted context omitted.

Pardon my confusion, but is null referring to that of Java-style reference types, in which case the article is really about those? The value itself seems irrelevant as null is practically equivalent to Nothing. Now, if comparing the types then I'd say that Haskell's Maybe has the following improvements over Java-style optional: 1. Opt-in 2. Not tied to reference types 3. Safe extraction/"dereferencing". ie case expre…

Yep, you've got it exactly right. The problem for dynamic type systems is how do you enforce 3? Do you care to?

I suppose you could write a sort of safe Maybe template class in c++. You could pass in two callbacks to handle Just and Nothing respectively. It would be really ugly, but should work, right?

Re: Why Maybe Is Better Than Null

#107

Post by geon »

hmottestad wrote: post #81

Null != None Null means unknown. Take a look at the difference between open and closed world systems.

Null would mean whatever the programmer inteded it to mean. In the C world it sees to me it tends to mean "nothing", while in SQL it usually means "unknown".

Re: Why Maybe Is Better Than Null

#108

Post by geon »

dscrd wrote: post #64

If you work on types that might be null, you're bloody careful or you're in the wrong profession. We're not calling incompetent programmers a gazillion dollar mistake, even though they probably have caused as much.

If mistakes can be made, they will be.

Re: Why Maybe Is Better Than Null

#109

Post by laureny »

kruffin wrote: post #23
bajsejohannes wrote: post #14

Earlier quoted context omitted.

I've worked with a code base in C++ where the code base would accumulate significant amounts of if (argumentX == null) return null; at the top of function signatures. It was just defensive programming. Maybe argumentX couldn't be null, but it would take time to figure that out (sometimes I did that, though). More code means harder to read and maintain, thus costing dollars. This would also be contagious: If a piece o…

I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null. You can do this, but if you want it to be maintainable, you'll also want to detail in the function comments this technical debt. If you don't, someone else will come along and see your sweet method (looking only at the comments) and use it where the input can be null. Ex: /** * This does some stuff. *…

Java has supported @Nullable and @Nonnull for a while, it's pretty standard in good Java code these days, and the IDE's will perform static analysis to make sure you use these annotations consistently (e.g. warn you if you are checking a @Nonnull against null or if you are forgetting to test a @Nullable against null before dereferencing it).

Re: Why Maybe Is Better Than Null

#110

Post by nandemo »

qb45 wrote: post #50

Another story is that you may end up with something like: Just x -> something x Nothing -> halt_and_catch_fire # impossible In Haskell there is even a standard library function fromJust which does exactly that. One introduces this hack knowing that this particular variable will always be Just and having absolutely no way to deal with Nothing and later somebody else sees the type Maybe Foo and figures that it must be…

Well, assuming "halt_and_catch_fire" is something like error foo or undefined, you're essentially going out of your way to circumvent the type system. It's possible to do it, but it's frowned upon.
Post reply on HN