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

61–70 of 133 posts

Re: Why Maybe Is Better Than Null

#61

Post by dllthomas »

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.

But that's precisely why you abstract it; so you can switch to Error in need be...

Re: Why Maybe Is Better Than Null

#62

Post by dllthomas »

evincarofautumn wrote: post #35
svachalek wrote: post #27

Earlier quoted context omitted.

Ah yes, wonderfully clear syntax: do a

That was a poor choice. The local “a” shadows the parameter “a”. You can of course write: addM :: Maybe Int -> Maybe Int -> Maybe Int addM ma mb = do a As an aside, the inferred type would be much more general, because (+) works on any number and do/return work on any monad: addM :: (Monad m, Num a) => m a -> m a -> m a Which means you could use it like this: addM (Just 5) (Just 10) == Just 15 But also like this: add…

Of course, addA = liftA2 (+) is even more general.

Re: Why Maybe Is Better Than Null

#63

Post by masklinn »

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.

Except contrary to NaN, the type system encodes where it can exist and what its span is.

Re: Why Maybe Is Better Than Null

#64

Post by dscrd »

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.

Re: Why Maybe Is Better Than Null

#65

Post by gizmo686 »

nilkn wrote: post #12

In comparison to Haskell, null in Java is similar to adding an implicit Maybe a instance for every type a. In doing so, Java makes it just that much easier to create bottom values when they are not desired (e.g., dereferencing a null pointer).

I disagree. If null was like Maybe, than you should be able to do:

E foo; ... foo=foo.bar().bat()

without having to do a null check after each function.

I think that Java's approach has the worst of both worlds, because there is no way to make foo.bar().bat() safe when a function could return null.

In C, for example, calling a method on a null object does not cause an error. Rather it passes in null as the 'this' value, allowing you to do you null checks within the method.

Re: Why Maybe Is Better Than Null

#66

Post by dllthomas »

[deleted] wrote: post #55

[deleted]

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.

Re: Why Maybe Is Better Than Null

#67

Post by dllthomas »

yew wrote: post #49
cantankerous wrote: post #45

Earlier quoted context omitted.

True. I think it's also a covert argument for static type checking, though ;-).

Give me a statically typed Python and a type system that can handle external hardware poking around in its memory and I'm in ;) I'm sort of a fan of Haskell already, to tell you the truth.

> Give me a statically typed Python

Not sure that's so far from Haskell, really... :-P

> and a type system that can handle external hardware poking around in its memory

Can it be in isolated places? That's doable...

Re: Why Maybe Is Better Than Null

#68

Post by drorweiss »

dllthomas wrote: post #66
[deleted] wrote: post #55

[deleted]

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.

Re: Why Maybe Is Better Than Null

#69

Post by jeremyjh »

[deleted] wrote: post #55

[deleted]

I think you should reserve judgement until you've worked with a more sophisticated type system than Java. I held the same opinion for quite some time but Scala and Haskell have showed me that much more is possible than I expected.

Still, on balance I prefer dynamic languages because I don't like to spend time defining and using type relations but I am no longer sure I really know which way is "better" for many types of tasks.

Re: Why Maybe Is Better Than Null

#70

Post by papsosouid »

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.

Look everyone, dscrd has solved the problem of software having bugs. Just be careful! Man, why didn't anyone think of that before? The software industry is going to be so much nicer now that you eliminated bugs.
Post reply on HN